Date: 2026-06-13 | Target: fleetdm/fleet @ HEAD (post-CVE-2026-46371) | Result: WALK CLEAN (no finding) | Method: white-box set-difference (no stack needed for a no-finding conclusion)
Two ORDER BY oracle advisories on Jun 11 (GHSA-x4qr Apple-MDM-commands, GHSA-vxm7 labels-host-listing; CVE-2026-46371, patched 4.84.2): an order_key interpolated into ORDER BY over a secret-joining query (hosts/nano_enrollments) lets an Observer binary-search node_key/APNS tokens via the after cursor. Classic two-endpoints-of-a-class = incomplete-coverage bait.
The patch added a CENTRALIZED secure path: appendListOptionsToSQLSecure / AppendListOptionsWithParamsSecure taking an OrderKeyAllowlist (maps user keys -> safe column exprs). Set-difference {insecure callers} vs {secure callers}: 35 secure callers; base insecure appendListOptionsToSQL has ZERO real callers (fully migrated); every SECRET-bearing endpoint uses the allowlist (hosts.go hostAllowedOrderKeys/batchScriptHostAllowedOrderKeys; vulnerabilities.go allowlist on inner+outer; the 2 disclosed endpoints). Lone residual insecure path = software.go:2142 appendListOptionsToSelect (goqu + syntax-only SanitizeColumn) BUT its query joins only software/CVE INVENTORY tables - no secret column reachable, and that data is observer-readable anyway. software.go:1692 (optimization gate, hardcoded hosts_count) and software_titles.go:567 (switch, not interpolation) are safe.
The set-difference primitive flags every call site NOT on the secure path. But a flagged site is only a FINDING if its SINK reaches something the actor can't already get. Weight each residual by: (a) does the query JOIN a secret/cross-tenant table the order key can name? (b) is the leaked data otherwise unreadable by this actor? Gitea-feed / Filebrowser-delete were real because the residual reached private data the actor lacked. Fleet's residual (software.go:2142) reaches only inventory the observer can already list -> no privilege gain -> not a finding. Same discipline as the Gitea label-IDOR prune: unguarded path + sink-doesn't-reach-secret = prune, don't overclaim.
Incomplete-fix YIELD correlates with fix ARCHITECTURE: - Per-handler, secret-reaching residual -> FINDING: Gitea feeds (token-scope), Filebrowser resourcePostHandler cleanup RemoveAll. - Centralized/allowlist fix, residuals don't reach secrets -> CLEAN: Fleet (allowlist on all secret endpoints), MinIO (DenyOnly central override), Vaultwarden (resolver on every connect). The cheap predictor: grep whether the fix is a central choke-point/allowlist vs per-call-site, AND whether any non-migrated residual reaches a secret/cross-tenant sink.
White-box only (Fleet's full stack = MySQL+Redis+server, too heavy for the 1.9GB box). Sufficient for a WALK CLEAN (no vuln claimed, so no run-before-claim violation). A live oracle PoC would need the stack; not warranted since the secret-bearing endpoints are allowlisted.