Summary
File Access Authorization lets an administrator restrict access to a path to a named set of processes. One selector, PlatformBinary, is meant to match only code shipped and signed by Apple as part of macOS.
Santa evaluated that check only for processes carrying a code signature. An unsigned process skipped it entirely and could satisfy an allow entry naming PlatformBinary as its only requirement, gaining access the administrator had reserved for Apple code.
The check had been grouped with the selectors that describe a code signature, which are correctly rejected for unsigned code. Whether the operating system considers an executable part of the platform is a meaningful question for unsigned code too, and the answer is simply no.
Impact
An unsigned local process could read data protected by an affected rule. The defect does not grant permissions the operating system would otherwise deny, and it is not an execution-policy bypass. An attacker still needs to get their unsigned process running, and still needs ordinary OS access to the target.
Affected configurations
A rule is affected when all of the following hold:
- The rule is enforced rather than audit-only, and protects a path the attacker can reach.
- One of its process entries names
PlatformBinary as its only effective selector.
- The attacker can run an unsigned process that already has OS-level permission for the target.
Selectors within a single process entry are conjunctive, so an entry that also specifies a Signing ID, Team ID, CDHash, certificate hash, or binary path is not affected. Separate process entries are independent alternatives, so an unaffected entry sitting alongside an affected one does not repair it.
The older TeamID=platform spelling is normalized to the same thing internally, so an entry written that way has the same exposure as one written with PlatformBinary.
Platform-binary-only entries were already a weak boundary
Platform binaries include the shells and general-purpose file utilities that ship with macOS. An allow entry naming only PlatformBinary therefore already permits /bin/sh, /bin/cat, and similar tools by design. Anyone with terminal access on the host could read the protected data through one of those permitted processes without relying on this defect at all.
The predicate should behave as documented, and the fix makes it do so. Even so, an entry that relies on PlatformBinary as its only selector does not provide a meaningful boundary in either direction. Treat this fix as closing a correctness gap rather than as making such a policy sound.
What changes in 2026.7
A PlatformBinary requirement now rejects every process the operating system does not report as a platform binary, unsigned processes included.
Expect access that was previously permitted to start being denied. If a workflow depended on an unsigned process reaching a path through such an entry, that entry needs a selector naming the process explicitly rather than relying on PlatformBinary.
Affected versions
| Field |
Value |
| Affected |
Santa <= 2026.6 |
| Fixed in |
Santa 2026.7 |
| Severity |
Medium, CVSS v4.0 base score 4.8 |
| CVSS |
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N |
| CWE |
CWE-863: Incorrect Authorization |
Mitigation
Upgrade to Santa 2026.7 or later.
Administrators can also remove the exposure through configuration, and doing so is worthwhile independent of this fix:
- Review File Access Policy entries for any process entry whose only selector is
PlatformBinary, including entries written as TeamID=platform.
- Narrow those entries with an additional selector such as a Signing ID or a binary path, so the exception names the specific Apple tooling intended rather than all platform code. This closes the defect on affected versions and produces a tighter policy on fixed ones.
Credit
Reported by OpenAI Codex Security, Jamie Brim (@jamieb-oai).
Summary
File Access Authorization lets an administrator restrict access to a path to a named set of processes. One selector,
PlatformBinary, is meant to match only code shipped and signed by Apple as part of macOS.Santa evaluated that check only for processes carrying a code signature. An unsigned process skipped it entirely and could satisfy an allow entry naming
PlatformBinaryas its only requirement, gaining access the administrator had reserved for Apple code.The check had been grouped with the selectors that describe a code signature, which are correctly rejected for unsigned code. Whether the operating system considers an executable part of the platform is a meaningful question for unsigned code too, and the answer is simply no.
Impact
An unsigned local process could read data protected by an affected rule. The defect does not grant permissions the operating system would otherwise deny, and it is not an execution-policy bypass. An attacker still needs to get their unsigned process running, and still needs ordinary OS access to the target.
Affected configurations
A rule is affected when all of the following hold:
PlatformBinaryas its only effective selector.Selectors within a single process entry are conjunctive, so an entry that also specifies a Signing ID, Team ID, CDHash, certificate hash, or binary path is not affected. Separate process entries are independent alternatives, so an unaffected entry sitting alongside an affected one does not repair it.
The older
TeamID=platformspelling is normalized to the same thing internally, so an entry written that way has the same exposure as one written withPlatformBinary.Platform-binary-only entries were already a weak boundary
Platform binaries include the shells and general-purpose file utilities that ship with macOS. An allow entry naming only
PlatformBinarytherefore already permits/bin/sh,/bin/cat, and similar tools by design. Anyone with terminal access on the host could read the protected data through one of those permitted processes without relying on this defect at all.The predicate should behave as documented, and the fix makes it do so. Even so, an entry that relies on
PlatformBinaryas its only selector does not provide a meaningful boundary in either direction. Treat this fix as closing a correctness gap rather than as making such a policy sound.What changes in 2026.7
A
PlatformBinaryrequirement now rejects every process the operating system does not report as a platform binary, unsigned processes included.Expect access that was previously permitted to start being denied. If a workflow depended on an unsigned process reaching a path through such an entry, that entry needs a selector naming the process explicitly rather than relying on
PlatformBinary.Affected versions
<= 2026.62026.7CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:NMitigation
Upgrade to Santa
2026.7or later.Administrators can also remove the exposure through configuration, and doing so is worthwhile independent of this fix:
PlatformBinary, including entries written asTeamID=platform.Credit
Reported by OpenAI Codex Security, Jamie Brim (@jamieb-oai).