The whole public evidence base for this morning's Falcon zero-day is 744 characters, and two of its sentences did not survive the retelling.

A researcher published working exploit code this morning for an unpatched local privilege escalation in CrowdStrike Falcon Sensor. The repository was created at 02:48 UTC and had 201 stars within hours.

There is no CVE. NVD returns zero results for CrowdStrike Falcon across the last three months. The KEV catalogue has never contained a CrowdStrike entry. There is no vendor advisory.

So the entire public evidence base for what is being reported as a zero-day is a repository of compilable code and a README of 744 characters.

That README is worth reading in full, because it contains two qualifications the coverage has dropped, and the author put both of them there himself.

The two sentences the headlines skip

The first is a precondition. In his own words, it "works in a fully updated windows 11 25H2 / Windows Server 2025 with Crowdstrike Falcon - Phase 3 Optimal Protection + needs 'Microsoft Office file malicious macro removal'".

That is a specific remediation feature, and it has to be enabled. This is not "Falcon is vulnerable". It is a flaw in one function, reachable only where that function is switched on.

The second is stranger, and it appears in the same sentence as the disclosure:

"obviously by the time I drop this Crowdstrike would already have detections for it so if you want to test you either have to add it to the exclusions or obfuscate the PoC and change the dll load technique."

Read that carefully. The author is saying that to make the published code work you must first add an exclusion for it or rewrite it. Which is a statement that, as published, it does not work against a default deployment.

Nobody has verified that either way. CrowdStrike has published nothing, and the researcher's claim about his own detections being caught is as unverified as the exploit. But it is his claim, in his own README, and it is the first thing lost in the retelling.

What is actually established

The whole evidence base, itemised

Question	Answer
Is there working code?	Yes. A C++ source file and a Visual Studio solution, published 02:48 UTC on 3 September 2026
Is there a CVE?	No. NVD returns zero results for CrowdStrike Falcon over the last three months
Is it in KEV?	No, and the catalogue has never held a CrowdStrike entry
Is there a vendor advisory?	None published at the time of writing
Is there a technical write-up?	No. The README is 744 characters and a screenshot
Does it work by default?	The author says no. He states testers must add an exclusion or obfuscate the code, because detections exist
What does it require?	Falcon Phase 3 Optimal Protection with “Microsoft Office file malicious macro removal” enabled

Every row in that table is checkable in about two minutes, which is roughly the point.

The fifth in a fortnight

This is now a recurring shape here rather than an observation. In the last two weeks this site has covered five exploitation or capability claims that rested on a single source and lost their qualifier in transit.

UAC-0099, where an entire technique claim rested on three posts and nobody had run the test. JFrog, where the exploitation claim was one firm's honeypots and the vendor never confirmed it. Langflow, where detection counts moved sevenfold in a day against a sensor fleet of unstated size. SonicWall, where "a case indicating" became "hackers are chaining two zero-days". And now this, where a precondition and a working-as-published caveat both appear in the source and in almost none of the coverage.

What fell out between the source and the second telling

The pattern is not that researchers overclaim. In four of those five the original wording was careful, and it is careful here. The loss happens between the source and the second telling, reliably enough that you can plan around it.

The position

The interesting thing here is not the flaw, which may be entirely real and is impossible to assess from what has been published. It is what now counts as a zero-day disclosure.

Seven hundred and forty-four characters, a screenshot, no CVE, no write-up, no vendor contact evident, and a caveat from the author that the code as published does not work against a default install. That was enough to be reported as an unpatched zero-day in a major endpoint product before lunchtime.

A defender's response to that should be neither dismissal nor alarm. It should be a configuration check, which takes a few minutes, and a note in the log that the claim is currently unverifiable in either direction.