CVE-2026-27952 is a high severity sandbox escape (CVSS 8.8) in the custom code evaluator of the Agenta API, an open-source LLMOps platform. Authenticated users could run arbitrary code on the server. Versions before 0.48.1 are affected. Upgrade to 0.48.1 or later. The record does not mark it as exploited.
What's affected
The Agenta API (agenta-api) before 0.48.1. The fixed version is 0.48.1, per the GitHub advisory.
The record says this affects the self-hosted platform's API server, not the Agenta SDK used on its own as a Python library. It also notes that from version 0.60 the RestrictedPython sandbox was removed and replaced with a different execution model.
How to check if you're exposed
Find the version of the Agenta API in each deployment.
docker image ls | grep agenta
docker ps --format "table {{.Names}}\t{{.Image}}"
Read the image tag, and check your compose or deployment files for the pinned version. If you build from source, check the release you built from.
Then list who holds accounts on your instance. The flaw needs a signed in user who can define a custom code evaluator, so the exposure is in your user list.
What to do now
- Upgrade the Agenta API to 0.48.1 or later. The advisory notes that later versions, 0.60 and above, replaced the sandbox entirely.
- Review which users can create or edit custom code evaluators, and remove access that is not needed.
- Treat the API server as potentially exposed if untrusted users had accounts. Rotate secrets that the server can read, such as model provider keys and database credentials.
- Run the API with the least privileges you can, in a container with a restricted network.
- Review evaluator code that exists in your instance and remove anything you do not recognise.
Why it matters
The record says the evaluator ran user supplied code inside RestrictedPython, and the numpy package was wrongly placed on the allow list. That gave an authenticated user a route out of the sandbox into unfiltered system functionality. The fix removes numpy from the allow list. NVD classifies the flaw as CWE-94 (Improper Control of Generation of Code).
The broader point is that language level sandboxes are hard to get right. An allow list is only as safe as every module on it, and a large library can expose parts you never meant to hand over. Running untrusted code in a separate process or container with strict limits is a stronger boundary.
Understanding the boundary
Agenta lets users write their own evaluator code and runs it on the server. That feature needs a sandbox, and the project used RestrictedPython. A sandbox like this works by allowing a short list of safe modules. The record says numpy was placed on that list by mistake, and numpy exposes introspection utilities that reach well beyond what the sandbox intended. The fix removes numpy from the allow list.
Who is exposed
The flaw needs an authenticated user, so the first question is who has accounts. A private deployment for a small trusted team has a smaller risk than one open to many users or tenants. The CVSS vector reflects this, with privileges required rated low but not none.
Containing the damage
If the API server was exposed to untrusted users, think about what the process can read. It may hold database credentials, model provider API keys and storage tokens in its environment. Rotate them if you cannot rule out misuse, and review provider usage logs for unexpected activity.
Run the API in a container with a read only file system where possible, drop unneeded capabilities, and block outbound network access that the service does not need.
Moving off the sandbox
The record notes that from version 0.60 the RestrictedPython sandbox was removed and replaced with a different execution model. If you are on an old release, upgrading past 0.60 retires this whole design, not only this bug. Read the release notes for any behaviour changes to your evaluators before you do.
After upgrading
Check the running image tag, then run an existing evaluator to confirm it still works. Remove evaluators nobody owns.
Questions to ask your team
Do we need user supplied evaluator code at all? Who approves new accounts? Could this API server reach systems it does not need to? The answers shape how much a sandbox escape could cost you, whatever version you run.
Writing it up for your team
Record the deployed version, the fix version and who has accounts on the instance. List the secrets the API server can read and note whether you rotated them. Add a date to re-check, and a note about the sandbox removal in later releases so a future upgrade has context.
Try it yourself
Self-hosted tools often arrive as container images. This demo shows what an image scan reports.
Click through it at your own pace, or open it full screen.
Quick check
Do I need an account to exploit this?
Yes. The record says authenticated users can bypass the sandbox, and the CVSS vector requires low privileges.
Is the SDK affected?
The record says it affects the self-hosted API server, not the SDK used as a standalone library.
Sources
Last reviewed: 19 October 2026.
