QWED Math Verification Endpoint Unsanitized SymPy Eval Leading to RCE

Technical Analysis

The /verify/math and /verify/batch endpoints accept a caller-controlled 'expression'/'query' field intended for deterministic math verification of agent tool calls, but forward it to SymPy's parse_expr() without a restricted global_dict/local_dict, meaning parse_expr's internal use of eval() can resolve Python builtins and execute attacker-supplied code. The only sanitization applied is a cosmetic regex substitution for implicit multiplication, which provides no security boundary. Because POST /auth/signup and POST /auth/api-keys are enabled by default and unauthenticated, an attacker can self-provision a valid tenant API key, satisfy the get_current_tenant check, and reach the vulnerable parse path with no privileged access required. This crosses a critical trust boundary: a component meant to sandbox and verify LLM/agent outputs before execution becomes itself an unsandboxed code execution primitive, enabling file read/write, OS command execution, service disruption, and cross-tenant compromise in shared/multi-tenant deployments.

Affected Systems

QWED (qwed package, src/qwed_new)

Detection Signatures

• POST /verify/math or /verify/batch requests containing expression/query fields with Python builtin references (e.g. __import__, __builtins__, os.system, eval, exec, open() calls)
• Unexpected outbound process spawning or file system access originating from the QWED API server process following a /verify/math or /verify/batch call
• Sequential API calls: POST /auth/signup followed immediately by POST /auth/api-keys and then POST /verify/math from the same source IP
• SymPy parse_expr() invoked with default global_dict/local_dict in server logs or code review
• Spike in tenant signups from unfamiliar sources shortly before anomalous verification requests

Remediation Steps

1. 1

   Upgrade QWED

   Update to qwed version 5.1.2 or later, which restricts parse_expr() namespaces and remediates the vulnerable code path.

2. 2

   Restrict parse_expr namespaces

   If patching immediately is not possible, wrap all SymPy parse_expr() calls with explicit, minimal global_dict/local_dict that exclude builtins and disallow arbitrary attribute/function resolution.

3. 3

   Disable open signup

   Disable or gate POST /auth/signup and POST /auth/api-keys behind admin approval or invitation so untrusted parties cannot self-provision tenant credentials.

4. 4

   Sandbox verification workloads

   Run math/expression verification in an isolated, resource-limited sandbox (container/subprocess with no filesystem or network access) separate from the main API server process.

5. 5

   Enforce tenant isolation

   Ensure per-tenant process/resource isolation in shared deployments so a compromised tenant cannot access or affect other tenants' data or the host service.

6. 6

   Audit and rotate credentials

   Review logs for suspicious signup/API key issuance and /verify/math or /verify/batch activity; rotate all API keys and audit for signs of prior exploitation.