Execution control bypass in an extensible AI platform

#System context

The affected software is a widely used open-source AI application platform that supports extensible components and executable workflows; at the time of writing it had 152k GitHub stars and 22k forks (measured September 2026). Running code is an intended feature of the platform, not a defect.

Because that runtime executes code, some deployments enable an optional control meant to restrict dangerous operating-system operations. An operator enabling this control would reasonably expect it to prevent code in the extensible runtime from reaching restricted operating-system execution.

#What we found

The platform applies a validation layer before extensible code runs, blocking a defined set of dangerous operating-system operations.

We identified an equivalent execution path that was not in that restricted set. With the control enabled, code running inside the extensible runtime could still reach operating-system process execution. The restriction blocked particular interfaces, not the capability itself.

We reproduced this against the implemented control. The alternative path was available with the restriction active, and it reached the operation the control was written to prevent.

The validation layer runs inside the same execution context as the code it constrains. That makes it fundamentally weaker than an isolation boundary enforced outside the runtime.

#Security consequence

With the restriction enabled, arbitrary process execution remained reachable under the vulnerable execution conditions. That can expose:

• application secrets held by the process
• local files the process can read
• network-accessible resources reachable from the host
• the privileges the application process holds

When the extensible runtime executes on the application host, successful process execution inherits the reach of that environment rather than being contained inside a meaningful sandbox.

#Why the boundary failed

A denylist restricts the operations its authors anticipated. It does not automatically restrict equivalent ways of reaching the same capability.

Extensible runtimes typically expose several paths to powerful behavior. Treating a list of forbidden interfaces as an isolation boundary leaves that boundary dependent on whether every equivalent path was anticipated. The control blocked names, not capability. This is not a reliable isolation boundary.

A boundary intended to contain untrusted code should be enforced outside that code's own execution context: a sandbox, a separate process boundary, container or VM isolation, capability restrictions, syscall controls, or another mechanism that constrains the underlying capability rather than particular API names.

#Disclosure status

StatusResponsibly reported. Coordinated disclosure pending.

This is independent security research against public open-source software; the affected project is not a Themis customer.

We have not independently verified a remediation. This entry will be updated when coordinated disclosure is complete.

#Limitations

We reproduced the bypass against the implemented control with the restriction active. The alternative path reached the operating-system capability the control was intended to block.

We verified how the restriction is applied through source analysis rather than running the entire application deployment end to end. The finding therefore concerns the enforceability of the control itself, not a claim that every deployment is remotely exploitable. The restriction is optional; deployments that do not enable it were not relying on it.