Skip to content

A context-dependent compiler allow was cached and reused in contexts the rule denied

High
mlw published GHSA-9jm9-8xxf-87qj Aug 4, 2026

Software

santa

Affected versions

<= 2026.6

Patched versions

2026.7

Description

Summary

A CEL rule can decide an execution from dynamic properties of the invocation, such as its arguments or environment. Because the answer depends on that context, Santa correctly marks such a decision as applying only to the invocation that produced it.

When the decision granted compiler authority, that marking was discarded. The result was stored as a settled answer for the executable, keyed on its identity on disk. A later execution of the same file matched the stored answer and was allowed without the rule being consulted again, including in a context the rule denies. That execution also received compiler authority.

Whether an invocation is permitted and whether that answer may be reused are separate properties. Merging them let an answer that was only ever true of one invocation stand in for every later one.

Impact

A local user with no special privileges could run an executable under arguments or other context that policy denies, after one permitted invocation of the same file. The denied invocation runs with the user's own permissions, so this is not a privilege escalation.

The same execution is also marked as a compiler. Where transitive rules are enabled, a process holding compiler authority causes Santa to record durable allow rules for executables it produces, which turns a single denied invocation into standing permission for further code. The reporter demonstrated the execution bypass at runtime and established this downstream effect from the source.

Affected configurations

A deployment is affected when a CEL rule grants compiler authority conditionally, so that the same executable is permitted in one context and denied in another. Rules that grant compiler authority unconditionally are unaffected, because there is no context for a cached answer to contradict. Fallback compiler results are also unaffected, since Santa reduces those to an ordinary allow.

The transitive-rule consequence additionally requires EnableTransitiveRules, which is off unless a configuration profile or sync server turns it on.

The stored answer is tied to the executable as it exists on disk. It does not survive a cache flush, modification of the file, unmounting the volume it lives on, a daemon restart, or a reboot.

Granting compiler authority conditionally is an uncommon policy shape. Compiler authority is already a broad grant, and deployments that use it generally target build tooling regardless of how it is invoked. If you use compiler rules at all, check whether any of them are conditional.

What changes in 2026.7

A compiler decision that came from a context-dependent rule now authorizes only the invocation that produced it. Each later execution of the same file re-evaluates the rule.

Administrators using conditional compiler rules should expect executions that previously succeeded to start being denied, since those were the invocations relying on a reused answer. Rules that grant compiler authority unconditionally behave as before and continue to be cached.

Affected versions

Field Value
Affected Santa <= 2026.6
Fixed in Santa 2026.7
Severity High, CVSS v4.0 base score 8.2
CVSS CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
CWE CWE-863: Incorrect Authorization

Mitigation

Upgrade to Santa 2026.7 or later.

On affected versions, administrators can remove the exposure through policy:

  • Review CEL rules that return compiler authority conditionally. These are the only rules affected. A rule that grants compiler authority for every context is not.
  • Consider whether compiler authority needs to be context-dependent at all. Where the contextual test exists to narrow which invocations may mint transitive rules, splitting the executable into separately identified builds, or granting compiler authority unconditionally to a narrower identity, avoids relying on a per-invocation decision.
  • Confirm whether EnableTransitiveRules is on. It is off by default, and the durable-rule consequence does not apply when it is off.

Credit

Reported by OpenAI Codex Security, Jamie Brim (@jamieb-oai).

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Local
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity High
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity High
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N

CVE ID

No known CVE

Weaknesses

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

Credits