CVE-2026-55830: RestrictedPython Sandbox Bypass via Positional-Only Arguments

Technical summary

RestrictedPython's check_function_argument_names() function performs validation to prevent embedding applications' access control policies from being bypassed via shadowing of guard hook names. Prior to version 8.3, the validation correctly rejected these protected names (including __getattr__, __getitem__, __write__, __print__) when used as regular, *args (variadic), or **kwargs (keyword-only) parameters. However, the check contained a logic gap: it did not validate positional-only arguments (those appearing before a / separator in Python function definitions). This omission allows an attacker to define a function like def foo(protected_name, /): ... and successfully bypass the guard, creating a local binding that shadows the sandbox's built-in protections and potentially enabling unauthorized object introspection, attribute access manipulation, or output interception.

Business impact

Applications that embed RestrictedPython to execute untrusted code—such as workflow automation platforms, data transformation pipelines, or user-defined rule engines—face a direct sandbox escape risk. A malicious or compromised script could circumvent the application's security policy to access restricted attributes, modify protected state, or intercept sensitive operations. The severity depends on what the embedding application exposes within the sandbox; in high-trust scenarios (e.g., multi-tenant SaaS), this could lead to cross-tenant data exfiltration or privilege escalation. The required high privilege level (PR:H) suggests exploitation needs authenticated or elevated context, reducing opportunistic exploitation but amplifying insider threat and supply-chain risks.

Affected systems

RestrictedPython versions prior to 8.3 are affected. The vulnerability applies to any embedding application using RestrictedPython as its sandboxing mechanism. No specific downstream products are listed in the advisory, so identification depends on scanning dependencies in your codebase or supply chain. Developers and security teams should audit their use of RestrictedPython and review application-level policies that rely on it for access control.

Exploitability

Exploitation requires high privilege (authenticated or elevated context within the application) and user interaction, which together limit the attack surface in typical deployments. However, the technical barrier is low once those preconditions are met—an attacker simply needs to craft a function definition using positional-only argument syntax to trigger the bypass. The presence of user interaction (UI:R) suggests the exploit must be triggered through application workflows rather than pure network attack, but this does not diminish the risk in systems where users are expected to author or upload code.

Remediation

Upgrade RestrictedPython to version 8.3 or later immediately. This version includes a corrected check_function_argument_names() that validates positional-only arguments alongside other parameter types. After patching, verify that your embedding application's security tests pass and that any code samples or user-supplied scripts continue to execute as intended. If immediate upgrade is infeasible, implement compensating controls at the application level to reject or inspect user-defined functions that use positional-only parameters.

Patch guidance

Update your RestrictedPython dependency to version 8.3 or later. If using package managers (pip, poetry, etc.), update your lock files and re-test your application. Verify the upgrade in a staging environment first, particularly if your application dynamically compiles or inspects function signatures. Check the RestrictedPython release notes and security advisory for any behavioral changes or deprecations. If you cannot upgrade immediately due to compatibility concerns, document the risk and establish a timeline for remediation.

Detection guidance

Monitor your codebase and dependencies for RestrictedPython versions < 8.3 using software composition analysis (SCA) tools. In runtime environments, inspect logs for attempts to define functions with positional-only parameters named __getattr__, __getitem__, __write__, or __print__; however, benign code may also use such patterns, so this should be context-aware. Review access logs of applications using RestrictedPython for unusual introspection or attribute access patterns that may indicate exploitation. Consider adding unit tests to your embedding application that explicitly verify RestrictedPython rejects these parameter names in all contexts, including positional-only arguments.

Why prioritize this

Despite the CVSS score of 8.3 (HIGH), this vulnerability merits urgent but not emergency prioritization. It requires high privilege and user interaction, which narrows the immediate threat. However, the simplicity of the bypass and its direct impact on sandbox integrity make it critical for any organization embedding RestrictedPython in multi-tenant or untrusted-code execution scenarios. Prioritize based on your exposure: if RestrictedPython is core to your security model, treat as critical; if it is one of many layers, sequence it within your normal patch cycle but do not defer.

Risk score, explained

The CVSS 3.1 score of 8.3 reflects HIGH severity: the vulnerability grants high impact on confidentiality (C:H) and integrity (I:H), meaning an attacker can read restricted data or modify protected state. The attack vector is network-accessible (AV:N) and requires low complexity (AC:L), but the high privilege requirement (PR:H) and user interaction (UI:R) reduce the overall score. The scope change (S:C) indicates the impact can cross trust boundaries. The availability impact is low (A:L), suggesting denial-of-service is not the primary concern. The score appropriately reflects a critical sandbox escape that is not trivial to exploit but poses severe consequences if triggered.

Frequently asked questions