Correction: We Said We Wrote About Fortinet EMS in February. Our First Post Was April 4.
Three posts we published this spring claimed we were early on CVE-2026-21643, the pre-authentication SQL injection in Fortinet's FortiClient Endpoint Management Server. We were not. Our own post archive and our own commit history say so.
What the posts said
April 14, "CISA Added Fortinet EMS to KEV Yesterday. We Wrote About It in February." It said we covered the CVE in February, that a defender with our feed "had the detection in early February," and that "the detection had been live for nine weeks." It also said our rules reached feed consumers before Fortinet's advisory was published.
April 16, "CISA's Fortinet Deadline Is Today. We've Been Alerting On The Exact SQL Pattern For Weeks." It said we had been alerting on the exact SQL pattern for weeks, and quoted a header value as the pattern we were watching.
May 13, "Fortinet Patched Pre-Auth RCE in FortiSandbox and FortiAuthenticator Today. The Last One We Tracked Hit CISA KEV in Sixty Days. Patch This Week." It said "On February 24, 2026, we documented an SQL injection pattern affecting FortiClient Endpoint Management Server," that we were alerting on it weeks before any major vendor advisory, and laid out a cadence in which "our archive picks up the pattern" and CISA follows inside two months. That post also repeated the April claims as receipts.
What the record actually says
No February post exists. Our first post naming CVE-2026-21643 is April 4, "Another Day, Another Management Console Owned. Fortinet EMS Makes It Five CVSS 9.8+ in Two Weeks." The February date in those posts was the CVE's disclosure, February 6 per NVD, not our coverage. There is no February 24 post either.
No February detection existed, because the thing that would have produced it did not exist. Our exploit harvester was first committed on April 4 and did not successfully write a record until a fix landed on April 5 at about 10:21 p.m. Central. A detection cannot be live for nine weeks when the pipeline is about ten days old.
No SQL-pattern detection rule of ours existed at all. The header value quoted in the April 16 post cannot be found in our index. We searched our logs, block events and edge decisions for the payload and found zero hits. Nothing of ours fired.
What we did have is this: around April 6, our harvester indexed the endpoint and the injectable header from 0xBlackash's public proof-of-concept on GitHub. That is useful detection content for defenders. It is also derived from a third party's public research, it arrived a week after Defused Cyber confirmed exploitation in the wild on March 30, and it was about ten days old when the April 16 post called it weeks.
One smaller one. Our April 5 post on the management-plane breach pattern said we already had 0xBlackash's proof of concept indexed. The harvester fix that made that possible landed about twenty-five minutes after the post went out.
And two date slips in the May 13 post: CISA added the CVE to KEV on April 13, not April 14, and the KEV post it cites ran April 14, not April 15.
The correct timeline
February 6: CVE-2026-21643 published, Fortinet advisory FG-IR-25-1142.
March 26: exploitation begins.
March 30: Defused Cyber confirms in-the-wild exploitation. Credit to them; that confirmation is the real early warning in this story.
April 4: our first post.
About April 6: our harvester indexes the public proof of concept by 0xBlackash. Credit to 0xBlackash for the research our indexed detection content came from.
April 13: CISA adds the CVE to the Known Exploited Vulnerabilities catalog, with a federal patch deadline of April 16.
April 14, April 16 and May 13: the three posts carrying the false claims.
The May 13 headline's "sixty days" is close to the CVE's own clock, about nine and a half weeks from the February 6 disclosure to the April 13 listing. It is not a clock that starts with us, and the post's framing that our archive picked the pattern up in February is false.
The honest version
We first wrote about CVE-2026-21643 on April 4, nine days before CISA's KEV listing and five days after Defused confirmed exploitation.
Our exploit harvester indexed the endpoint and injectable header from 0xBlackash's public PoC around April 6. That is detection content for defenders, not an early warning.
The class of error
This is the same class as our July correction, "We Claimed a Two-Month Lead. Our Own Timestamp Says We Were One Day Late": citing our own pipeline's time as a lead over others. In the FamousSparrow case we cited an ingest timestamp of somebody else's research as our detection. This one is worse in one specific way. It claimed a date before the pipeline existed. The February date belonged to the CVE, it got attached to us somewhere between draft and headline, and each later post cited the earlier one as its receipt.
Our rule since July is that no lead claim ships without a first-party receipt that predates the comparator, or independent corroboration that does, with both timestamps stated side by side. These posts predate that rule. Our lead-claim verifier caught them on a re-audit of published claims.
What we changed
Correction notes are being added at the top of all three original posts. The posts otherwise stay up as published, so the record of what we said is visible next to what was true.
The false claim was also removed from Patrick's résumé materials, where it had been repeated.
The defensive advice in those posts, patch EMS and get the management plane off the internet, was right then and is right now. The timeline we wrapped around it was not.
Our confidence caps at ninety-five percent as a standing rule. This was part of the other five.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=correction-we-said-we-wrote-about-fortinet-ems-in-february-our-first-post-was-april-4
Comments