We check our work before it goes up. Occasionally something still gets past us. When it does, we fix it in the open, say what changed and when, and list it here.
This page sets out how that works. The wider rules we write to are in our editorial standards.
Correction, update or clarification?
We use three labels, and we try to use them honestly.
Correction. We got a fact wrong. That includes a wrong affected version, CVE number, CVSS score, patch release, date, figure, name or quotation, a fix or detection that does not work as described, or a claim we could not stand behind. Every correction gets a dated note on the article and an entry in the log below.
Update. The facts moved after we published. A vendor shipped a patch, exploitation was confirmed, an advisory was revised, a Bill passed a stage. Updates are dated in the article, but they are not errors, so they do not go in this log.
Clarification. What we wrote was accurate but could reasonably be read the wrong way, or left out context that changes how it reads. A clarification gets a dated note on the article. If the misreading could have led someone to act wrongly, we log it here as well.
Typos, broken links and formatting slips are fixed without a note, as long as the fix does not change the meaning.
Where the note goes
A correction note sits at the foot of the article, in this form:
Correction, 3 November 2026: An earlier version of this article said version 4.2.1 fixed the flaw. The fix is in 4.2.2. We have corrected the affected versions table.
Where the error was in security advice, such as an affected version, a patch, a mitigation or a detection rule, the note also goes at the top of the article, so nobody acts on the old version before reaching the end.
If an article is wrong at its foundations, we withdraw it rather than patch it. The page stays up with a note explaining what was wrong and why it has been withdrawn.
No silent edits
We do not quietly change the substance of a published article. If a fact, a figure, a recommendation or a conclusion changes, the article says so and says when. Headlines are covered too: if a headline was wrong, the correction note says what it used to say.
How to report an error
Use our contact page and put Correction at the start of your subject line. Tell us:
- which article (the link is ideal);
- what you think is wrong; and
- where possible, the source that shows it, such as the vendor advisory, CVE record or legislation.
You do not need to give your name. If you would rather we did not mention you, say so and we will not.
How quickly we respond
We aim to:
- acknowledge a correction report within two working days;
- decide within five working days whether a correction is needed, and tell you what we decided; and
- correct errors in security advice (affected versions, patches, mitigations, detection logic) the same day we confirm them.
Where we decide no correction is needed, we will say why, briefly.
Corrections log
Most recent first. Updates are not listed here; see above.
| Date | Article | What changed |
|---|---|---|
| 27 October 2026 | PHP2Shell: patch PHP now, then go hunting | Corrected the Elastic conversion advice for the hunt rule: Elastic rejects the EQL output, and the PHP worker check never matches in ES|QL or Lucene. |
| 27 October 2026 | Hunt: SafePay’s recovery sabotage and exfiltration tools | Corrected the Elastic conversion advice: sigma-cli doesn’t accept the ecs_windows pipeline with ES|QL, and ES|QL’s LIKE is case-sensitive. Added notes on two rule checks that need adapting for Elastic. |
| 26 October 2026 | Node2Shell (CVE-2026-111497): patch Node.js, .NET and anything else that decodes Brotli | Added Ubuntu status and the 20.04 exception. |
| 23 October 2026 | PHP2Shell: patch PHP now, then go hunting | Removed an unsourced “several hundred” figure and corrected wording. The same revision added newly published indicators, NVD scores and researcher credits. |