[Security]Potential inconsistency in HTTP sandbox enforcement in radare2 6.2.2
Potential inconsistency in HTTP sandbox enforcement in radare2 6.2.2
Summary
A static review of radare2 6.2.2 raises a concern that HTTP command processing may not consistently apply the requested sandbox restrictions on process execution. The security question is whether those restrictions are intended to prevent process execution for commands accepted by the built-in HTTP service, and whether their enforcement is consistent across HTTP command handling.
This assessment is based on source inspection. No runtime reproduction, browser delivery test, or cross-platform validation has been performed.
Product and assessment scope
| Item | Assessment |
|---|---|
| Product | radare2, native application; radareorg/radare2 |
| Component | Built-in HTTP service and sandbox enforcement |
| Statically reviewed release | 6.2.2 |
| Reviewed commit | ad27058877024389292fddf12e1db6e13824ba34 |
| Release mapping | The official 6.2.2 tag resolves to the reviewed commit |
| Version coverage | 6.2.2 is suspected on static evidence; earlier releases and subsequent master commits have not been assessed here |
| Patched version | Not established for this finding |
| Proposed severity | High, conditional on the execution restriction being an intended security boundary and on the suspected enforcement failure being confirmed |
| CVSS | No numeric score assigned; reachability, privileges and interaction requirements remain unresolved |
| Proposed weakness | CWE-693: Protection Mechanism Failure, subject to confirmation |
The historical source review was recorded on 27 September 2026. The tag mapping and release metadata were checked on 30 September 2026. A release metadata check is not a new validation of the suspected behavior.
Security boundary and potential impact
The HTTP service must be enabled by the operator. Its availability to untrusted clients depends on the binding, authentication and surrounding deployment. Localhost binding alone does not establish a browser-mediated attack, and public network exposure is a separate deployment assumption.
The concern is specifically about enforcement of a requested execution restriction. If an untrusted client can reach the service and cause process execution despite that restriction, the resulting impact could extend to data and resources accessible to the radare2 process. This would not by itself establish elevated operating-system privileges.
The proposed High rating reflects that conditional impact. This report does not establish a default, remotely exploitable configuration, a successful browser attack, or unrestricted code execution across platforms.
Review areas and evidence limitations
The existing source assessment concerns the interaction between HTTP command handling in libr/core/rtr_http.inc.c and sandbox enforcement in libr/util/sandbox.c. The unresolved question is whether the intended restriction is preserved consistently during command processing.
There is no runtime output establishing that this boundary can be crossed, no validated platform coverage, and no comparison with a confirmed fix. The full affected range and behavior of current master are not established.
Related reports and requested clarification
Public reports #6415, #10564 and #4336 concern HTTP sandbox or HTTP request-security topics. They are potential overlap leads, not proof that this assessment is either a duplicate or a new vulnerability.
Please clarify the intended execution restriction for the HTTP service, whether this concern is already covered by a known issue or subsequent change, and which configurations and platforms are supported by that restriction.
If the restriction is intended as a security boundary, a remediation review should check consistent enforcement throughout command processing and fail-closed behavior when the restriction cannot be maintained. If some configurations are outside that guarantee, the documentation should make those limits explicit.
References
Source: radareorg/radare2