Skip to main content
← All vulnerabilities
CVE-2026-63378

TAKO AI Agent for Okta: Authenticated Python execution through validator bypass

Affects TAKO / okta-ai-agent v3.0.0-beta, where any account with a valid fctr_session cookie can reach the affected endpoint. Fixed in v3.0.1-beta.

Published
Last modified
published
Not listed in CISA KEV
Specific setups only
Fix
Fixed in 3.0.1-beta
None on Exploit-DB, Metasploit or GitHub

Summary

Any authenticated user of TAKO AI Agent for Okta, without administrator privileges, can run arbitrary Python code on the server because a flawed code validator can be bypassed. This can lead to full compromise of the application container, exposing Okta API tokens, secrets, and the local database, and enabling further pivoting within the backend.

Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.

Read the original description

TAKO AI Agent for Okta is a local-first AI agent that helps Okta administrators query tenant data using natural language. Prior to 3.0.1-beta, any authenticated user with a valid `fctr_session` cookie can submit arbitrary Python source in the `script_code` field of `POST /api/react/execute-script`, without administrator privilege. In `src/api/routers/react_stream.py`, the source is stored with `skip_discovery=True`, bypassing AI-based content filtering, and is passed to `validate_generated_code` in `src/utils/security_config.py`. `BLOCKED_PATTERNS` recognizes direct `import` calls but misses the import name passed as a string, `getattr` is in `ALLOWED_BUILTINS`, and the AST checker handles `ast.Name` and `ast.Attribute` targets but fails to handle `ast.Call` targets. Dynamic `getattr` call chains through `builtins` therefore evade validation. The `_write_temp_script` helper writes the accepted code to disk, and `asyncio.create_subprocess_exec()` executes it as the application process user, which is root in the default container. Command output is returned as Server-Sent Events through `GET /api/react/stream-react-updates?process_id=<id>`. The resulting container compromise can disclose environment secrets including Okta API tokens and the JWT key, expose the SQLite database, and permit backend-service pivoting and persistence. This issue is fixed in version 3.0.1-beta.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • fctr-id okta-ai-agent

    fixed in 3.0.1-beta

References 3

GitHub · fctr-id/okta-ai-agent

FAQ

Questions about CVE-2026-63378

What does this mean?

A validator bypass lets an authenticated user run arbitrary OS commands on the server as the process owner. In the default Docker deployment that owner is root, which can lead to container compromise and exposure of secrets such as Okta API tokens and the JWT key.Source: github.com, github.com

Am I affected, and how do I check?

The advisory names TAKO / okta-ai-agent v3.0.0-beta. The affected endpoint requires only a valid fctr_session cookie and checks for no admin or elevated privilege, so any authenticated account can reach it. To check a installation, confirm which version of TAKO / okta-ai-agent is deployed.Source: github.com, github.com

What should I do about it?

Upgrade to v3.0.1-beta, the patched version named in the advisory. The sources give no workaround.Source: github.com, github.com

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data