AIMF Security Research · Report 1 of 2 · Original Finding
macOS Gatekeeper Revocation Bypass via Network-Layer Attacks
The original report: how an attacker on the same network could make an unreachable revocation check end in execution — and why the report was closed as intended behavior.
Published July–August 2026 · Full paper: github.com/aimarketingflow/macos-gatekeeper-revocation-bypass (PAPER.html + 5 figures) · This page is a summary and landing page for the follow-up: October 2026 Retest →
Abstract (condensed). The paper documents a vulnerability in macOS Tahoe's certificate
revocation enforcement that allows an attacker on the same network to bypass Gatekeeper's
"Malware Blocked" protection for applications signed with revoked Developer ID certificates.
The root cause is a triple failure: CRLite — Apple's offline bloom-filter revocation
system — was present in the
valid.sqlite3 schema but disabled via feature flags (UseCRLite is disabled); valid.sqlite3 contained zero Developer ID
certificate serials; and the fallback policy (rule 11) fails open when OCSP is
unreachable — allowing a revoked-certificate application to launch with only a bypassable
"unidentified developer" prompt instead of the non-bypassable "Malware Blocked" dialog.How the Attack Flows
How Certificate Revocation Actually Works
How It Was Found: Firewall-Based Constraint Analysis
The vulnerability was not found by reading code or fuzzing — it was found by constraining the system: selectively blocking security daemons' network access with a local firewall and watching which guarantees broke. That methodology turns "what does this daemon depend on" into a testable question, and it produced the causal chain:
| Step | Observation |
|---|---|
| Initial observation | A timed WrongPredictState error appeared when the firewall blocked security daemons — the first hint that trust evaluation was sensitive to network reachability |
| LuLu timeline correlation | Blocking windows correlated precisely with trust-evaluation failures, establishing the causal link between network denial and revocation blindness |
| From firewall to network attack | Once the dependency was proven, the same blindness was reproduced with attacker-controllable vectors: ARP-spoofed NTP and poisoned DNS |
Why Each Vector Works
NTP manipulation — ARP MITM lets the attacker control time. Clock drift
undermines timestamp validation across the trust chain: certificate validity windows, response
freshness, and cache expiry all become attacker-steerable. The paper documents drift accumulation
and its security impact (§2).
DNS poisoning — pointing the revocation hostnames anywhere but their
responder produces three-channel blindness (§3): OCSP queries are blocked, notarization
checks fail, and the offline channels that should compensate are empty or disabled. The machine cannot
get an answer — and, critically, has no local answer to fall back on.
WiFi-only simplification — the final variant (§7) needs no Thunderbolt
hardware at all: same-network DNS poisoning alone reproduces the bypass in ~5 minutes, which moves the
scenario from "lab rig" to "coffee-shop network."
The Three Attack Vectors
All three produce the same result. The discovery method itself — firewall-based constraint analysis — simulates network-layer attacks on macOS security daemons using a local firewall.
| Vector | Complexity | Result |
|---|---|---|
| Thunderbolt + NTP MITM (ARP spoofing, clock manipulation) | ~105 minutes | syspolicyd rule-11 fail-open engages when OCSP is unreachable → revoked-certificate app launches |
| Thunderbolt + DNS poisoning | ~5 minutes | |
| WiFi-only DNS poisoning | ~5 minutes |
The Triple Failure
1 · CRLite disabled. The offline revocation layer existed in the schema but the
feature flag was off:
UseCRLite is disabled (via feature flags) — captured July 24, 2026.2 · Empty coverage.
valid.sqlite3 held no Developer ID certificate
serials — nothing to check revoked status against offline.3 · Fail-open fallback. With OCSP unreachable and no local revocation data,
syspolicyd's rule 11 policy allowed the launch.
Proof: Side by Side
The proof-of-concept on video: the bypass running live, from the original disclosure. youtube.com/watch?v=4MXjfBAxc9I
Controls
| Control | Date | Result |
|---|---|---|
| Positive control — bypass confirmed | July 9, 2026 | Revoked-certificate app launched under attack conditions |
| Negative control — unnotarized app | July 7, 2026 | Rejected (the attack is specific to the revocation path) |
| Negative control — post-fix | July 14, 2026 (macOS 26.5.2) | Bypass no longer reproduced after OS update |
The Apple Exchange — Full Thread
The complete ticket thread — the original report, every rebuttal with log evidence, Apple's responses, and the final "working as expected" close — is preserved in the public evidence repository: Full ticket thread OE1107167498810 → (names redacted; technical content verbatim)
Disclosure Timeline — Apple's Responses, Verbatim
Response 1 (June 22, 2026): "This report was reviewed but it does not
outline or demonstrate a security vulnerability."
Response 2 (June 30, 2026): "Thank you for the additional exploitation
evidence. We looked at the full chain and the code execution comes from a curl-delivered binary that
never receives a quarantine attribute combined with a non-default VSCode auto-task setting, neither of
which is caused by the NTP time shift and neither of which Apple treats as a Gatekeeper bypass. The
OCSP and syspolicyd errors in the logs track the network disruption from the ARP spoofing rather than
the clock offset, so we don't see a security issue here and are closing the report."
Response 3 (July 14, 2026): "The scenario as described requires an
attacker to already control the victim's network, and the final step relies on the user explicitly
choosing to open the software despite a Gatekeeper warning. Because the software runs only after the
user affirmatively overrides that warning, the report does not demonstrate that a security boundary is
crossed without user consent."
The pattern: closed as not-a-vulnerability, then as user-consent,
while the positive control stood. The CRLite enforcement layer that would have prevented the outcome
sat disabled on the tested system. The follow-up report documents what changed afterward. verbatim quotes from the disclosure timeline
What Happened Next
In October 2026 the same artifact was re-tested on two current builds — macOS 26.7.1 and 27.0.1 — with radically different results. The fail-open did not reproduce in any tested condition, and the dormant CRLite layer was observed active on 27.0.1.