CVE-2025-46569: OPA REST API Path Injection Vulnerability
A security vulnerability related to Rego code injection via OPA’s API path was recently discovered in OPA by security researchers GamrayW, HyouKash, and AdrienIT. We appreciate their responsible disclosure which allowed us to address the issue promptly in the latest OPA release.
The vulnerability involves crafting specific HTTP request paths to OPA’s HTTP Data API, which can inject Rego code into the internal query OPA constructs for evaluation.
The vulnerability has been published as Security Advisory GHSA-6m8w-jc87-6cr7. This can also be found in the OPA project security advisories.
This post outlines the status, impact, and solution related to this vulnerability.
Status
Users are affected by this vulnerability only when one of the two sets of conditions below is met:
Scenario 1:
- OPA is deployed as a standalone server (i.e., not used as a Go library).
- AND the OPA server’s REST API is exposed outside of localhost to an untrusted environment.
- AND an Authorization Policy is configured but does not perform exact matching or sufficient validation on the input.path attribute of incoming requests.
Scenario 2:
- OPA is deployed as a standalone server.
- AND a service connecting to OPA allows potentially untrusted third parties to provide unsanitized input that is directly used to construct the path segment of an HTTP request to OPA’s Data API.
Important Considerations:
- Default Behavior: Since OPA v1.0, the server defaults to binding only to the localhost interface, significantly limiting exposure in default configurations.
- Authentication: Deployments in untrusted environments typically employ authentication. While authentication alone doesn’t prevent this vulnerability, it restricts potential attackers to authenticated clients with some level of trust.
- No Authorization Policy: If an OPA server is exposed without an Authorization Policy restricting API access (not recommended in untrusted environments), the existing broad access via the Data and Query APIs generally presents a greater risk than this specific vulnerability facilitates. Such configurations are not considered affected by this specific attack vector described in GHSA-6m8w-jc87-6cr7.
- OPA as a Library: Users leveraging OPA purely as a Go library (rego or SDK package) are not affected by this server-specific vulnerability.
We expect very few deployments meet the specific preconditions required for this vulnerability to have a practical impact.
Styra Declarative Authorization Service (DAS) customers are generally not directly affected by this vulnerability. Customers who have built custom integrations using standalone OPA servers exposed in potentially untrusted ways should review their configurations against the conditions outlined above. Please contact your CSM or support@styra.com if you need help with this, or have further questions.
Users of OPA Gatekeeper and Conftest are unaffected by this issue.
Impact
For the limited number of users potentially affected, the impact could include:
- Erroneous Decisions: Injected code could be crafted to force query success or failure, potentially leading to incorrect authorization decisions if the API response (true/false) is the basis for access control.
- Denial of Service (DoS): Injected code could be designed to be computationally expensive, consuming excessive resources and potentially leading to a DoS condition.
- Oracle Attacks / Environment Variable Exfiltration: In specific circumstances, it might be possible to craft injected code that accesses and potentially exfiltrates environment variables from the OPA host process, which could contain sensitive information.
The vulnerability stems from how OPA constructs a Rego query reference (e.g., data.path.to.resource) from the HTTP request path (e.g., /v1/data/path/to/resource). Malicious elements in the path could be misinterpreted as Rego code during this construction.
Solution
The issue has been fixed by Styra’s OPA team. Users potentially impacted are strongly recommended to upgrade to OPA v1.4.0 or later.
- Affected Release: Versions prior to OPA v1.4.0.
- Fixed Release: OPA v1.4.0.
- Affected Go Modules:
github.com/open-policy-agent/opa/v1/server,github.com/open-policy-agent/opa/server(only prior to v1.4.0).
If an immediate upgrade is not possible, consider the following workarounds:
- Limit Network Exposure: Ensure OPA server APIs are not exposed to untrusted networks. Utilize the default localhost binding unless external access is strictly necessary and appropriately secured.
- Enable Authentication: If exposing OPA, always require authentication to limit access to trusted clients.
- Implement Strict Path Validation: Configure an OPA Authorization Policy to rigorously validate the input.path. Ensure the policy explicitly allows only known, expected path structures, for example, by checking against an allow-list:
package system.authz
allowed_paths := [
["v1", "data", "policy1", "allow"],
["v1", "data", "policy2", "users", "user_id"],
# Add all other legitimate paths here
]
allow {
input.path in allowed_paths
}Alternatively, path validation and sanitization can be performed by intermediary services like API gateways or reverse proxies before the request even reaches OPA.
If you have any questions, feel free to stop by the Styra Community Slack.