GhostLock + Git Signature Spoofing: Two Trust Boundaries Fell at Once
Under the Hood
The subtle break hits CI pipelines that look bulletproof. Git treats a signed commit hash as two things at once: authorship attestation and unique identifier. New research shows those are separable. Take a developer's valid signature. Mint a different commit with a different hash that the signature still validates. No signing key required. A deployment gate that asks 'signed by an authorized dev?' and trusts the hash as canonical is bypassable. I'd test that gate before I trusted it.
GhostLock (CVE-2026-43499) is blunt. A 15-year-old flaw lets any authenticated user escalate to root and escape the container on most Linux distributions. On unpatched kernels, self-hosted GitHub Actions/GitLab/Jenkins runners executing external-contributor code, multi-tenant Kubernetes nodes, and shared hosting all hand every user root. This is a different class from last week's Januscape KVM escape. That one lived at the hypervisor. This one is userland-to-root inside your own fleet.
In Your Stack
The mechanism is the same both times: verification you inherited from a platform is not the boundary you assumed it was. For provenance, put the check somewhere Git can't be the single point of trust. An independent record works: Sigstore/Rekor transparency logs, SLSA provenance attestations. Build integrity then stops resting on the commit hash alone. For GhostLock, the fix is patch velocity. Shared CI runners are P0 because they run untrusted code on the assumption that isolation holds. Patch those first.
On an unpatched kernel, 'container' is a naming convention, not a security boundary.
What to do
Audit kernel versions across all production nodes and container hosts for CVE-2026-43499 this week, patching shared CI runners and multi-tenant clusters first
Remove Git 'Verified' badge status as a sole deployment gate this sprint and add SLSA provenance or Rekor transparency-log verification as an independent check