GHSA-r9q7-6784-7rc6: TAKO AI Agent for Okta: Authenticated Python execution through validator bypass
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 fctrsession cookie can submit arbitrary Python source in the scriptcode field of POST /api/react/execute-script, without administrator privilege. In src/api/routers/reactstream.py, the source is stored with skipdiscovery=True, bypassing AI-based content filtering, and is passed to validategeneratedcode in src/utils/securityconfig.py. BLOCKEDPATTERNS recognizes direct import calls but misses the import name passed as a string, getattr is in ALLOWEDBUILTINS, 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 writetempscript helper writes the accepted code to disk, and asyncio.createsubprocessexec() 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?processid=<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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
TAKO AI Agent for Oktato a version that resolves this vulnerability.Fixed in 3.0.1-beta
Event History
Frequently Asked Questions
Who can exploit this issue?
Any authenticated user who has a valid fctr_session cookie can exploit it. Administrator privileges are not required.
What access does successful exploitation provide?
An attacker can submit arbitrary Python through the execute-script endpoint, and the application executes the accepted code as its process user. In the default container, that user is root, so exploitation compromises the container.
Is the default deployment configuration affected?
Yes. The application process runs as root in the default container, making successful code execution root-level within that container.
How can an attacker retrieve command results?
Command output is returned through Server-Sent Events at the stream-react-updates endpoint using the process ID associated with the execution.
What version addresses the issue?
The issue affects versions prior to 3.0.1-beta. The referenced release for the fix is v3.0.1-beta.