BadGarbage (CVE-2026-53361): why product security needs real-time exploit and PoC intelligence

If you take away one thing from this post: working exploit code for CVE-2026-53361 was public for eighteen days while every channel a product-security team routes by — the CVE record, NVD, vendor trackers, upstream — stayed silent, late, or wrong. The only signal that was correct, precise, and on time was the exploit and PoC code itself. This is the case for wiring a real-time source of the latest exploits and PoCs into your triage; everything below is the evidence.

The bug, in one paragraph: a use-after-free in the AF_UNIX socket garbage collector, rated CVSS 7.1 HIGH, local-only. Two independent working exploits are public as of this writing — Google’s kernelCTF submission (merged 28 August) and an independent PoC (published 11 August) that describes itself as an unprivileged container escape. It is the only 2026 CVE among all 111 kernelCTF submissions to date.

And the conventional record: no oss-security thread, no vendor advisories, no press coverage — the only write-ups were the researchers’ own. The Hacker News submission drew 13 points and no comments. NVD lists no exploit reference to this day.

The risk

There is no remote attack vector. This is never an initial-access bug: the trigger is ordinary socket calls from an attacker already running unprivileged code on the machine — socket(), sendmsg() with SCM_RIGHTS, recv() with MSG_PEEK. No capabilities, no user namespace, no special hardware. What it buys is a use-after-free on a live kernel socket object — the classic starting point for escalation to root.

Two data points on how practical it is:

• The kernelCTF submission reports ~99% success across 100 runs against an LTS kernel (6.12.93), self-contained, no separate KASLR leak. kernelCTF submissions must demonstrate full compromise of a hardened instance to qualify — this is a working exploit, not a crash reproducer. Its metadata lists CONFIG_UNIX as the only precondition, with an empty capability and attack-surface list.
• The independent PoC claims an unprivileged container escape, naming Ubuntu 24.04 HWE, RHEL 10, Debian trixie and CentOS Stream 10 among its targets, and claims 6.12 kernels up to 6.12.94 (the researcher’s own claims; we have not run it). Note what follows: disabling unprivileged user namespaces — a common container mitigation — does not take this away.

How this could happen

UNIX-domain sockets can be passed through other UNIX-domain sockets via SCM_RIGHTS, which makes reference cycles possible — so the kernel runs a periodic garbage collector over in-flight sockets, with a flag named gc_in_progress recording whether a collection is running.

• January 2024: a commit sets that flag in the wrong place — in the function that schedules the collector rather than in the collector itself. Two threads can both observe the flag as false and both queue a collection; the second then runs while a collection is in progress but the flag reads false. At the time this is harmless: nothing depends on the flag but scheduling.
• March 2026: a fix for CVE-2026-23394 — a 4.7-rated bug in the same subsystem, reported by the same researcher — makes that flag safety-critical. The problem it fixes: MSG_PEEK silently takes fresh references on in-flight files without the collector’s bookkeeping, so the collector can trust a stale refcount and judge a live socket dead. The new code invalidates that check before acting — but only when gc_in_progress reads true. The two-year-old race supplies exactly the state where it reads false while a collection is running. The collector trusts the stale refcount, frees a live socket group, and leaves an open descriptor pointing at it. That is the use-after-free.

The uncomfortable part: each patch was individually correct. The defect exists only in the composition of two changes two years apart — the 2024 patch was right against the 2024 tree, and the 2026 patch was reasonable if the flag meant what its name says. Change-scoped review, human or automated, answers “is this change correct?” well and “which assumption did this change quietly promote from convenience to safety-critical?” badly. The upstream trail confirms nobody was positioned to notice: the fix’s mailing-list thread is two messages long — the patch, and the bot announcing it had been applied. No review tags, no human reply, the words “security,” “use-after-free” and “CVE” nowhere in it, no Cc: stable. The fix sat in mainline for two months until the researcher himself filed the stable backport requests on 29 June — and for the 6.19 and 7.0 branches, that request arrived after they had already reached end of life, which is why they never got the fix at all. The CVE was assigned only on 4 July, on request. You acquired this vulnerability by installing the fix for the previous one.

The timeline

On 29 August — eighteen days after the first exploit — Red Hat rated RHEL 10 Important (7.8) with no errata shipped; SUSE’s overall state was “Pending”; Ubuntu held priority medium with no USN; Debian trixie was fixed (DSA-6381-1) but bookworm sat behind at 6.1.180. Amazon illustrates the version-number trap from the other side: its default AL2023 kernel reads 6.1.177 — below upstream’s 6.1.183 fix release — yet already carries the patch, cherry-picked into the build per its own advisory. You cannot tell fixed from vulnerable on a vendor kernel by version number alone. Attackers reading GitHub had working code on 11 August. If your remediation SLA starts when a tracker turns green, you started eighteen days later — on the fleet the exploit names as its target.

The published affected-version ranges were wrong in the same direction — quietly, and in both ways at once. We read net/unix/garbage.c at every relevant release tag and tested two questions: is the dependency present, is the fix present:

Read the middle two columns as a window: exposure opens where the dependency lands and closes where the fix lands. On 6.1 that window is empty — the dependency and the fix shipped in the same tarball, 6.1.183, so no 6.1 release was ever vulnerable; before it, 6.1 carried the mis-placed flag with nothing depending on it. Roughly 42 releases of 6.1 and 49 of 6.6 are marked affected that never contained the vulnerable code path; on 6.19 and 7.0 there is no fixed release to move to at all. Two checks say the narrow reading is right, and one of them is the exploit record: the kernelCTF submission targets 6.12.93 and the PoC claims up to 6.12.94 — inside the three-release 6.12 window, not the twenty months the CNA range covers (the other check: the fixed versions of CVE-2026-23394 — 6.1.183, 6.6.142, 6.12.92, 6.18.23 — line up exactly with where exposure begins). Do not read this as “older is safer”: a kernel without the dependency is exposed to CVE-2026-23394 instead, which is Debian bookworm at 6.1.180’s situation. And expect tooling noise: NVD’s CPE range for 6.1 (< 6.2 where the CNA wrote < 6.1.183) flags every patched 6.1 kernel in the world as vulnerable.

What a real-time exploit and PoC source buys you

Three things, all demonstrated on this one CVE. A corrected impact assessment — the CVSS callout above is an impact analysis frozen before the exploits existed, and the exploits revised it the day they landed. Ground truth on versions — exploit authors state exactly what they ran against, and the disagreement with the advisory ranges is what flags the real 6.12 window. An honest clock — the threat became real on 11 August, and only the exploit repositories said so, for eighteen days.

This is why we ship exploit-maturity tracking. The mechanism is deliberately dull: three curated sources — Google’s kernelCTF, kernel-exploit-factory, and a public PoC index — polled continuously, every sighting keyed on the CVE id the source itself asserts. No model, no star counts; index sources can only ever earn the weaker PoC label, curated exploit repositories earn Weaponized, and CISA KEV stays a separate signal because “code was published” and “this is being used against people” are different claims. Corpus as of 29 August: 318 sightings across 199 CVEs — 132 weaponized, 67 PoC; kernelCTF coverage 111 of 111. The badge is public; the proof links need a verified account, not a paid plan, because the people who act on a weaponized badge are the ones who most need to check our work. The signal travels with the VEX export, so it reaches your Dependency-Track instance the same day it changes. What it deliberately does not do is change applicability — public code cannot make a disabled subsystem reachable, and for this CVE that doesn’t help you: CONFIG_UNIX is on every general-purpose Linux system in existence, so this is a patch-or-accept CVE.

The takeaway

CVE-2026-53361 will be forgotten in a month; the pattern will not. Exploit code publishes before advisories, trackers and scores catch up — and on the CVEs that matter most, the gap is measured in weeks. A product-security process needs a real-time source of the latest exploits and PoCs joined into triage the same day, because here that feed was the only signal that was simultaneously correct, precise, and timely.

Concretely, for this CVE:

1. Check your point release, not your branch. Fixed at 6.1.183, 6.6.144, 6.12.95, 6.18.38 and 7.1. On 6.19.x or 7.0.x there is no fixed release — only a branch migration.
2. If below the fix, check whether you are above the dependency (6.6.142, 6.12.92, 6.18.23). Below both, this CVE is not reachable — but its predecessor is, so update anyway.
3. Ask who can run code on the box. Container platforms, CI runners and multi-user hosts are the exposed shapes; a sealed appliance is a scheduled update, not an incident.
4. Do not read fixedness off a version number on vendor kernels. Amazon’s 6.1.177 carries the fix; upstream 6.1.183 is where it landed. Read the advisory, not the semver.
5. Expect your scanner to be wrong on 6.1 specifically — NVD’s CPE range flags every patched 6.1 kernel as vulnerable.
6. Expect this pattern again. The next BadGarbage will not announce itself through an advisory either — make sure your feed is watching where the exploits actually publish.

Upload a kernel .config and KernelScan will tell you which of your CVEs are actually present in the code you compiled, which have public exploit code today, and which point release fixes each one on the branch you actually ship.

References

• Upstream commits — the fix d82ba05263c6, the commit it repairs 8b90a9f819dc, and the dependency e5b31d988a41 — the fix for CVE-2026-23394, scored 4.7 by NVD.
• CVE records — the kernel CNA record in CVEProject/cvelistV5, including the per-metric CVSS justifications quoted above; NVD’s entry and its CPE configuration; the kernel CVE team’s announce of 4 July 2026.
• Exploit sources — the kernelCTF submission’s metadata.json (exp533), and the public PoC repository.
• Kernel releases — stable tags v6.1.183, v6.6.144, v6.12.95, v6.18.38 and v7.1 with their kernel.org ChangeLogs, and the end-of-life dates for the 6.19 and 7.0 branches.
• Vendor trackers — Red Hat, SUSE, Debian, Ubuntu and Amazon Linux (ALAS2023-2026-1969, -2014, -2032), all read 29 August 2026.

The per-release exposure table is our own analysis — source read at each stable tag, not taken from any advisory — and the two cross-checks described above agree with it. We have not run either exploit; claims about what they achieve are the researchers’ own, as published.