Okta Ai Agent
Monthly
Authenticated users of TAKO AI Agent for Okta can execute arbitrary Python and OS commands on the server because the application's script validator can be bypassed with dynamic getattr call chains; all versions prior to 3.0.1-beta are affected, and the default Docker deployment runs the process as root. The public advisory includes a working proof-of-concept that returns uid=0(root) output in that default container, enabling disclosure of Okta API tokens and the JWT key, SQLite database access, and backend pivoting. No CISA KEV entry is recorded at time of analysis; the vendor-released fix is 3.0.1-beta.
Unauthenticated first-run administrator takeover in TAKO AI Agent for Okta (pip package okta-ai-agent) v3.0.0-beta: the POST /api/auth/setup endpoint in src/api/routers/auth.py performs no authentication, requires no one-time bootstrap token, and applies no network restriction, so any remote attacker who reaches a freshly deployed instance before the legitimate owner completes setup can create the sole admin account and receive a valid fctr_session JWT cookie. Because the default docker-compose.yml publishes port 8001 on all interfaces and the Dockerfile binds uvicorn to 0.0.0.0, a default deployment reachable from untrusted hosts is exploitable with a single HTTP request and no Okta tenant access; the attacker then controls Okta-synced user data, stored API tokens, chat history, and integration credentials. A public advisory includes full reproduction artifacts and working step-by-step exploit instructions (publicly available exploit code exists), and the release fixing the issue is v3.0.1-beta, which introduces an ephemeral in-memory setup token and binds the published port to 127.0.0.1 by default. Exploitation is limited to the first-run window: once setup is completed the endpoint returns HTTP 400, and deployments bound to localhost or an internal interface reduce exposure.
Authenticated users of TAKO AI Agent for Okta can execute arbitrary Python and OS commands on the server because the application's script validator can be bypassed with dynamic getattr call chains; all versions prior to 3.0.1-beta are affected, and the default Docker deployment runs the process as root. The public advisory includes a working proof-of-concept that returns uid=0(root) output in that default container, enabling disclosure of Okta API tokens and the JWT key, SQLite database access, and backend pivoting. No CISA KEV entry is recorded at time of analysis; the vendor-released fix is 3.0.1-beta.
Unauthenticated first-run administrator takeover in TAKO AI Agent for Okta (pip package okta-ai-agent) v3.0.0-beta: the POST /api/auth/setup endpoint in src/api/routers/auth.py performs no authentication, requires no one-time bootstrap token, and applies no network restriction, so any remote attacker who reaches a freshly deployed instance before the legitimate owner completes setup can create the sole admin account and receive a valid fctr_session JWT cookie. Because the default docker-compose.yml publishes port 8001 on all interfaces and the Dockerfile binds uvicorn to 0.0.0.0, a default deployment reachable from untrusted hosts is exploitable with a single HTTP request and no Okta tenant access; the attacker then controls Okta-synced user data, stored API tokens, chat history, and integration credentials. A public advisory includes full reproduction artifacts and working step-by-step exploit instructions (publicly available exploit code exists), and the release fixing the issue is v3.0.1-beta, which introduces an ephemeral in-memory setup token and binds the published port to 127.0.0.1 by default. Exploitation is limited to the first-run window: once setup is completed the endpoint returns HTTP 400, and deployments bound to localhost or an internal interface reduce exposure.