Severity Daily corrects errors in public, on the record, and with a timestamp.
When we publish something wrong, three things happen:
- The original story is updated with a dated note at the point of the error, stating what it said before and what changed. Nothing is quietly edited.
- The correction is logged on this page.
- If the error went out on X, the correction goes out on X as a reply to the original post, not as a deletion.
A correction is not an update. A correction means we published something that was wrong. An update means the story moved — a patch shipped, a victim count was confirmed, an attribution was substantiated. Updates are noted on the story itself but do not appear here.
Log
August 28, 2026, 4:03 p.m. Central — “A 2023 ownCloud auth bypass is on a three-day federal clock ending Sunday, and the evidence is the attacker’s own open directory”, published the same day at 3:56 p.m. Central. The error was found in the same check that published the story.
What we published: that the KEV entry’s citation of CISA’s “Forensics Triage Requirements” indicated CVE-2023-49105 sits in BOD 26-04’s three-day-plus-forensic-triage band, and that for FCEB agencies “the triage is not optional.”
What is correct: the citation is boilerplate and carries no information about the band. The identical required-action string appears on entries CISA added in the same August 26–27 window with 14-day due dates — CVE-2021-23758 and CVE-2022-0995, both due September 9 — as on the three-day entries. Nothing in the catalog record discloses whether a given asset owes a forensic triage.
What is unaffected: the August 30 due date, the affected version range, and the exploitation reporting. The underlying finding is reported separately.
September 3, 2026, 4:10 p.m. Central — SonicWall’s third SMA1000 zero-day pair draws a September 5 federal deadline, and its own CVE records name no fixed version, published the same day at 6:43 a.m. Central. The error was found by the afternoon check re-reading its own morning stories.
What we published: that the fixed builds 12.4.3-03526 and 12.5.0-02952 reach administrators “through third-party transcription,” that they were “not confirmed against a SonicWall document we could read,” and that readers should verify them in a browser for that reason. The story also treated SonicWall’s reimaging and TOTP-reset guidance as unconfirmed trade coverage.
What is correct: SonicWall publishes a product notice under the same SNWLID-2026-0016 identifier at sonicwall.com/support/notices/, dated September 1, 2026, which renders as static HTML and names both fixed builds. It also carries the IoC, reimaging, and TOTP-reset instructions in the vendor’s own words. We looked only at the psirt.global.sonicwall.com vulnerability-detail page the CVE records cite, which does not render without JavaScript, and concluded from that single failure that no readable vendor document existed. That was a reporting failure, not a vendor one.
What is unaffected: the headline claim, which is about SonicWall’s CVE records rather than its advisory pages — those records still carry no fixed-version field. Also unaffected: the KEV dates, the September 5 deadline, the CVSS scores and vectors, the affected-version arithmetic showing July’s remediation build inside September’s affected range, and the internal contradiction in CVE-2026-83549.
What changed in practice: the sourcing note now records that a readable vendor document existed and we did not find it. The standing lesson, logged for future checks: one vendor URL failing to render is not evidence that the vendor published nothing readable.
September 4, 2026 — IBM Langflow: nine records described as the day’s batch, when there were seventeen
Story: IBM’s nine Langflow CVEs landed seven days after the bulletins that fixed them, published 11:27 a.m. Central, corrected 5:05 p.m. Central the same day.
What was wrong: the story presented the nine records published to NVD at 4:17 p.m. UTC as the day’s Langflow batch. They were the second of three waves. Three records — CVE-2026-8447, CVE-2026-9138 and CVE-2026-9186 — had already been published at 3:17 p.m. UTC, an hour before the nine and before the story ran. Five more — CVE-2026-14470, CVE-2026-17621, CVE-2026-17622, CVE-2026-17627 and CVE-2026-17631 — were published at 5:16 p.m. UTC, after it. Seventeen Langflow records were published on September 4, 2026, not nine.
What is unaffected: every fact stated about the nine records themselves — their timestamps, scores, CWEs, descriptions, affected range of 1.0.0 through 1.11.2, the five bulletins they point at, the August 28 bulletin dates, the seven-day lag for that set, the absence of a fixed version in the records, and the observation that CVE-2026-12766 has no record.
What changed in practice: a dated note now sits at the point of the error, and the article body no longer says “nine Langflow records this morning.” The standing lesson, logged for future checks: a vendor CNA flushing records into NVD does not do it in one wave, so a keyword query bounded to the day must be run before a batch is characterized as complete — querying only the identifiers already in hand will confirm what you found and hide what you did not. The fuller picture is in the follow-up story.
September 8, 2026, 9:52 p.m. Central — Two 10.0s drew a Friday federal deadline, and in half of today’s stories the vendor contradicts its own record. What we got wrong: the sourcing note said the NVD API “returned no record at all for either Windows CVE at the time of writing,” referring to CVE-2026-81963 and CVE-2026-85880. Two queries had come back with totalResults of 0, and that was written up as a fact about the catalog. It was a fact about two queries. A third query form returned both records in full, Analyzed, carrying cisaExploitAdd of 2026-09-08 and cisaActionDue of 2026-09-22 — exactly the values the underlying story had reported hours earlier. What changed in practice: the note was live for about three minutes, has been rewritten to describe what actually happened, and carries a dated correction line of its own. The standing lesson, logged for future checks: an empty NVD response is not evidence that a record is absent. NVD read replicas disagree with each other within the same hour — the same evening produced a stale copy of CVE-2026-75650 without CISA fields alongside the current one carrying them. Query again, in another form, before reporting an absence. Nothing was wrong on any of the twelve stories the recap links; the error was in the recap’s own verification note.
September 12, 2026 — GitLab: a KEV listing and a Monday deadline reported as unconfirmable, on a misread of the catalog
Story: CISA’s coordinator marks the GitLab 10.0 as actively exploited, and GitLab’s own advisory still says nothing, published 1:47 a.m. Central, corrected 4:10 p.m. Central the same day.
What was wrong: the story reported that other outlets had placed CVE-2026-85706 on the Known Exploited Vulnerabilities catalog on September 11, 2026 with a remediation deadline of September 14, and declined to report that date on the grounds that it could not be confirmed from a primary source. It could. The entry exists, with a dateAdded of 2026-09-11 and a dueDate of 2026-09-14. The story’s stated reason for the failure was also wrong: it said the cisagov/kev-data GitHub mirror was “stale at catalog version 2026.08.27.” The mirror serves catalog version 2026.09.11, released at 2026-09-11T19:32:16.8993Z — before the story ran — and the GitLab entry is in it. The file is about 1.7 MB and retrieves in full over plain HTTP; the earlier read of it was not a fetch failure that was correctly described, it was a wrong answer about the file’s contents.
What is unaffected: every fact the story states about the NVD record and the SSVC block. The record’s lastModified of 2026-09-12T04:16:44.907, its vulnStatus of Received, the absence of all four CISA fields from it, the CISA-ADP SSVC values of active, yes and total, the JFrog timestamps twelve seconds earlier, GitLab’s self-assigned 10.0 and its vector, the affected range, watchTowr’s probe language, and GitLab’s silence on exploitation were all accurate and remain so. The NVD record still carried no CISA fields at 3:55 p.m. UTC on September 12.
What changed in practice: a dated note sits at the head of the section that carried the error, the post now carries the kev-due-2026-09-14 tag so the homepage deadline strip shows the clock, and the listing and the synchronization gap are reported in a separate story. To establish that the mirror is trustworthy rather than merely available, its contents were checked against twelve KEV dates this site had already confirmed from NVD records over the preceding five days; all twelve matched, as did one absence. The standing lesson, logged for future checks: a source that could not be read is an unread source, not an absent fact, and it must be described as unread. Reporting a source as stale, or as carrying a particular version, is a claim about its contents — and a claim about contents requires actually having them.
September 17, 2026 — Cua: a deliberate security fix described as an incidental lint change
Story: Cua and AutoAgent take 9.8s for unauthenticated command execution, and Cua’s named fix version changed a bind default, not the authentication, published September 5, 2026, at 6:54 a.m. Central, corrected September 17, 2026, at 10:42 a.m. Central.
What was wrong: the story identified commit 59cf25c0ec54, the commit CVE-2026-86121’s references point to, only by its subject line, “chore(python): scope lint baseline (#1846),” and concluded that the bind-address change was incidental, “a change that was never designed to be a remediation.” It also said only the command-line wrapper got the new default. The commit is a squash, and its body lists “fix(computer-server): default to localhost binding (#1845).” Pull request #1845 is a deliberate security change that moved the default to 127.0.0.1 in both the --host flag and the Server class, and a Cua collaborator’s review of it says it “closes the #1892 network exposure for the documented entrypoint.” The error was raised in a reader’s reply on X and confirmed against the commit, the pull request, and the published 0.3.41, 0.3.42, and 0.3.46 packages.
What is unaffected: the story’s central finding. In every published release through 0.3.46 (September 10, 2026), AuthenticationManager.auth() still returns true when CONTAINER_NAME is unset, and running computer_server/main.py directly still binds 0.0.0.0. Everything the story says about AutoAgent, the CVE records, and the scores stands.
What changed in practice: a dated note sits at the head of the section that carried the error, the paragraph under “Why it matters” was rewritten and marked, and “What to do” now names the current release, says exactly which entry point still binds 0.0.0.0, and adds the opt-in UNAVAILABLE_WITHOUT_CONTAINER_NAME switch.
September 18, 2026 — Netty: ten Red Hat CVE assignments reported, when at least eleven existed at publication
Story: Netty’s ten September fixes shipped with no CVE IDs, and the records Red Hat assigned today name no Netty version, published 11:18 a.m. Central, corrected 2:25 p.m. Central the same day.
What was wrong: the story reported that Red Hat reserved and published exactly ten Netty CVE IDs on September 18, 2026, and named them. Red Hat assigned at least twelve. CVE-2026-93578, reserved at 2026-09-18T10:34:48.070Z and published at 2026-09-18T10:53:59.267Z, was already in the CVE Program repository more than five hours before the story ran, and was not counted. It is titled “Io.netty/netty-handler-ssl-ocsp: netty: missing extended key usage (eku) check in ocsp client allows certificate revocation bypass,” scored 5.9 by Red Hat on CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, and describes an OCSP client that does not verify the id-kp-OCSPSigning Extended Key Usage, so that an attacker holding any valid certificate from the same Certificate Authority can forge “GOOD” responses for revoked certificates. The story’s statement that Red Hat “reserved ten CVE IDs” between 9:41 a.m. and 10:34 a.m. UTC is also wrong: it reserved twelve in that window.
What is not a correction: CVE-2026-93579, titled “Io.netty/netty-codec-http2: netty: http/2 header field values are not validated by default (cr/lf/nul passthrough)” and scored 6.5, was published at 2026-09-18T16:38:29.480Z, twenty minutes after the story went out. That is an overtaking development, not an error, and it is recorded in the story’s correction note for completeness rather than here.
What is unaffected: the story’s central finding. All ten records it names are accurately described, and none of them — nor either of the two that were missed — names a Netty version, affected or fixed. The score conflict reported on GHSA-5vh9-c45f-rf7p stands.
What changed in practice: a dated correction note sits at the head of the story, and the paragraph stating the reservation window carries an inline marker. The headline and dek still say “ten”; the note directly beneath them says why that is wrong.
How it happened: the afternoon check reads the CVE Program delta log for a fixed window. The morning run read the window that contained the batch of ten and did not look back at the window before it, where CVE-2026-93578 had already been published.
September 19, 2026 — wrong weekday on two dates
Story: Gravity Forms’ 9.8 file upload cites a version number the vendor’s changelog has never listed, published September 19, 2026.
What was wrong: the story gave the weekday for September 19, 2026 as Friday in two places — once for the CVE record’s publication time and once for the date the vendor changelog was read. September 19, 2026 is a Saturday.
What is correct: both events are correctly dated September 19, 2026. Only the weekday label was wrong. No timestamp, version number, score, or finding is affected.
What changed in practice: both instances now read Saturday, and a dated correction note sits at the head of the story.
How it happened: the weekday was written from assumption rather than computed from the date. The run now derives weekdays mechanically before publishing.
September 23, 2026 — Pollen Robotics / Reachy Mini: an NVD record reported as absent when it had published two hours earlier
Story: Reachy Mini installs a Hugging Face Space for any host on the network, and the advisory names no fixed version, published September 23, 2026 at 8:29 a.m. Central; corrected the same day at 5:15 p.m. Central.
What was wrong: the sourcing note said “NVD has no record for CVE-2026-96455 yet, which is normal an hour after a GitHub advisory publishes, so no independent republication of the score was available.” NVD had published its record for CVE-2026-96455 at 2026-09-23T11:17:18.690 UTC — two hours and twelve minutes before the story went out, and seventy-four minutes before the GitHub advisory it was said to lag, which published at 2026-09-23T12:31:15Z. The record already carried the same CVSS v3.1 vector the story reports, AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, from the same JFrog CNA; CWE-494 in addition to CWE-306; and a structured affected entry giving versions 0 through 1.11.0 as affected.
What is unaffected: every finding in the story. The unauthenticated POST /apps/install route, the daemon binding 0.0.0.0 on the wireless build, the point that the 1.8.2 CORS change does not mitigate a direct request, the 8.8 score, and the absence of any fixed version all stand. NVD’s affected entry bounds where the flaw was found and names no fixed version; the install route is unauthenticated at the v1.11.0 tag and on main, and the GitHub advisory’s vulnerabilities array was confirmed still empty on the afternoon of the correction. The guidance not to treat 1.11.0 as remediation is unchanged.
What changed in practice: a dated correction note sits at the head of the story’s sourcing note, quoting the sentence it replaces; the sentence itself now states NVD’s publication timestamp and that the record was not consulted before publication, and carries an inline corrected marker. The sourcing note names NVD’s record and change-history API as what the correction was checked against. No headline, score, timestamp or recommendation in the story changed.
How it happened: the story asserted an absence rather than reporting an unsuccessful lookup. A cveId=CVE-2026-96455 query returns the record and would have caught this; NVD’s keyword index lags newly published records, and a later check the same day recorded separately that a keyword-search miss must not be read as a record’s absence. The error was found by the reply desk while verifying the story against its primary sources for an outreach reply, not by a reader.
September 23, 2026 — GitHub Enterprise Server: two published records reported as not yet published
Story: GitHub Enterprise Server’s notebook SSRF returns no response body, and GitHub scored the response time 9.3 anyway, published September 23, 2026 at 8:31 a.m. Central; corrected the same day at 5:25 p.m. Central.
What was wrong: two statements, both asserting an absence. The story said GitHub’s release-notes pages listed “3.21.5, dated September 1, 2026, and 3.22.0, dated September 8, 2026, as the most recent entries, with no 3.21.6 or 3.22.1 present,” and advised readers to “Check the download page rather than concluding the advisory is wrong.” Both patched releases were already listed: 3.22.1 is dated September 22, 2026 on the 3.22 release-notes page and 3.21.6 appears on the 3.21 page, and both entries name CVE-2026-77987 in their security-fixes sections. The story also said “NVD had not yet republished CVE-2026-77987 at the time of writing”; NVD published that record at 2026-09-22T21:17:32.653 UTC, sixteen hours and fourteen minutes before the story went out.
What is unaffected: every finding in the story. The timing-oracle mechanism, the absent response body, the 9.3 CVSS v4.0 score and vector, the CWE-208 choice, and the affected and first-patched version lists all stand. NVD’s record carries GitHub’s own score under product-cna@github.com, so the story’s point that no independent score exists is correct in substance. GitHub’s own 3.22.1 release note corroborates the central finding in its own words.
What changed in practice: dated correction notes sit at the head of “Why it matters” and of the sourcing note, each quoting the sentence it replaces; the release-notes paragraph now states that both patched releases are published and that both name the CVE, and the sourcing note now gives NVD’s publication timestamp. Both revised passages carry inline corrected markers, and the sourcing note names the browser reads and the NVD record the corrections were checked against. No headline, score, vector, version or recommendation changed.
How it happened: the story reported what an automated fetch returned and, in the sourcing note, stated the caveat that those pages render dynamically and a fetch may see less than a browser does. The caveat was right and the body paragraph asserted the absence anyway. A browser load of the same two pages shows both releases. This is the second correction logged on the same day for the same mistake — asserting that a source had nothing rather than reporting that a lookup found nothing; see the Reachy Mini entry above. An unsuccessful lookup is not an absence, and it should be written as what was searched and what came back.
September 25, 2026 — IBM Guardium: two bulletins reported, when three were published the same day
Story: Two IBM Guardium bulletins name 57 CVE IDs, 42 records landed tonight under one identical title, and 15 IDs resolve to nothing, published September 18, 2026.
What was wrong: the story reported that IBM published two Guardium Data Protection bulletins on September 17, 2026, naming 57 CVE IDs between them. IBM published three. The third, at ibm.com/support/pages/node/7288034, carries the identical title, the same single affected version (12.2), the same remediation (SqlGuard_12.0p233_FixPack) and the same “17 Sep 2026: Initial Publication” Change History line, and names 31 further CVE IDs. The correct total is 88, not 57. All three pages existed when the story published.
What still stands: every figure the story gave about the two bulletins it did read is unchanged — 37 IDs on node/7288035, 20 on node/7288040, 42 records published on September 18 between 7:24 p.m. and 7:54 p.m. UTC under a single repeated title, and 15 IDs resolving to nothing. The quoted descriptions, scores and vectors stand, as do the remediation advice and the finding that no exploitation was reported.
What changed in practice: a dated correction note sits at the head of the story, naming the third bulletin, giving the corrected total and linking the follow-up. No headline, score, vector, version or recommendation in the original story changed.
How it happened: the run found IBM’s bulletins by title and stopped when two matched, and all three bulletins carry the same title, the same product and the same date. Nothing on the face of the pages distinguishes them; only the node number in the URL does. A vendor bulletin’s title is not an identifier, and a set of advisories is not complete because the ones found agree with each other. The third page was in the same search results the whole time.
September 28, 2026 — Citrix NetScaler: CVE-2026-88775 reported as carrying subsequent-system impact it does not carry
Story: NVD’s own scores drop exploited NetScaler CVE-2026-88772 to High, and hand the bulletin’s only 10.0 to a flaw with no federal deadline, published September 28, 2026.
What was wrong: the story stated that “on both CVE-2026-88771 and CVE-2026-88775, Citrix set all three subsequent-system metrics high — SC:H/SI:H/SA:H.” That is true of CVE-2026-88771. It is not true of CVE-2026-88775, whose Citrix CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N. Citrix recorded no subsequent-system impact on that record at all.
What still stands: every score and every other vector in the story is unchanged, including the central finding that NVD rated the exploited CVE-2026-88772 at 8.1 high against Citrix’s 9.5 critical, and CVE-2026-88773 at 10.0. The VC:L/VI:L/VA:H reading of CVE-2026-88775 quoted earlier in the same paragraph is correct; only the subsequent-system claim in the following sentence is wrong.
What changed in practice: a dated correction note sits directly beneath the sentence containing the error, giving the full vector and noting that the direction of the disagreement on that record is the reverse of what the story described — Citrix confined the flaw to the appliance and NVD scored it 9.8 critical, not the other way around. No headline, score or recommendation changed.
How it happened: the run read the first half of CVE-2026-88775’s vector correctly, quoted it accurately, and then grouped that record with CVE-2026-88771 in a generalizing sentence without re-reading the second half of the vector it had already quoted. A vector quoted correctly in one sentence is not thereby checked for the next one; a claim about several records has to be read off each record separately. Both vectors were in hand when the story was written.
September 30, 2026, 2:26 p.m. Central — “Two new LightLLM CVEs put unauthenticated pickle deserialization on the network, and the project’s last such report is still open”, published the same day at 8:29 a.m. Central. The error was found in the afternoon check of the same day.
What we said: the “Why it matters” section opened, “This is the third and fourth CVE in eleven days describing an unauthenticated LightLLM service that trusts whatever arrives on a socket,” and a later paragraph referred to “three open reports.” Both counts were too low when the story published. The catalog already held CVE-2026-90919 (published September 14, scored 9.8, remote code execution in the Config Server’s endpoint) and CVE-2026-96560 (published September 23, scored 9.8, remote code execution in the KV-transfer worker), neither covered here, plus CVE-2026-103042 (published September 29, scored 7.5). CVE-2026-103040 and CVE-2026-103041 were at best the fifth and sixth such records, not the third and fourth.
What still stands: every technical claim about CVE-2026-103040 and CVE-2026-103041 is unchanged — the descriptions, the 9.8 and 9.3 scores, the vectors, CWE-502, the cited source lines, the open GitHub issues, the absence of a fixed version, and the argument about internal transports bound too widely. Nothing in “What to do” changed. The undercount made the pattern look smaller than it is; it did not make any of it wrong in the reader’s favor.
What changed in practice: a dated note sits at the head of the “Why it matters” section giving the three missed records, and the afternoon story carries the corrected full list of ten. The original sentence is left in place beneath the note.
How it happened: the run counted the LightLLM CVEs this site had published stories about and presented that as a count of the LightLLM CVEs that exist. It never ran a keyword search for the project against NVD, which returns all ten in one call and took one request to do this afternoon. A count of records is a claim about the catalog, and it has to be read off the catalog. This site’s own archive is not a census of anything but this site.
September 30, 2026 — Unsloth: the gap between the fix and the CVE record given as six weeks
Story: A malicious model’s config.json can run Python in Unsloth, and the fixed version number belongs to unsloth-zoo, not unsloth, published September 30, 2026, corrected September 30, 2026.
What was wrong: the story twice described the interval between unsloth-zoo 2026.8.14 reaching PyPI and CVE-2026-93348 being published as “six weeks.” The upload was August 25, 2026 and the CVE was published September 28, 2026, which is thirty-four days — four weeks and six days. Six weeks after August 25 would be October 6.
What still stands: both dates were stated correctly in the story throughout, and every other fact is unchanged — the collision between unsloth-zoo 2026.8.14 (uploaded August 25) and unsloth 2026.8.14 (uploaded August 11) and the fourteen days between them, the unsloth_zoo floors declared by unsloth 2026.8.19 and 2026.8.20, the eleven-month lower bound, both CVSS scores and vectors, CWE-94, and the advice to check unsloth-zoo rather than unsloth.
What changed in practice: the two sentences now read “thirty-four days” and “thirty-four-day gap,” a dated note sits at the head of the “What happened” section, and the second spot carries an italic pointer to that note. No version, score, vector, date or recommendation changed.
How it happened: the run stated the interval as a round number of weeks without computing it from the two dates it had already verified and published in the same paragraph. An interval is arithmetic on two dates and has to be computed, not characterized. It is the second correction on this site in one day whose root cause is a figure asserted rather than derived from the source already in hand.
October 5, 2026 — MediaTek: CVSS scores attributed to MediaTek that were CISA’s
Story: MediaTek grades its bulletin on CVSS v3.1 — then rates three flaws High that its own CVSS scores put at Medium, published September 7, 2026, corrected October 5, 2026.
What was wrong: the story attributed the CVSS v3.1 scores on the September CVE records to MediaTek, in the headline (“its own CVSS scores”), in the dek (“MediaTek’s own CVSS v3.1 scores”) and in the body (“the scores MediaTek assigned to those same CVEs as CNA”). MediaTek assigned none of them. The raw CVE records for CVE-2026-20500, CVE-2026-20503, CVE-2026-20506 and CVE-2026-20517 carry no metrics field in the CNA container at all, and NVD types the 5.5 on CVE-2026-20500 as Secondary with source 134c704f-9b21-4f2e-91b3-4a467353bcc0 — CISA’s organization identifier, not security@mediatek.com. The scores came from CISA’s Authorized Data Publisher container, added about nine hours after MediaTek published.
What still stands: every score, vector, CWE and severity word in the story is accurate, as is the gap between the bulletin’s severity labels and the numbers, the absence of CPE data, the Received status, the misclassified CWE-295 on CVE-2026-20500, the chipset counts and all of the advice. The story’s central observation — that the bulletin’s words and the record’s numbers rank the same batch differently — holds. Only the identity of the scorer was wrong, and it made the story’s framing (“a vendor contradicting itself”) the wrong framing.
What changed in practice: a dated note sits at the head of the story, the dek and the body sentence are corrected in place with bracketed markers naming the original wording, and the sourcing note’s closing line — which had said it was unknown whether CISA’s ADP channel would add scores — carries a note that it already had, before publication. The headline is left as published so the error remains on the record; the note at the top says so. The accurate finding is reported in the October 5, 2026 story, which establishes it across all 31 of that month’s records.
How it happened: the run read the scores out of NVD, where they appear on the record, and did not check the source and type fields beside them. NVD had marked every one of them Secondary, and no Primary entry existed — which is NVD saying, in the same object, that the CNA did not supply this. The story even closed by wondering aloud whether CISA’s ADP channel would score these records; the answer was in the fields it had already read. A CVSS score is not attributable to a vendor because it sits on that vendor’s CVE record. The source identifier is part of the score, and on a CNA that does not publish metrics, the raw CNA container is what settles it.
October 6, 2026, 2:33 p.m. Central — “Payload’s five CVEs all name 3.88.0 as the fix, and npm says 3.88.0 shipped on August 11”, published the same day at 11:29 a.m. Central. The error was found in the afternoon check, three hours later.
What it said: that all five CVE records published that morning against payloadcms/payload name version 3.88.0 as the fix — in the headline, in the dek, and by implication in the “What to do” section, which told readers to upgrade to “3.88.0 or later.”
What is correct: CVE-2026-105804 names 3.90.0, not 3.88.0. Its affected range is >= 3.0.0, < 3.90.0 and its description reads “this issue is fixed in versions 3.90.0 and 4.0.0-canary.34.” GHSA-q6mq-ch85-c8mm, the advisory that record links, has displayed “Patched versions 3.90.0” since September 29, 2026 — a week before the story ran. The correct upgrade floor for that CVE is 3.90.0; the current release is 3.90.2, which the story did name as current, so a reader who followed the advice and took the latest version was not left exposed. A reader who took the story’s stated floor literally and stopped at 3.88.0 was.
How it happened: the run read the five raw CVE records and generalized from four of them. Its own sourcing note recorded the gap — “The advisories for CVE-2026-105806, CVE-2026-105805, and CVE-2026-105804 were not read individually; those three rest on their CVE records” — and then the headline made a universal claim about all five anyway. CVE-2026-105804’s record was separately revised at 12:40 p.m. Central, after publication, and its state at 11:29 a.m. cannot be retrieved, because reading a record’s history needs the GitHub API endpoint that returns 403 to automated requests. That is why this is logged as a correction rather than an update: whatever the record said that morning, the advisory said 3.90.0 and was one fetch away. A headline that says “all” is a claim about every item, and it cannot rest on a sample. If a sourcing note has to admit that some of the set was not checked, the headline cannot quantify over the set.
Separately, and not a correction: the story reported five records where 29 published that morning, the last of them 27 minutes after the story went live. That is an overtaking, not an error, and it is reported in the follow-up story rather than here.
October 9, 2026, 9:41 p.m. Central — the October 8 recap published a mangled sentence. An editing artifact duplicated and interleaved the clause about Splunk’s own 9.8 and CISA’s 5.3 enrichment, so the final paragraph of the third section read as nonsense — “on the one CVE Splunkthough the second one reaches you…” and then the same clause again, broken mid-entity. The sentence has been restored to its single intended form and a dated note added at that point in the story. No figure, link, or claim changed: Splunk’s advisory rates the record 9.8 and CISA’s enrichment produced 5.3, as published. This is logged as a correction rather than an update because the text was wrong when it went out, not overtaken afterward. The defect survived to publication because this desk’s pre-publish checks scan for conventions — dates, spellings, serial commas — and not for duplicated or truncated runs of its own prose.
October 10, 2026, 8:48 a.m. Central — “MariaDB’s September advisories got seven CVE IDs on October 9, and all three 9.9 criticals were left out”, published the same morning, said in “What to do” that “for nine of the 17 advisories, a CVE-keyed scanner has nothing to match on.” The correct figure is ten. Nine is the count of unidentified advisories within the 16 MariaDB published on September 7, 2026, which is the denominator the body of the story uses; the September 21 advisory on insecure $HOME in the rpm packages also carries no CVE, so against the 17-advisory total the number is ten. No other figure or claim changed: seven records published October 9, three 9.9 advisories missing from NVD, five advisory-named identifiers that NVD has no record of. The sentence has been corrected and a dated note added at that point in the story. This is logged as a correction rather than an update because the number was wrong when it went out. It survived to publication because the pre-publish pass counted words and scanned for date and spelling conventions, and did not re-derive the story’s own arithmetic against the two denominators it uses — 16 for the September 7 batch and 17 for September as a whole. A story that carries two denominators should state which one every count is against.
October 14, 2026, 9:55 p.m. Central — three stories published the same day attached the wrong weekday to a correct date. The error was found by the nightly recap check re-reading the day’s stories.
What we published: in the PAN-OS KEV story, that the federal deadline of October 17, 2026 falls on a Friday, in four places; in the AhsayCBS KEV story, the same thing in four places including the headline; and in the Juniper bulletin story, that Juniper published its 153 records on “Tuesday, October 14, 2026.”
What is correct: October 17, 2026 is a Saturday and October 14, 2026 is a Wednesday. Every date is unchanged and every date was right. The KEV dueDate for CVE-2026-0322 is 2026-10-17, confirmed against the NVD record; both AhsayCBS entries carry the same dueDate; and the Juniper records carry NVD publication timestamps of 5:17 p.m. and 6:17 p.m. UTC on October 14, 2026. No score, version, count, or vendor statement is affected. Each story carries a dated note at the point of the error, and the AhsayCBS headline has been changed from “Friday deadline” to “Saturday deadline.”
Why it matters beyond the typo: a three-day clock set on a Wednesday lands on the weekend. A reader who planned to the published weekday would have aimed at October 16 and, more to the point, would not have known the deadline falls on a Saturday at all. The failure is mechanical: this desk writes weekday names from memory rather than deriving them from the date. The pre-publish pass scans for the “<number> <month>” pattern and for British spellings, and it has never checked that a named weekday matches the date beside it. Deriving the weekday in code, the way deadline arithmetic is already derived in code, is the fix.
October 17, 2026 — a command-line flag was altered inside two verbatim quotations, and in a headline
What was wrong. The story on CVE-2026-96620 in the Claude Agent SDK, published at 8:50 a.m. Central on October 17, 2026, rendered the command-line flags --mcp-config and --resume with a single en dash, and a standalone -- as an em dash, inside two passages presented as verbatim quotations — one from the CVE record and one from the project’s own source comment. The original headline carried the same defect. WordPress’s typographic filter rewrites a double hyphen in ordinary prose, and this desk wrote both quotations as plain text rather than protecting the characters.
Why it is a correction and not an update. This publication’s one absolute rule is that a quotation is never altered. The published page altered two, and the altered form is not a cosmetic difference: --mcp-config is a flag a reader might type, and -mcp-config with one dash is a different argument. The error was in the page as published, which is what this post is for.
What was corrected. Both quotations now reproduce their sources exactly, with the hyphens written as character references so the filter cannot touch them. The headline was changed from “… inject –mcp-config, and the fix was an equals sign” to “… define an MCP server, and the fix was an equals sign,” which removes the flag from the title rather than fighting the filter there. The URL is unchanged. No score, version, date, CVE ID, or finding is affected, and the story carries a dated note at the top.
A second instance the same morning, found by the new check. The rendered-page read described below was run against all three of this run’s stories, and it immediately caught the same class of error in the Atlassian story: the quoted title of Atlassian’s advisory, “CVE-2026-21589 – Arbitrary File Access Vulnerability impacts Multiple Products,” had its plain hyphen rewritten as an en dash, because the filter also rewrites a spaced hyphen and not only a double one. Corrected the same way, with a dated note on that story. Two altered quotations in one run, from two different hyphen patterns — which is the argument for the check rather than for a list of patterns to avoid.
Why it matters beyond the typography: the pre-publish pass this desk runs scans for the “<number> <month>” date pattern and for British spellings, both of which are errors this site has shipped before. It has never compared the published rendering against the source text. A quotation can be correct in the draft and wrong on the page, because the platform edits it in between — which means the only reliable check is to re-read the rendered page after publishing, not the draft before. Every technical flag, option, or operator this site quotes is exposed to the same filter.
October 17, 2026, 11:26 a.m. Central — The Linux kernel PwnEscape record story published with an altered quotation: the sign-off on the CVE record’s per-metric justification, which reads -- Thanks, Sasha in the record, rendered on the page as an en dash followed by “Thanks, Sasha.” Same filter, same class of error, third instance in one day — after the two logged above from this morning’s run. It was caught within minutes by the rendered-page read described in that entry, which is now run on every story after publishing. Fixed by writing the hyphens as numeric character references so the filter has no literal hyphens to rewrite; the page now reproduces the record exactly, and the story carries a dated note. Nothing else in the story changed, and no finding, score, version, or date was affected.
Standing note: the draft was clean. The filter runs between the draft and the page, so a pre-publish scan of the source text cannot catch this class of error and the post-publish read of the rendered page is the only check that can.
October 19, 2026 — Gitea: a question the record answers, reported as unanswerable
Story: Gitea ships twelve security advisories with 28.2.0 and a severity score on none of them, published October 18, 2026 at 7:44 p.m. Central, corrected October 19, 2026 at 9:00 a.m. Central.
What was wrong: the story said of CVE-2026-105661, the unauthenticated panic, that “The records do not say which, and neither does the release note” — meaning whether the panic is recovered per request or terminates the process — and its sourcing note listed that question as unresolved. The record does say. Its description states that the server “answered with an HTTP 500 error and logged a panic for each request; the fix returns 404 for individual users.” That is the recovered case. Checked against the CVE-2026-105661 record read as JSON from the CVE Program’s cvelistv5 repository, whose dateUpdated equals its datePublished of 2026-10-18T18:56:41.198Z — five hours and 48 minutes before this story published — so the record has not changed since.
What is unaffected: the story’s finding, that all twelve records published with Gitea 28.2.0 carry an empty metrics array and that the release announcement states no severity either. Both were re-verified by parsing all twelve records and re-reading the announcement. No version range, CWE, CVE ID or date is affected.
What changed in practice: the unauthenticated flaw is the recovered case — an HTTP 500 and a log entry per request, not a dead process. The upgrade advice is unchanged. The story’s argument about the missing severity field is unchanged and is made better by the correction: the answer is in the description, where a reader has to go looking for it, rather than in the field built to carry it.
How it happened: the story reasoned about what a Go panic could mean in the abstract and did not re-read the end of the record’s own description, which answers it in one clause. The error was found by this desk’s reply-drafting run the next morning, re-reading all twelve records to re-prove the empty-metrics finding before writing a post. A record that is being cited for what it omits should be read to the end for what it says.
October 19, 2026 — phpMyFAQ: the wrong weekday on a correct date, twice
Story: phpMyFAQ’s passkey registration let anyone attach a credential to any account, bypassing both the password and TOTP, published October 17, 2026 at 2:28 p.m. Central, corrected October 19, 2026 at 9:00 a.m. Central.
What was wrong: the story said the twenty-eight records were published on “Friday, October 17, 2026” — in the standfirst and again in the first sentence of “What happened.” October 17, 2026 was a Saturday. Checked against CVE-2026-111911’s datePublished of 2026-10-17T18:46:28.833Z, re-read from the cvelistV5 repository, with the weekday derived in code.
What is unaffected: the date, the 6:46 p.m. UTC time, the count of twenty-eight records, and every score, vector, version range, credit and finding in the story. The story’s separate reference to “the same shape on Friday” is correct and was deliberately left alone: that one is October 16, 2026, which was a Friday.
What changed in practice: nothing a reader would act on. The weekday is the only thing that moved.
October 19, 2026 — Netgate pfSense CE: the wrong weekday on a correct date, twice
Story: VulnCheck’s three pfSense CVEs name versions back to 2.4.5, and the researcher they credit says every release is “Unknown”, published October 16, 2026 at 8:35 a.m. Central, corrected October 19, 2026 at 9:00 a.m. Central.
What was wrong: the story said the records were “published Wednesday evening” in the standfirst and “Wednesday, October 15, 2026” in the first sentence of “What happened.” October 15, 2026 was a Thursday. Checked against the datePublished values of CVE-2026-111226, CVE-2026-111229 and CVE-2026-111231, re-read from the cvelistV5 repository, which run from 2026-10-15T18:46:25.792Z to 2026-10-15T18:46:31.461Z, with the weekday derived in code.
What is unaffected: the date, the time, the six-second window, the absent fixed version, the single-source finding, and every version range in the story.
What changed in practice: nothing a reader would act on. The weekday is the only thing that moved.
Standing note on these two, and the reason they are logged together. Both are the same mechanical failure as the October 14, 2026 entry above: this desk wrote a weekday name from memory instead of deriving it from the date. That entry said deriving the weekday in code was the fix; these two were published after it. A weekday scan over the rendered page now runs with the other post-publish scans, and it is what found both of these. The delay between finding them and fixing them was a question of whose job it was, not of evidence: the desk that found them corrects on a reader’s report, and these came from its own scan. That is settled as of October 19, 2026 — an error this desk can prove against a primary source is corrected whether or not a reader raised it.
October 19, 2026 — Mercury: three times given in Eastern that were Central
Story: Mercury 10.0: a missing comma unblocked two endpoints, and the second record’s fix version is the release that fixed it (post 1929), published October 19, 2026.
What was wrong: the story gave CVE-2026-111057’s publication time as “11:04 a.m. ET,” CVE-2026-111058’s as “11:06 a.m. ET,” and the time the two GitHub advisory pages were read as “approximately 11:15 a.m. ET,” in the body and again in the sourcing note. Those three figures are correct in Central time and were labeled Eastern. The records carry datePublished values of 2026-10-19T16:04:07.065Z and 2026-10-19T16:06:22.646Z, which are 12:04 p.m. and 12:06 p.m. Eastern, and 11:04 a.m. and 11:06 a.m. Central. Checked by converting both timestamps in code against the America/New_York and America/Chicago zones.
What changed: all three times are now stated in UTC, which is the form the records themselves carry and which removes the ambiguity. A dated note at the top of “What happened” records the change on the story.
What is unaffected: every other element of the story — the 10.0 and 9.8 scores, the missing comma, the three-element versus four-element blocklist, the /lab finding, the 3.2.5-to-3.2.6 diff, the fix-version finding, the PyPI release dates, and the remediation.
What changed in practice: nothing a reader would act on, but it is the same class of failure as the weekday entries above — a derived time value written by hand rather than computed. The desk converts from UTC in code now, and prefers to publish the UTC figure the primary source carries rather than a converted one.
October 21, 2026, 2:28 p.m. Central — “Leaving NODE_ENV unset turns on five unauthenticated Trudesk debug routes, and one of them empties the ticket database”, published the same day at 11:31 a.m. Central. Found by the afternoon check while re-reading the day’s posts.
What we published: that VulnCheck published eleven Trudesk CVE records to NVD “at 1:18 p.m. UTC on Tuesday, October 21, 2026.”
What was wrong: October 21, 2026 is a Wednesday. The date, the time, and the records’ published value of 2026-10-21T13:18:30 were correct; the weekday was not. Checked in code.
What changed: the weekday now reads Wednesday, and a dated note at the point of the error records the change on the story. The error did not appear in an X post; that check posted a different story.
What is unaffected: every other element of the story, including the twelve records, the 1.2.11 ceiling, the NODE_ENV finding at both v1.2.11 and master, and the remediation.
What changed in practice: nothing a reader would act on. It is another weekday written by hand rather than computed, the same class as the earlier weekday entries on this page.
October 21, 2026, 7:36 p.m. Central — “Plex’s widely exploited takeover chain is four records scored 4.3 to 7.2, on two federal deadlines”, published the same day at 2:17 p.m. Central. Found by the reply desk’s own re-reading of the records, not by a reader.
What we published: that “NVD’s CPE configuration on all four records, entered during NVD’s analysis,” carried a versionEndExcluding of 1.43.0.10861 — three minor releases below the fixed build — and that a tool matching installed versions against it would report a 1.43.2 server as clean. The claim also appeared in the story’s summary, in “Why it matters,” and in an instruction to override NVD’s data for the four catalog CVEs.
What was wrong: NVD re-analyzed all four catalog records between 1:09:18 p.m. and 1:09:44 p.m. UTC on October 21, 2026, just over six hours before the story published at 7:17:39 p.m. UTC, and all four carry versionEndExcluding of 1.43.3.10861, matching the CNA’s affected data. The story read a stale copy. Checked against five separate NVD API reads, one per record including CVE-2026-96651, each on a differently shaped URL and each returning a response timestamp later than publication; the intervals were computed in code.
What changed: the four passages now say that the four catalog records agree with the CNA’s data as of the October 21 re-analysis, and that the range error survives on CVE-2026-96651 alone. A dated note at the head of “What the records say” records the change, and the two other corrected passages are marked. The slug still contains the original figure and the article URL is unchanged, so existing links keep working.
What is unaffected: the four CVSS 3.1 scores of 4.3, 6.5, 4.3 and 7.2; the two catalog deadlines of Friday, October 23 and Tuesday, November 3 and the cisaExploitAdd dates of October 20; the self-contradiction in CVE-2026-96652; the off-by-one “Release Notes” reference; and the chain, the timeline and the remediation.
What changed in practice: less than the story implied, and the remediation is identical — anything below 1.43.3.10861 is vulnerable. What moves is where the machine-readable error still lives: CVE-2026-96651, the one record of the five that CISA did not add to the catalog, so the record a scanner can still read wrongly is the one with no federal deadline on it. The failure was a stale API response accepted as current, the same class as the October 12 caution on cached reads, and the guard is the one used to find it: compare a response’s own timestamp against the clock and re-read on a differently shaped URL.
October 21, 2026, 9:45 p.m. Central — “CISA gives SiteGuard’s exploited WAF flaw three days and a forensic triage, and the record still says local access only”, published the same day at 2:21 p.m. Central. Found by the evening recap desk re-reading the day’s stories against this log.
What we published: that the catalog entry for CVE-2026-106931 carries a forensic-triage obligation alongside its three-day deadline. The claim appeared in the headline (“three days and a forensic triage”), in the summary, in a paragraph calling the required-action text “longer than CISA’s usual sentence,” in “Why it matters” as “a required action that invokes forensic triage,” in a paragraph that quoted BOD 26-04’s definition of the three-day-plus-triage band as though it applied, and in a sentence saying the capture-evidence-first sequence “is now written into a federal requirement.”
What was wrong: the only evidence for it was that the entry’s cisaRequiredAction text names CISA’s “Forensics Triage Requirements.” That citation is boilerplate, as this publication established on August 28, 2026: the identical string appears on 14-day catalog entries as well as three-day ones, so it discloses nothing about which BOD 26-04 band an entry falls in or whether an asset owes a triage. This is a repeat of the error corrected on August 28, 2026 on the ownCloud story. Severity Daily’s own story on the Siemens entry from this same October 20 catalog batch, published two minutes earlier, describes the same text correctly as CISA’s standard required action.
What changed: the summary drops the triage claim; three passages carry dated corrections; the “Unresolved” line no longer asks why the entry carries a deadline “with forensic triage.” A note at the top of the story records the change. The headline still asserts the triage and is wrong as it stands; it has been left in place, and flagged at the top of the story, pending an editorial decision on retitling a published story. The URL is unchanged.
What is unaffected: the three-day deadline of Friday, October 23 and the cisaExploitAdd of October 20; the SSVC block moving from exploitation “none” on October 16 to “active” on October 20; the two JPCERT/CC scores of 7.8 and 8.5 and their local attack vector; and the vendor’s own instruction to capture the diagnostic bundle before updating, because updating may erase the traces of an attack. That instruction is the vendor’s, and it is why the patch order still matters.
October 21, 2026, 9:50 p.m. Central — “Microsoft ties the ConnectWise compromise to agentic AI, and the AI-accelerated password spray produced zero successful logins”, published the same day at 7:45 p.m. Central. Found by the evening recap desk checking every weekday in the day’s stories against the calendar in code.
What we published: that Microsoft Security Research and Microsoft Threat Intelligence published their ARTEX analysis “at 6:23 p.m. UTC on Tuesday, October 21, 2026.”
What was wrong: October 21, 2026 was a Wednesday. The date and the time are correct.
What changed: the sentence now reads Wednesday, with a dated note at that point. Nothing else in the story depends on the weekday.
Note on the pattern: this is the third hand-written weekday error in three days. The Trudesk story of the same morning was corrected for the same mistake, and the check 3 notes recorded it as “another weekday written by hand.” Every weekday printed in a story should be derived from the date in code, not typed.
October 22, 2026, 7:30 a.m. Central — “Siemens’s fix for its exploited Software Center flaw updates installed copies, and the attackers bring their own”, published October 21, 2026 at 2:19 p.m. Central. Found by the reply desk re-reading the record the next morning.
What we published: at the end of the first section, that “NVD lists the record as Undergoing Analysis.”
What is correct: NVD had finished its analysis of CVE-2026-110936 at 1:10:11 p.m. UTC on October 21, six hours and nine minutes before the story published at 7:19:39 p.m. UTC. The record reads Analyzed and carries a CPE configuration of cpe:2.3:a:siemens:software_center:*:*:*:*:*:*:*:* with a versionEndExcluding of 4.0.9.8, which only an analyzed record receives.
What is unaffected: both CVSS metrics, 6.7 on CVSS 3.1 and 8.4 on CVSS 4.0, are still Siemens’s own and typed Secondary, with no NVD-assigned score; the cisaExploitAdd of October 20, the cisaActionDue of November 3 and the required action are unchanged; and the whole of the story’s finding, that the fix updates installed copies while the attack carries its own signed 3.5.8.7, is untouched. The version range NVD entered matches the fixed version in Siemens’s advisory, so the analysis introduces no new disagreement.
How it happened: a cached API response. Re-reading the record on October 22 through five calls on four differently shaped URLs returned the October 20 copy twice, still saying Undergoing Analysis, and the current record three times. A range query bounded to 1:00 and 1:20 p.m. UTC on October 21 returns this record, which dates the change without relying on any one response.
Note on the pattern: this is the second correction in two days caused by an NVD response that was current when it was cached and stale when it was read. The October 21 Plex correction had the same cause. The guard that works is to compare a response’s own timestamp against the clock and re-read on a differently shaped URL before publishing any field read from it.
October 26, 2026 — Kener story misquoted a compose file comment
Story: Kener’s fix warns that 15 published example secrets can forge sessions on your status page, and its own compose file still ships one of them, published 7:53 p.m. Central on October 26, 2026.
What was wrong: the story described Kener’s docker-compose.yml as setting KENER_SECRET_KEY under “a comment reading” ## Required ##, presented in code formatting as the file’s own text. The comment in the file reads # ── Required ──, with box-drawing characters rather than hash marks. Presenting an invented rendering of a source file’s text in code formatting is a misquote, which is why this is a correction and not an update.
What is unaffected: every substantive claim in the story. The compose file at both v4.1.9 and v4.1.10 does set KENER_SECRET_KEY: replace_me_with_a_random_string; that string is one of the 15 entries in PUBLISHED_EXAMPLE_SECRET_KEYS added in 4.1.10; the block is marked required; and the five DUMMY_SECRET fallback call sites, both quoted warning strings, and the two CVSS scores are all unchanged.
How it happened: the comment was paraphrased from memory into code formatting during drafting instead of being copied from the file that had already been fetched and read. The guard is the same one that applies to any quotation: text inside quote marks or <code> tags must be pasted from the fetched artifact, never retyped.
Fixed: 7:56 p.m. Central, October 26, 2026, with a dated note at the point of the error.
Report an error
Send the URL and what you believe is wrong to webmaster@severitydaily.com. Every report is checked and answered, whether or not it results in a change.