Code injection in premsql followup worker enables code execution
TL;DR — A code-injection bug in premAI-io/premsql uses eval() on attacker-influenced data, enabling arbitrary Python code execution in the service context when the vulnerable follow-up path is reachable.
What happened
premsql is an open-source project from premAI-io focused on SQL/agent-style workflows (e.g., baseline “workers” that process intermediate results).
CVE-2026-5594 describes a code injection issue in premsql/agents/baseline/workers/followup.py where the function eval is invoked in a way that allows manipulation of the result argument, leading to execution of injected code. The source states the attack can be performed remotely and that a public exploit is available.
Although scored Medium (CVSS v3.1 6.3; CVSS v4.0 5.3), this is still an important class of bug for platform teams because eval() sinks frequently sit on high-trust execution paths in agentic/automation backends, turning “data flow” into “code flow” under attacker influence.
| Item | Source value |
|---|---|
| Affected versions | <= 0.2.1 |
| Patched versions | Not stated in the source |
| Public exploit | Yes (references include PoC links) |
| Vendor response | "The vendor was contacted early about this disclosure but did not respond in any way." |
Who is impacted
- Deployments running
premAI-io/premsqlversions<= 0.2.1. - Systems where an attacker can influence the follow-up worker’s
resultvalue (directly or indirectly via upstream inputs/outputs). - Higher-risk environments where the
premsqlprocess has access to secrets (API keys, database credentials) or is co-located with other sensitive services (common in AI/agent stacks).
What to do now
- Follow vendor remediation guidance if/when premAI-io publishes it (the source notes no vendor response at publication time).
- Inventory where
premsqlis deployed (repos, lockfiles, container images) and confirm whether you are at<= 0.2.1. - Reduce exposure until a verified fix is available:
- Avoid exposing
premsql-backed endpoints to untrusted networks. - Treat any path that can populate the
resultvalue as untrusted input and add strict validation/allowlisting at the boundary.
- Avoid exposing
- Use the referenced public PoC links to support internal testing and detection (e.g., reproduce in a sandbox to confirm reachability of the vulnerable code path).
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.