After the Gatekeeper Fail-Open Report: The October 2026 Retest

The original report documented a fail-open that let a revoked-certificate app execute. Re-tested on macOS 26.7.1 and 27.0.1, the app did not execute — in any condition. This report maps what changed, what it means, and what remains unresolved.

Companion page: the original report (August 2026) → · Full paper + evidence: github.com/aimarketingflow/macos-gatekeeper-revocation-bypass · Change discovered incidentally while testing OpenDLP against macOS 27's reworked EndpointSecurity framework — not through targeted follow-up on the original report.

The Questions the Retest Asked

1. Does the fail-open still execute? With the revocation responder unreachable, does a revoked-certificate app still run — as it did in July?
2. Is the verdict stored — and where? If blocked, which local store held the revoked status, and can removing it restore execution?
3. Does the memory of revocation expire? A cached OCSP response has a nextUpdate deadline. Is it still enforced weeks past that deadline, offline?
4. Did the dormant layer wake up? The paper documented CRLite present but disabled. Is it still disabled — and does it change the outcome?

Results at a Glance

Historical and current tests used differing cache conditions and artifact versions — this is not a matched comparison of builds. "DMG opened" and "app executed" are separate enforcement stages and are reported separately throughout.

The Machine Remembers the Verdict

The central technical lesson of the retest: "the cache" is not one thing. Revocation verdicts persist in several independent local stores, and — unlike a speed cache — they are enforced offline, without any responder contact. That is precisely why the historical fail-open no longer reproduces: an unreachable responder used to mean "no answer"; now it means "enforce the last answer on file."

Resetting one store is not resetting the machine's memory of the verdict.

Pro Investigation (26.7.1): Clearing the Cache Didn't Restore Execution

Recovery-mode surgery identified and removed the target's revoked OCSP response (ocspcache.sqlite3, certStatus=1) and cleared bulk validity data. On retest with a fresh trustd process, the app was still refused — some other local source held the verdict. Live queries found the certificate's serial and SHA-256 absent from the 73,711-row bulk valid list; whether that absence is itself an enforcement input (an absence-based fail-closed mechanism) remains a hypothesis — absence from one queried table does not establish the lookup path.

Source: reports/2026-10-09_TEST_RESULTS_CONSOLIDATED.md, reports/2026-10-09_FRESH_STATE_VERDICT.md in the evidence repository.

Air Investigation (27.0.1): The Stale Verdict, Enforced

The Air's cached-state test produced the cleanest mechanism evidence of the retest:

OCSPSingleResponse: nextUpdate 65.74 days ago
OCSP status revoked=1 definitive=1 fetchFailed=0 timedOut=0
cert[0]: Revocation =(leaf)[force]> 6
Trust evaluate failure: [leaf Revocation6]

The stored answer was ~66 days past its own freshness date, the responder was unreachable, and the system enforced the last answer on file anyway: the app launch was refused. The October 16 sysdiagnose shows the same cached verdict at 72.96 days past nextUpdate — still enforced, with sibling evaluations showing fetchFailed=1 (responder unreachable at eval time).

Source: evidence/air-2026-10-09_offline-retest-evidence.txt, evidence/air-2026-10-16_dmg-block-evidence.txt.

Two Stages, One Verdict — and an Open Question

The builds refused the target at different stages: the Pro rejected the DMG container itself (malware-class dialog, reported); the Air typically mounted the DMG and refused the app. Sysdiagnose evidence from October 16 shows the Air can also fire the DMG-stage malware block (XProtectMalwareType = 10, four evaluations that day) — so both enforcement paths exist on 27.0.1, and what varies is which stage fires.

The October 16 Run, Minute by Minute

The newest Air sysdiagnose captured the exact sequence behind the current screenshots — one evaluation chain, from mount attempt to denial, with the machine offline:

Source: evidence/air-2026-10-16_dmg-block-evidence.txt, extracted from sysdiagnose_2026.10.16_17-46-55-0400_macOS_Mac_26A434.tar.gz. The evidence supports a real denial sequence but does not by itself prove whether every denial was caused by the stale OCSP response, CRLite, XProtect, or an interaction among them — the stale revoked OCSP result is the clearest direct revocation input.

The Deployment Change: CRLite Is Active on 27.0.1

The paper's §5 documented CRLite as the obvious missing defense: infrastructure present, feature flag off. The retest's runtime captures show the flag state flipped between the two eras:

July 24, 2026 capture:   UseCRLite is disabled (via feature flags)
Oct  9, 2026 capture:    UseCRLite is enabled  (via feature flags)

Apple's published source (Security · SecRevocationServer.c L646–668) shows the gate: when the enforcement predicate is false, the function returns before a CRLite "revoked" verdict is ever applied — the verdict exists but never reaches its consequence. When true, the verdict becomes a formal trust failure and is logged (Enforcing CRLite result).

What the Evidence Establishes

What Remains Unresolved

The Apple Exchange

The full ticket thread behind the original report — including Apple's July 28 "intended behavior" response (which confirmed the cached-revoked-response pinning the retest later observed directly) and the August 25 close — is preserved in the public evidence repository: Full ticket thread OE1107167498810 →

Timeline — and Why This Was Published Anyway

Evidence Index