al-ice.ai

Setup Was the Vulnerability: TAKO's Okta AI Agent Shipped Unauthenticated Admin Creation and Root Code Execution

AI Vulnerabilities & CVEs by al-ice.ai Editorial

An AI agent that administers your identity provider is the highest-leverage software in the building — and this one handed out the keys twice. NVD published CVE-2026-63377 (CVSS 9.8) and CVE-2026-63378 (CVSS 8.8) on 30 October 2026 against TAKO AI Agent for Okta, a local-first agent that lets administrators query tenant data in natural language. The first flaw let any unauthenticated network attacker create the sole administrator account; the second let any authenticated user — no admin role needed — execute arbitrary Python as root by walking around the agent's own AI-based code filter. Both are fixed in 3.0.1-beta.

CVE-2026-63377 is a first-run setup race with no referee. POST /api/auth/setup in src/api/routers/auth.py checks only the is_setup completion flag: no authentication, no one-time bootstrap token, no network restriction. The default docker-compose.yml publishes port 8001 on all interfaces, the Dockerfile binds 0.0.0.0, and the auth router is mounted without a global authentication guard — so initial_setup is reachable by anyone who can open a socket. It invokes create_auth_user with UserRole.ADMIN and returns a valid fctr_session JWT. Localhost-only CORS rules do not constrain non-browser HTTP clients, and setup requires no access to a real Okta tenant, so the attacker needs nothing except to arrive before the legitimate owner. The prize is total: read Okta-synced users, API tokens, chat history and configuration, modify users and Okta integration credentials, lock out administrators or disable the service. Completed setup is rejected — whoever gets there first owns the system permanently.

The AI filter was the only guard, and getattr walked around it

CVE-2026-63378 is the more instructive failure because the developers clearly tried. POST /api/react/execute-script accepts a script_code field that is stored with skip_discovery=True — bypassing AI-based content filtering — and passed to validate_generated_code in src/utils/security_config.py. That validator recognizes direct __import__ calls but misses the import name passed as a string; it allows getattr in ALLOWED_BUILTINS; and its AST checker handles ast.Name and ast.Attribute targets but not ast.Call targets. Dynamic getattr call chains through __builtins__ therefore sail through validation. The accepted code is written to disk by _write_temp_script and executed via asyncio.create_subprocess_exec() — as the application process user, which is root in the default container — with output streamed back as Server-Sent Events through GET /api/react/stream-react-updates?process_id=. Container compromise exposes Okta API tokens, the JWT signing key, and the SQLite database, with backend-service pivoting and persistence on top. A blocklist that cannot see through getattr is not a sandbox; it is a suggestion.

The disclosure lag is the real story

Here is the uncomfortable detail: the fix release v3.0.1-beta ("Secure the Harness") shipped on 30 June 2026, and the project has since moved through 3.1.x to v3.2.0-beta (22 September). The CVEs were only published on 30 October — a four-month gap between patch and public record. Anyone tracking this small project (57 GitHub stars at last check) by CVE feed rather than by release notes had no signal the whole time, and any deployment still sitting on v3.0-beta or earlier is running a network-reachable unauthenticated admin-creation endpoint on an Okta-connected box. This is the recurring tax on the long tail of AI agent tooling: the blast radius per deployment is enormous — Okta tokens, directory data, chat history — while the project's security communication runs at hobbyist speed. Note the thematic collision with Okta's own AI-agent identity sprawl problem: whether the agent comes from the vendor or the community, giving natural-language systems the keys to the directory keeps producing the same failure class. And the validator-bypass shape rhymes with the token-theft tooling now targeting coding agents — the agent ecosystem keeps assuming generated code is trustworthy enough to execute.

What to do

  • Upgrade to 3.0.1-beta or later now. Anything at or below v3.0-beta exposes both endpoints. If the setup endpoint was ever reachable from an untrusted network, assume the first-run race was contested: inspect the user table for unknown admins and rotate the JWT key.
  • Rotate everything downstream. Okta API tokens, integration credentials, and any secret the container could see. Container root plus Okta tokens means the compromise boundary is the whole tenant, not the host.
  • Do not expose setup endpoints, ever. Bind first-run flows to localhost, require a printed bootstrap token, and put routers behind a global authentication guard rather than relying on per-endpoint checks and CORS.
  • Replace AI-content-filtering of code with real isolation. Blocklists that miss getattr-through-__builtins__ and ast.Call targets will always lose. Execute agent-generated code in a sandbox with no ambient credentials, or not at all.

Sources: