CVE-2022-36085

Executive Summary

CVE-2022-36085 is a vulnerability in the Open Policy Agent (OPA) Rego compiler that allows a bypass of the deprecated WithUnsafeBuiltins security control. The WithUnsafeBuiltins function permits policy authors to specify a set of built-in functions that should be rejected by the compiler during the policy compilation stage. However, the with keyword — a feature introduced in OPA v0.40.0 — can be used to mock a built-in function without being evaluated against the WithUnsafeBuiltins set, thereby circumventing the restriction. The vendor has issued a patch in OPA version 0.43.1, and the vulnerability is assigned a CVSS score of 7.4, reflecting the range of conditions required to trigger an adverse effect. Organizations using OPA with restricted built-in functions in policy evaluation should prioritize upgrading to v0.43.1 or applying the recommended workaround.

Technical Analysis

Open Policy Agent is an open-source, general-purpose policy engine that uses the Rego policy language to define and enforce access-control policies. During the compilation phase, the Rego compiler can be configured with a security control called WithUnsafeBuiltins. This function accepts a set of identifiers representing built-in functions that should be considered unsafe. When the compiler encounters these functions during compilation (e.g., in a policy query or rule body), it raises an error and rejects the compilation. This is generally used to restrict the availability of potentially dangerous functions (e.g., those capable of external calls) to untrusted policy authors.

The bypass occurs in the interaction between WithUnsafeBuiltins and the with keyword. The with keyword in Rego allows a policy author to override or "mock" a built-in function's implementation — for instance, replacing http.send with a stub that returns a static value. The NVD description explicitly states: "the use of the with keyword to mock such a built-in function ... isn’t taken into account by WithUnsafeBuiltins." This means that the compiler's filter that rejects unsafe built-ins does not consider cases where the built-in is being mocked or overridden via the with clause. As a result, an otherwise-unsafe built-in can be referenced in a policy if it is wrapped in a with statement, bypassing the security control entirely.

Critical detail: multiple conditions must be met in order to create an adverse effect. The NVD description does not enumerate these conditions precisely. Inferred from the vulnerability class, these likely include: (1) the OPA deployment uses WithUnsafeBuiltins rather than the capabilities feature, (2) the policy author has the ability to submit or modify policy code, and (3) the overridden built-in would have had a security implication if left unrestricted.

Attack surface: The vulnerability is in the compilation phase, not necessarily at query-evaluation time. This means the attack requires a scenario where an untrusted party can supply or influence the policy source code that gets compiled. This is common in multi-tenant SaaS platforms that accept user-defined policies for collaborative filtering or tenant-specific authorization logic, and in CI/CD pipelines where policy-as-code is developed by multiple contributors with differing trust levels.

The risk is not that the built-in is arbitrarily executed — the with keyword mocks it, meaning the actual built-in implementation is not run. The risk is instead in the security-posture bypass itself: the WithUnsafeBuiltins control exists to reject a class of functions outright, and the with keyword allows those same functions to appear in the compiled policy, undermining the intent of the security boundary. The exact post-compilation impact depends on how the policy evaluation engine treats a mocked built-in — if the mock logic itself is attacker-controlled, it can produce policy-allowing results that would otherwise be forbidden by the control.

Exploitation Scenarios

No public PoC is available for CVE-2022-36085; the attack chain below is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance and target identification. The attacker identifies a target OPA deployment that uses the WithUnsafeBuiltins function to restrict built-in functions. This would be discovered via passive reconnaissance (identifying OPA endpoints, e.g., /v1/policies APIs in a service mesh or API gateway) or through public documentation of the target's policy-as-code workflow.

Step 2 — Triggering the flaw class. The attacker needs the ability to submit or influence a Rego policy that is compiled by the vulnerable OPA instance. In a multi-tenant or user-contributed policy scenario, the attacker submits a policy that references a restricted built-in function (e.g., one that would normally be rejected by WithUnsafeBuiltins) inside a with keyword clause. The compiler, failing to consider the with keyword in its safety check, accepts the policy instead of rejecting it.

Step 3 — Payload and execution at the vulnerability-class level. The payload is a Rego policy that includes a with clause referencing an unsafe built-in. Rather than executing the actual built-in, the attacker uses with to replace it with their own custom function or static value. For instance, a policy designed to permit access based on the status of an external service might instead have that check mocked to always return "allowed." At the vulnerability-class level, this is a validation bypass: the security control expecting to see and reject the unsafe built-in at compile time is foiled by indirection through the with keyword. The exact Rego expression is not specified in the NVD description.

Step 4 — Post-exploitation impact. Once the policy is accepted, the attacker's mocked built-in returns attacker-chosen values during evaluation. Depending on the policy logic, this can result in unauthorized access to resources, privilege escalation, or incorrect authorization decisions in the application relying on OPA. Since the control is a compile-time check, the bypass is persistent — every evaluation of the compiled policy uses the attacker's mock, as long as the policy remains loaded.

Impact Assessment

Business impact. A bypass of WithUnsafeBuiltins undermines a security boundary that organizations explicitly deploy to restrict policy authors. This is most dangerous in zero-trust architectures where OPA is the sole enforcement point for authorization decisions. A malicious policy author can cause the policy engine to reach decisions that the security team never intended.

CVSS correlation. The vulnerability is scored 7.4 (High). The vector (inferred, not officially published) is AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N — network-accessible, with high attack-complexity, no privileges required, no user interaction, scope unchanged, no confidentiality impact, high integrity impact, no availability impact. This aligns with the requirement for multiple preconditions and the integrity-focused nature of a policy-control bypass. Note that the official CVSS vector is listed as "N/A" in the intelligence data; the vector shown is an inferred approximation derived from the score and description.

Affected systems and blast radius. Any deployment of OPA using the WithUnsafeBuiltins function, running at a version before 0.43.1. Systems using the recommended capabilities feature are not affected. The blast radius is limited to multi-tenant environments or pipelines where multiple parties contribute policy code. Single-tenant OPA deployments where policy is imported solely from trusted internal teams are at substantially lower risk — the "multiple conditions" precondition makes exploitation unlikely there.

Exploit likelihood. The EPSS score is 0.01270 (67.2% percentile of exploited CVEs) — meaning that among known CVEs, this one has a relatively higher (though still low in absolute terms) probability of exploitation in the wild. There is no evidence of active exploitation, no CISA KEV listing, and no public PoC. The high attack-complexity condition tempers the likelihood of widespread automated exploitation.

Detection Guidance

Detection for CVE-2022-36085 is fundamentally about detecting anomalous policy compilation activity — specifically, policies that reference restricted built-ins via a with clause. The detection rules below should be tuned to the deployment environment.

Sigma Rule

title: OPA Policy Compilation with Unsafe Builtin Bypass
id: 6f8c2b1e-0c5a-4a1f-9be1-4d6a39127f94
status: experimental
description: Detects compilation of Rego policies that reference built-in functions in a with clause when the deployment uses WithUnsafeBuiltins. Detection occurs at the OPA audit log level.
author: Valtersit Threat Intel
date: 2025/04/08
logsource:
    product: open_policy_agent
    category: policy_compilation
detection:
    selection_unsafe:
        EventName: 'policy_compilation'
        Error: 'unsafe builtin'  # would appear if control active — miss indicates bypass
    selection_with_clause:
        EventName: 'policy_compilation'
        PolicyContent|contains: 'with '
    condition: selection_unsafe and selection_with_clause
falsepositives:
    - Legitimate policies mocking functions for unit testing in CI (should use capabilities feature instead)
level: high

YARA Rule

rule OPA_UnsafeBuiltin_WithBypass {
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects Rego policy source code referencing 'with' clauses alongside built-in function names commonly restricted by WithUnsafeBuiltins."
        cve = "CVE-2022-36085"
        date = "2025-04-08"
    strings:
        $keyword_with = "with "
        $keyword_import = "import rego.v1" ascii nocase
        $common_unsafe_1 = "http.send" ascii
        $common_unsafe_2 = "opa.runtime" ascii
        $common_unsafe_3 = "net.lookup_ip_addr" ascii
        $common_unsafe_4 = "time.now_ns" ascii
    condition:
        uint16(0) == 0x3C25  // checks for "%<" typical header start
        and $keyword_with
        and 1 of ($common_unsafe_*)
        and filesize < 200KB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-36085 OPA Rego Policy Upload with Unsafe Builtin Bypass"; flow:to_server,established; content:"/v1/policies"; http.uri; content:"with"; http.request_body; pcre:"/(http\.send|net\.lookup_ip_addr|opa\.runtime)/Ui"; classtype:attempted-admin; sid:3000001; rev:1; metadata:cve_id CVE-2022-36085;)

Elastic Detection

// EQL query for OPA audit endpoint events
sequence by host.name
  [ file where event.category == "file" and event.action == "write"
      and file.extension == "rego" ]
  [ file where event.category == "file" and event.outcome == "success"
      and file.extension == "rego"
      and process.executable == "/usr/bin/opa"
      and process.args == "build" ]
  | where process.args == "with" or process.args == "--with"

Splunk SPL Query

index=opa sourcetype=opa_audit
| where event_type="policy_upload" OR event_type="policy_compile"
| eval unsafe_bypass = if(match(policy_content, "with\\s+[a-zA-Z0-9_.]+") AND match(policy_content, "(http\\.send|net\\.lookup_ip_addr|opa\\.runtime)"), 1, 0)
| where unsafe_bypass=1
| stats count by host, source_user, policy_name, _time
| sort - _time

Wazuh OSSEC Rule

<group name="opa,">
  <rule id="120101" level="12">
    <decoded_as>json</decoded_as>
    <field name="event_type">policy_upload</field>
    <field name="action">compile</field>
    <regex>with\s+[a-zA-Z0-9_.]+</regex>
    <description>CVE-2022-36085: OPA policy compilation with 'with' keyword containing potentially unsafe builtin reference</description>
    <group>opensecurity_policy,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED). The vendor (via CNA) claims a fix in OPA v0.43.1, but this has not been independently confirmed by secondary sources in the provided intelligence data.

1) Immediate mitigations

• Discontinue use of the deprecated WithUnsafeBuiltins function.
• Follow the vendor's workaround: use the capabilities feature instead, which provides a whitelist/blacklist approach for built-ins and is not affected by this bypass.
• Restrict who can submit or modify Rego policy files in multi-tenant deployments. Add a manual code-review step for all policy changes.
• Monitor policy compilation logs for with clauses referencing restricted built-ins.

2) Patch/upgrade steps

• Upgrade OPA to version 0.43.1 or later as soon as feasible. Verify the upgrade in a staging environment before production rollout.
• After upgrade, run a regression test suite that specifically includes policies using with to mock built-ins, to confirm the control now rejects them.
• Audit existing deployed policies: enumerate any policy that uses the with keyword referencing a built-in, and manually review whether that policy was previously blocked by WithUnsafeBuiltins.

3) Long-term hardening

• Migrate completely from WithUnsafeBuiltins to the capabilities feature, which is the supported path forward and provides a more explicit allow-list mechanism.
• Implement policy signing and provenance. Only accept policy bundles that are cryptographically signed by trusted identities.
• Introduce a policy-as-code CI pipeline that runs static analysis against Rego source to flag any reference to restricted built-ins, including references embedded in with clauses.
• Enforce a policy-review gate requiring two-person approval for any policy change in production environments.

References

1. NVD Entry — https://nvd.nist.gov/vuln/detail/CVE-2022-36085
2. GitHub Advisory (CNA source) — https://github.com/open-policy-agent/opa/security/advisories (referenced advisory for CVE-2022-36085)
3. OPA Release Notes v0.43.1 — https://github.com/open-policy-agent/opa/releases/tag/v0.43.1 (patch version)
4. OPA Documentation — Capabilities — https://www.openpolicyagent.org/docs/latest/management/#capabilities (recommended workaround feature)
5. CISA KEV Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (not listed — verification reference)

Threat-actor evidence: No known campaigns or in-the-wild exploitation reported as of the intelligence cut-off date. EPSS percentile (67.2%) suggests prior scan or exploit attempts are not observed, and the required preconditions (use of deprecated WithUnsafeBuiltins, attacker policy submission, multiple conditions) make mass exploitation unlikely.