Severity Daily

IT and AI security incidents, checked against the primary source

Author: Severity Daily

  • Corrections

    Severity Daily corrects errors in public, on the record, and with a timestamp.

    When we publish something wrong, three things happen:

    1. 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.
    2. The correction is logged on this page.
    3. 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

    No corrections yet. This page went up before the first story did.

    Report an error

    Send the URL and what you believe is wrong to [email protected]. Every report is checked and answered, whether or not it results in a change.

  • Microsoft flagged a CVSS 10.0 Entra ID flaw as exploited, then retracted it a day later. Much of the coverage never followed.

    Microsoft flagged a CVSS 10.0 Entra ID flaw as exploited, then retracted it a day later. Much of the coverage never followed.

    On 20 August, Microsoft published an advisory for a maximum-severity remote code execution flaw in Entra ID and marked it as exploited in the wild. On 21 August, Microsoft filed revision 1.1 with a one-line correction: “Corrected Exploited to No. This vulnerability was not exploited in the wild.” A number of the articles written during that twenty-four hour window are still up, still uncorrected, and still telling readers that a perfect-10 flaw in the identity service they depend on came under attack.

    There is nothing for you to patch here. That is the point of running it.

    What happened

    CVE-2026-69836, titled by Microsoft “Microsoft Entra ID Remote Code Execution Vulnerability.” The description: “Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.” CWE-502.

    Base score 10.0 critical, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The scope change — S:C — is what carries it from 9.8 to a perfect 10.

    What is affected is Entra ID itself, the cloud service. The CVE record lists the product with version “-” and carries Microsoft’s CNA tag exclusively-hosted-service. This is not Entra Connect, not a sync agent, not a connector, not anything installed on a server you own. There is no version range because there is nothing you run.

    Consequently, customer action required: no. Microsoft’s advisory FAQ, verbatim: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take.” The CVE was published under Microsoft’s cloud transparency initiative — an advisory that exists to tell you something happened, not to give you something to install.

    The correction

    The MSRC revision history is short and worth reading in full:

    • Revision 1.0, 20 August 2026: “Information published.”
    • Revision 1.1, 21 August 2026: “Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.”

    The advisory currently records Exploited: No, Publicly Disclosed: No, and an exploitability assessment of “Exploitation Less Likely.” CISA’s own enrichment record sets exploitation status to none. It is not in KEV.

    So for roughly one day, the authoritative vendor advisory for a CVSS 10.0 identity-service flaw carried an incorrect exploited flag, and the security press did what the security press does with a perfect-10 marked exploited.

    The Register ran it. Secarma ran it. Cybersecurity Dive ran it. Several of those pieces have not been updated. The Hacker News did correct theirs, appending a note that Microsoft changed the flag after they sought comment — which is what the process is supposed to look like.

    Why this is a story

    Three reasons, in ascending order of importance.

    First, the practical one. Somewhere right now a security team is being asked about a CVSS 10.0 Entra ID vulnerability under active attack, and the honest answer — it was never exploited, Microsoft already fixed it, there is nothing to do — sounds like deflection to anyone holding a printout of an uncorrected article. Bad information costs real time.

    Second, the number is doing work it shouldn’t. Microsoft published temporal metrics alongside the base score that almost nobody carried: E:U/RL:O/RC:C — exploit code maturity Unproven, remediation level Official Fix, report confidence Confirmed — producing a temporal score of 8.7. Microsoft’s own fuller assessment was meaningfully less alarming than the number in the headlines, and Microsoft published both. The base score alone was never the whole record.

    Third, and this is the one that generalizes. The vendor advisory is the primary source, and the primary source moved. Publications that treated a point-in-time read of MSRC as a permanent fact ended up permanently wrong. Advisories are living documents — Broadcom’s vCenter advisory reached revision .2 and added patch guidance for an entire version branch three weeks after publication; PaperCut’s build numbers still do not appear on its own release pages. Reading an advisory once and filing the story is not the same as sourcing it.

    That is a workflow problem, not a competence problem, and it is going to get worse as the volume of disclosure grows. The counter is unglamorous: check when the record was last revised, and go back before you cite it.

    Cloud CVEs are new, and they confuse people

    Worth understanding the mechanism that produced this advisory, because you will see more of them.

    Historically a CVE meant something you could install a fix for. Cloud providers fixed their own services quietly and told nobody, on the reasoning that there was no customer action to communicate. That changed as the industry pushed for transparency about flaws in services that customers depend on but do not control, and Microsoft now publishes CVEs for cloud-service issues it has already remediated, tagged exclusively-hosted-service.

    This is a genuine improvement. It is also a reliable source of confusion, because these advisories look identical to the ones that require action. Same CVE format, same severity scores, same MSRC page layout, same vulnerability scanners ingesting them. The only signal that there is nothing to do is a “Customer Action Required: No” field and an FAQ entry, both easy to skip when a 10.0 is on the screen.

    The practical consequence lands on whoever runs your vulnerability management program. A CVSS 10.0 flowing into a scanner or a risk register does not carry the “already fixed, nothing to install” context with it, and someone has to notice. If your process cannot distinguish a cloud-service transparency CVE from a patchable one, this will not be the last time it generates a fire drill.

    What to do

    • Nothing, for this vulnerability. There is no customer-installable fix, no build number, no configuration change. Any advice you see to “update Entra Connect” or “apply the Entra ID patch” is fabricated — there is nothing to apply.
    • If this reached your leadership as an active-exploitation story, correct it, and point at MSRC revision 1.1 rather than at us.
    • Add a revision check to how your team consumes advisories. MSRC, VMSA, and vendor KB articles all carry revision histories, and they change more often than the coverage built on them does.
    • Be wary of a base score quoted without its temporal metrics when the vendor published both.

    Sourcing note

    Everything above comes from Microsoft’s own records: the MSRC advisory and its revision history, the CNA record at CVE.org, and NVD’s mirror of Microsoft’s data. The CVSS 10.0 is Microsoft’s own CNA score and NVD has produced no independent primary score. We could not verify when the service-side fix was actually deployed relative to the 20 August disclosure — Microsoft says only that it was mitigated before publication and gives no date, so we are not implying a window of exposure. No discoverer is credited in the MSRC record or the CVE record. Not in CISA KEV; CISA’s enrichment record sets exploitation to none. The characterization of which outlets have and have not corrected their coverage reflects their state at the time of writing.

  • The GitLab flaw under “active exploitation” is one firm’s honeypot data — GitLab hasn’t said a word about it

    The GitLab flaw under “active exploitation” is one firm’s honeypot data — GitLab hasn’t said a word about it

    A critical GitLab flaw is being reported as under active exploitation within days of disclosure. The vulnerability is real, the patch is real, and self-managed instances should install it. But the exploitation claim comes from a single company’s honeypot network, GitLab’s own advisory says nothing about exploitation, and the flaw is not in CISA’s Known Exploited Vulnerabilities catalog. Several headlines attribute the warning to GitLab. GitLab did not issue one.

    What happened

    CVE-2026-19478 is a code injection flaw (CWE-94) in GitLab CE and EE. GitLab’s own description:

    “GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.11.11, 19.0 before 19.0.8, 19.1 before 19.1.6, and 19.2 before 19.2.4 that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive.”

    Two qualifiers in that sentence get dropped in most retellings and both matter: “under certain conditions” and “public projects.” GitLab has not published what those conditions are, and the HackerOne report and internal work item referenced by the advisory are both non-public, so the mechanism cannot be checked against a primary source.

    CVSS 9.4 critical, vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H. The impact shape is worth reading rather than skipping: confidentiality Low, integrity and availability High. This is a destroy-and-tamper bug, not a data-theft bug. If your threat model for a source control platform is “someone exfiltrates our code,” this is not that. If it is “someone deletes or silently alters our public projects,” this is exactly that.

    The score is GitLab’s own, assigned as CNA. NVD’s record was still in “Undergoing Analysis” status as of its last modification, so there is no independent primary score.

    Fixed versions: 19.2.4, 19.1.6, 19.0.8, and 18.11.11, released in the critical patch release of 17 August 2026. The same release fixes CVE-2026-19650, a CSRF issue in the GraphQL multiplex query handler rated 7.1.

    GitLab.com and GitLab Dedicated were not exposed. The release post: “GitLab.com and GitLab Dedicated are already running the patched version. GitLab.com and GitLab Dedicated customers do not need to take action.” This is a self-managed problem only.

    Where the exploitation claim actually comes from

    One company: watchTowr. Their principal security researcher Jake Knott told The Hacker News the firm reproduced the vulnerability within minutes of disclosure and observed in-the-wild exploitation against its honeypot network. SecurityWeek reported the same, sourced to the same firm.

    That is the entirety of the evidence base. Specifically:

    • GitLab’s patch release contains no statement about exploitation in the wild. The advisory is silent.
    • CISA has not added it to KEV, and therefore no federal remediation deadline attaches. Verified against the KEV catalog at version 2026.08.21; NVD’s cisaExploitAdd and cisaActionDue fields are absent for this CVE. We cannot speak to the catalog after 21 August.
    • No second firm has published its own telemetry. Horizon3’s write-up repeats the claim but sources it explicitly to public reporting rather than to its own observations; its contribution is a validation test, not an exploitation sighting.
    • No victim reports, no government advisory, no incident disclosures.

    Honeypot observations are legitimate evidence. They are also the weakest useful kind, because a honeypot records attempts against bait, not successful compromises of real instances. “Scanners are firing exploits at anything that answers” and “organizations are being breached through this” are different claims, and the reporting has flattened them.

    Why the distinction matters this week

    Two other stories are running alongside this one with the same “actively exploited” label attached.

    The N-able N-central flaw has vendor-confirmed exploitation, a KEV listing, a three-day federal deadline, and the vendor describing what attackers did after they got in. The PaperCut zero-day has the vendor stating it is aware of confirmed customer incidents. This GitLab item has one firm’s honeypot data and vendor silence.

    Run those three side by side under one label and you have flattened a real difference in evidentiary weight — which matters when someone is deciding what to bring to an emergency change window at 4pm on a Friday. All three should be patched. Only two of them justify waking anyone up.

    This is not an argument for ignoring watchTowr. They found and demonstrated the thing, and being first is genuinely useful. It is an argument for saying who is claiming what, so a reader can weigh it.

    The unpublished conditions are their own problem

    GitLab says exploitation is possible “under certain conditions” and does not say what they are. The HackerOne report is closed and the internal work item is confidential, so there is no primary source that would let an administrator work out whether their instance meets them.

    That is defensible while unpatched instances are still exposed, and it is also the reason a defender cannot triage this properly. You cannot check whether you are in the vulnerable configuration. You can only patch, which is the right answer anyway, but it removes the option of a reasoned deferral for anyone who genuinely cannot take an outage this week.

    It also makes the honeypot evidence harder to weigh. If exploitation requires conditions nobody outside GitLab can enumerate, then attempts observed against a honeypot tell you scanners are trying, not that the conditions are commonly met in the wild. Both things can be true: worth patching promptly, and not worth an emergency change window unless your instance is public-facing.

    What to do

    • Self-managed: upgrade to 19.2.4, 19.1.6, 19.0.8, or 18.11.11 depending on your branch. The patch has been out since 17 August.
    • GitLab.com and Dedicated: nothing to do, per GitLab.
    • Prioritize by exposure, not by the headline. The flaw reaches public projects on internet-facing self-managed instances. An internal-only GitLab with no public projects is a different risk than a public-facing one.
    • If you are already patched, check integrity rather than confidentiality. Given the CVSS shape, the question is whether public projects or user data were modified or deleted, not whether code was stolen.

    Sourcing note

    The description, CVSS, affected ranges, and fixed versions all come from GitLab’s own patch release and its CNA record. Exploitation is asserted by watchTowr alone; GitLab has made no such statement, and headlines attributing the warning to GitLab — including at least one that reads “GitLab Warns of Active Exploitation” — misattribute it. Not listed in CISA KEV as of the 2026-08-21 catalog, the freshest we could reach. The CVSS 9.4 is vendor-self-assigned with NVD analysis incomplete. Specific impacts appearing in some coverage, such as forging merge records or banning maintainers, come from watchTowr’s analysis rather than from GitLab. We could not verify the number or nature of exploitation attempts, whether any attempt succeeded against a real instance, or what GitLab’s “certain conditions” are — the referenced HackerOne report and GitLab work item are both non-public.

  • N-able says attackers used N-central’s own remote control to reach managed endpoints and plant Cloudflare tunnels

    N-able says attackers used N-central’s own remote control to reach managed endpoints and plant Cloudflare tunnels

    If you are an MSP running N-central on premises, or a company whose MSP does, this is the most consequential item of the week. N-able has stated in its own words that attackers who got into N-central servers used the product’s Take Control feature to reach managed devices and registered Cloudflare tunnels on those devices for persistence that survives losing access to N-central itself. Two CVEs are involved, one of them created by an incomplete fix for the other, and there have been two rounds of insufficient patching.

    What happened

    There are two CVEs, and any account naming only one will mislead you.

    CVE-2026-18556 is the original: “Authentication bypass using an alternate path or channel vulnerability in N-able N-central allows Authentication Bypass. This issue affects N-central: through 2026.1.” CVSS 7.4, CWE-288, published 1 August 2026.

    CVE-2026-18577 is what the fix for the first one produced: “An incomplete patch for CVE-2026-18556 allows for authentication bypass and account takeover in N-central Versions through 2026.3.1.” CVSS 8.1, same CWE, published 2 August 2026.

    Both are in CISA’s Known Exploited Vulnerabilities catalog, with deadlines that are worth reading twice. CVE-2026-18577 was added 3 August with a due date of 6 August. CVE-2026-18556 was added 4 August, due 7 August. Three-day windows, citing BOD 26-04 and its forensics triage requirements rather than the familiar 21-day BOD 22-01 clock. Note the ordering: the incomplete-patch CVE entered the catalog a day before the original.

    Two rounds of incomplete fixes

    The version history is the part that catches people out, because “we patched it” has been true and insufficient twice.

    Round one is the one that got a CVE. The fix for CVE-2026-18556, shipped in the 2026.3.1 line following the 2026.3.0 release on 30 July, was incomplete — and that incompleteness became CVE-2026-18577.

    Round two did not get a CVE. Hotfix 1, build 2026.3.1.7, released 2 August, “addressed the original access point.” On 6 August N-able released Hotfix 2, build 2026.3.1.10, described as “additional hardening measures that build on and supersede Hotfix 1.” The Hotfix 2 release notes are unusually direct about the risk of being ignored: “This is not a duplicate of our previous communication — Hotfix 2 is required, even if you already applied the earlier hotfix.”

    2026.3.1.10 is the complete fix. Self-hosted deployments on 2025.4, 2026.1, 2026.2, 2026.3, or 2026.3.1 with Hotfix 1 upgrade directly to it.

    Hosted customers are in a different position. Per the Hotfix 2 notes: “If you are on an N-central hosted instance (NCOD), mitigations have already been applied to your environment. You do not need to do anything at this time.” N-able’s timeline records mitigation deployed to hosted environments on both hotfix dates. On-premises customers download and apply manually, which is where the exposure sits.

    The vendor’s own account of what attackers did

    Exploitation here is confirmed by N-able itself, not merely alleged by a third party. The company’s account: “On July 31, our Adlumin MDR solution detected unusual activity inside a customer environment,” and “A threat actor exploited a vulnerability in N-central that allowed remote administrative access without authentication.” Scope, in N-able’s words: “A limited number of customers have been identified as impacted, and our team has directly engaged with each of them.” No threat actor has been named.

    Then the sentence that makes this an estate-wide problem rather than a server problem:

    “Once inside, they used N-central’s Take Control feature to connect to managed devices, and registered Cloudflare tunnel services on those devices to maintain persistence even after their access to N-central was revoked.”

    Read that carefully. The attackers did not merely compromise a management server. They used the management server’s legitimate remote control capability to reach the endpoints it manages, and then established independent persistence on those endpoints through a service that looks like ordinary outbound traffic. Revoking their access to N-central does not touch it.

    N-able says as much: “Applying Hotfix 2 closes the vulnerability that allowed attackers in, but it does not remove a threat actor who may already be present.” An update published 10 August includes indicators of compromise: nine IP addresses plus suspicious files, services, and account activity.

    Why it matters

    RMM platforms are the highest-leverage target in the managed services model, and everyone in the industry knows it. What makes this case instructive is not that N-central was attacked. It is the shape of the failure: a patch that was incomplete, a hotfix that needed a second hotfix, and a compromise whose reach extends into every device the platform manages by using the platform exactly as designed.

    If you are an MSP, your remediation scope is not one server. It is every endpoint that server could reach during the exposure window, and the hunt is for outbound tunnel services that will not look anomalous to anything watching for malware.

    If you are a customer of an MSP, the question to ask this week is specific: were they self-hosted or on NCOD, when did they apply build 2026.3.1.10, and what did their endpoint hunt find? “We’re patched” is not a sufficient answer to a compromise the vendor says patching does not remove.

    The three-day KEV deadlines are also worth noting for what they signal. CISA does not issue those casually, and the forensics triage requirement attached to BOD 26-04 implies an expectation that agencies look for evidence of compromise rather than simply install and move on.

    One correction to the coverage

    Reporting has framed this as attackers repeatedly defeating N-able’s fixes, with headlines suggesting exploitation continued through Hotfix 1. N-able does not say that. The vendor-documented incompleteness is the 2026.3.1 fix for CVE-2026-18556, which produced CVE-2026-18577. The Hotfix 1 to Hotfix 2 sequence is described by N-able only as a “related attack path” found through “continued monitoring on August 6” — it does not claim attackers exploited a Hotfix 1 bypass in the wild. Anyone stating that attackers defeated Hotfix 1 should attribute it to whoever is claiming it.

    One more piece of language worth flagging: The Register’s characterization of the access as “God mode” is a reporter’s coinage, not vendor wording. In this case the vendor’s own plain description is the more alarming version.

    What to do

    • Self-hosted: upgrade to 2026.3.1.10. If you applied Hotfix 1 (2026.3.1.7), you are not done — the vendor says so explicitly.
    • Hosted (NCOD): no action required, per N-able.
    • Hunt the endpoints, not just the server. Look for Cloudflare tunnel services registered on managed devices, unexpected outbound tunnel traffic, and Take Control sessions in the exposure window that nobody can account for.
    • Pull N-able’s 10 August indicators — nine IPs plus file, service, and account artifacts — and run them against your estate.
    • Treat patching as step one. The vendor states the fix does not evict an actor already present.
    • If you buy managed services, ask your provider the three questions above in writing.

    Sourcing note

    CVE descriptions and CVSS scores are NVD’s, both records in Analyzed status. KEV add and due dates were confirmed through the KEV catalog JSON and NVD’s mirrored CISA fields, which agree; cisa.gov itself is not retrievable from here. All quoted material is from N-able’s own advisories, status posts, and release notes. Exploitation is vendor-confirmed, which is the strongest category of sourcing available and distinguishes this from several other stories running this week. We could not find an authoritative vendor statement listing every affected version — N-able never publishes a clean “versions X through Y” line, so the anchors above are NVD’s ranges and the Hotfix 2 upgrade path. The total number of victims is not public beyond “a limited number,” and no attribution exists.

  • Carhartt’s breach is 12.9 million records, not 25 — and the gap is benchmark data someone left in production

    Carhartt’s breach is 12.9 million records, not 25 — and the gap is benchmark data someone left in production

    Every headline today puts the Carhartt breach at 12.9 million accounts. That number did not come from Carhartt, which has said nothing publicly, and it did not come from the attackers, who claimed roughly twice as many. It is a researcher’s downward correction — and the reason nearly half the dump evaporated under scrutiny is a lesson worth more than the breach itself.

    What happened

    ShinyHunters published data attributed to Carhartt in mid-August, claiming more than 50GB compressed covering customer, employee, and corporate records. The raw dump contained 24.8 million unique email addresses.

    Troy Hunt’s analysis, now loaded into Have I Been Pwned, puts the real figure at 12.9 million accounts, after discarding approximately 11.9 million records — about 47% of the dump — as not corresponding to real people.

    The bulk of the discard, some 11.25 million records, was synthetic TPC-DS benchmark data. TPC-DS is a standard decision-support benchmark used to test the performance of analytics and data warehouse systems. Its generated rows are identifiable once you know what to look for: fabricated email domains and birth years distributed uniformly across 1924 to 1992. The remainder of the discard was Microsoft 365 routing aliases and internal accounts with names like perftest and deactivate- prefixes.

    What survived is real, and it is not trivial. The verified records include names, email addresses, phone numbers, physical addresses, dates of birth, salutations, birth countries, and first-purchase dates. More than 15,000 @carhartt.com employee addresses are in there too.

    Carhartt has said nothing

    This is the part that should shape how you read every version of this story. There is no Carhartt statement. There is no breach notification on the company’s site. There is no entry on the California Attorney General’s breach notification portal. Reporters have asked; The Register noted the company “is yet to comment on the breach anywhere publicly,” and BleepingComputer reported a spokesperson was not immediately available.

    So the chain of custody for the number in every headline runs: attackers published a dump → a researcher analyzed it and revised the count downward → publications reported the researcher’s figure. At no point does the affected company appear. If you are briefing anyone on this, the correct phrasing is “researcher analysis of data published by ShinyHunters indicates approximately 12.9 million accounts,” not “Carhartt disclosed.”

    Several claims attached to this story come from ShinyHunters alone and have no corroboration: that the entry point was a compromised Databricks analytics platform, that a $3.3 million extortion demand was made, and that it was refused. We are not printing those as fact. They may well be true. Nothing confirms them.

    Why it matters

    The interesting question is not how big the breach was. It is why nobody — including, apparently, the attackers — could tell.

    Eleven and a quarter million rows of database benchmark data were sitting in the same environment as real customer records. Someone ran a TPC-DS workload to size or test an analytics platform, and the generated dataset was never cleaned out. When that environment was taken, the synthetic rows left with everything else, indistinguishable from real people until a researcher who knew the benchmark’s fingerprint went looking.

    Work through the consequences of that for a moment. If this had gone the ordinary route — a regulator asking how many people were affected, a notification obligation with a deadline attached — the honest answer would have been that the company could not say. Not because forensics were incomplete, but because the data itself could not be sorted into real and fake without specialist analysis of a benchmark schema. Every downstream decision depends on that number: who gets notified, in which jurisdictions, on what clock, at what cost.

    There is a second-order problem too. Test and benchmark data in production analytics environments does not just inflate breach counts. It skews the models trained on it, corrupts the metrics computed from it, and — because it looks like customer data — tends to inherit whatever access controls customer data has, which is to say fewer than it should.

    The 15,000 employee addresses deserve their own line. Corporate email addresses in a public dump are raw material for credential stuffing and for targeted phishing against a company that has not yet acknowledged it has a problem.

    The verification gap

    Step back from Carhartt for a second and look at who did the work here.

    An attacker published a dump and made a claim about its size. The affected company said nothing. No regulator has said anything. The number that every publication is now using, and that will end up in the running tallies of “biggest breaches of 2026,” was established by one independent researcher who recognized a database benchmark schema by its birth-year distribution.

    That is not a criticism of the researcher. It is an observation that breach scale — the input to notification obligations, regulatory exposure, and every “how bad was it” conversation in the industry — is increasingly established by whoever bothers to look, on no particular timeline, with no obligation to look at all. Roughly 47% of this dump was fictional. Nothing in the process that produces breach headlines would have caught that.

    The practical takeaway for anyone running IT: if your organization ends up in this position, the count that sticks is the one that gets published first and analyzed best, and it will not necessarily be yours. Being able to produce a defensible number quickly is a capability, and it starts with knowing what is actually in your data stores before anything goes wrong.

    What to do

    • Audit what synthetic and benchmark datasets are sitting in your production analytics environments. TPC-DS, TPC-H, generated load-test fixtures, anonymized-but-not-really exports. If you cannot answer where they are, you cannot answer how many people a breach affected.
    • Check whether test data inherits production access controls. It usually does, in the wrong direction — it gets the same permissive treatment as the real thing while receiving none of the scrutiny.
    • Make “can we count the victims” part of your incident response tabletop. Most exercises assume the number is knowable. This one wasn’t.
    • If you are downstream of Carhartt as a supplier or partner, note that 15,000 employee addresses are public and act accordingly on inbound mail purporting to come from them.

    Sourcing note

    The 12.9 million figure and the composition analysis are Troy Hunt’s, published on his site and reflected in the Have I Been Pwned breach entry. Carhartt has issued no statement of any kind, and no notification appears on the California AG portal; we did not check Maine, Texas, or Washington. The 50GB volume, the 24.8 million raw email count, the Databricks attack vector, the $3.3 million demand and its refusal are all ShinyHunters’ claims, and only the data volume has been independently examined. No regulator has confirmed anything about this incident.

  • GPUThor beats NVIDIA’s ECC for a root shell in about a minute — on four workstation cards, not the AI fleet

    GPUThor beats NVIDIA’s ECC for a root shell in about a minute — on four workstation cards, not the AI fleet

    University of Toronto researchers have shown that non-uniform Rowhammer patterns defeat NVIDIA’s sideband ECC on GDDR6 workstation GPUs, yielding a root shell on the host in under two minutes. Three of the four affected cards were tested on rented cloud GPUs. The coverage is getting two important things wrong, and both of them make the problem sound broader than it is.

    What happened

    GPUThor — “Amplifying Rowhammer Attacks via Non-Uniform Patterns to Exploit ECC-Protected GPUs” — has been accepted to ACM CCS 2026, one of the field’s top peer-reviewed venues. The authors are Chris S. Lin, Joyce Qu, Aditya Rajeev, and Gururaj Saileshwar, the same group behind GPUHammer in 2025.

    Four Ampere-class workstation GPUs with GDDR6 memory are affected: the RTX A4000, A4500, A5000, and A6000. The bit-flip rates are the headline finding, because they are enormous compared with prior work — 377,552 flips per gigabyte on the A5000, 114,488 on the A6000, 75,024 on the A4500, and 72,768 on the A4000. The paper claims between 500 and 23,500 times more flips than earlier GPU Rowhammer research.

    What gets defeated is sideband SECDED ECC, specifically. NVIDIA’s scheme protects 16 bytes of data with 1 byte of ECC, or 2 bytes of sideband ECC per 32 bytes of data. Single-error correction, double-error detection. The attack works by inducing multiple bit errors inside a single ECC chunk: the researchers produced 387 double-bit errors, which ECC detects but cannot correct, and 2 triple-bit errors, which pass silently as corrupted data.

    From there, corrupting GPU page tables yields arbitrary read and write access to CPU memory and a root shell on the host in 0.7 to 1.2 minutes. There is also a denial-of-service mode: roughly one uncorrectable error every two hours on an ECC-enabled A6000, costing about 13% of daily GPU availability and causing the card to flag itself as defective within a day. Exhausting the row-remapping budget also opens the door to RMA abuse.

    The threat model is shared GPU tenancy. The attacker is an unprivileged user who can launch CUDA kernels and, in the paper’s words, “co-locate with another victim user on a time-shared GPU in the cloud.” Three of the four cards were tested on rented cloud GPUs, which is what makes this a procurement question rather than a lab curiosity.

    Disclosure was coordinated: reported to NVIDIA on 29 April 2026, embargoed to 25 August, with a security notice published by NVIDIA. Code and artifacts are withheld until 15 November 2026.

    Two corrections to today’s coverage

    A100-class hardware is not in scope. This is the important one. The researchers explicitly tested HBM, GDDR6X, and newer-generation GDDR6, and observed no bit flips on any of them, which they attribute to different target row refresh implementations. Reporting that places datacenter accelerators inside the blast radius contradicts the paper it is describing. Four Ampere workstation cards flipped. The AI training fleet, as tested, did not.

    The model-accuracy result belongs to a different paper. Coverage attaching machine learning accuracy degradation to GPUThor is reaching back to the same group’s 2025 GPUHammer work, which did degrade model accuracy. GPUThor contains no ML accuracy experiments at all. It demonstrates denial of service and privilege escalation. Those are serious enough without borrowing a finding from elsewhere.

    Both errors push in the same direction — toward “Rowhammer breaks AI datacenters” — and both make the actual finding harder to act on, because they point defenders at the wrong hardware.

    Why it matters

    The value here is not that a novel memory attack exists. It is that the economics of GPU rental have quietly recreated a threat model the industry spent a decade engineering out of shared CPU infrastructure.

    Workstation-class Ampere cards are exactly what the second tier of GPU rental markets is full of. They are what you get when you rent by the hour from a provider that is not a hyperscaler, and they are what sits in university clusters, render farms, and internal shared-compute pools. In all of those, “another tenant can run a CUDA kernel next to yours” is not a hypothetical, it is the product.

    ECC is the reason those environments are considered safe to share. The finding here is that a specific, widely deployed ECC implementation does not survive contact with a patterned attack, and that the failure mode includes silent corruption — the two triple-bit errors that ECC neither corrected nor flagged. Silent corruption in a shared numerical workload is a category of problem most teams have no detection for at all.

    The denial-of-service angle deserves attention on its own. A card that flags itself defective within a day of sustained attack is a supply chain problem as much as a security one: it looks like hardware failure, it triggers an RMA, and it does not look like an attack to anyone in the loop.

    What to do

    • If you rent GPU capacity, ask specifically about tenancy isolation on Ampere workstation SKUs. Not about the provider’s datacenter fleet, which is not what was broken. The question is whether A4000/A4500/A5000/A6000 capacity is time-shared between tenants, and what sits between them.
    • Enable SYS-ECC and IOMMU/DMA isolation where you control the host.
    • Start collecting GPU ECC error counters. A rise in correctable errors is the early signal, and most shops are not looking at this telemetry at all. It is also how you distinguish an attack from a genuinely failing card before you ship it back.
    • Treat sustained uncorrectable errors on shared GPUs as a security event, not solely a hardware fault, until you can rule out the alternative.
    • Note the 15 November date. Artifacts become public then. Whatever isolation review this prompts should be finished before that, not started after it.

    Sourcing note

    This is the best-sourced item we have run: a peer-reviewed paper accepted to ACM CCS 2026, named researchers at a named institution, coordinated disclosure with a four-month embargo, and a vendor security notice on record. Bit-flip counts, affected models, timings, and the negative results on HBM and GDDR6X all come from the paper itself. NVIDIA’s security notice could not be retrieved directly — the host blocks automated fetching — so its exact wording, affected-product list, and severity rating are unverified at primary, and no CVE is mentioned in any primary source we could reach. There is a minor date conflict on when NVIDIA published: the paper and project page say 25 August, one outlet says 21 August. Exploit code is not public until 15 November 2026.

  • vCenter servers are being backdoored five days after the patch, and Broadcom still hasn’t mentioned exploitation

    vCenter servers are being backdoored five days after the patch, and Broadcom still hasn’t mentioned exploitation

    CISA gave federal agencies three days to fix a vCenter directory traversal flaw. A German incident response firm has since mapped 361 victim IP addresses across 47 countries, with a persistence chain deep enough that patching does not remediate it. Broadcom’s advisory, now at its third revision, still says nothing about exploitation at all — and this is not the zero-day it is being called.

    What happened

    CVE-2026-59310 is a directory traversal vulnerability in the vCenter Syslog server leading to arbitrary code execution. Broadcom’s own description, as the CNA: “VMware vCenter contains a directory traversal vulnerability in the Syslog server. A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.” CWE-22, CVSS 9.8.

    It arrived in VMSA-2026-0006, published 29 July 2026, now at revision .2. The advisory covers five CVEs across ESX, vCenter, Workstation, and Fusion. A companion flaw, CVE-2026-59309, is an authentication bypass in VMware Directory Service, also scored 9.8. There are no workarounds for any of them. Both vCenter flaws are credited to Phil Brass and Matt South of Atredis Partners.

    Fixed versions for vCenter Server:

    • 9.1.x → 9.1.0.0300
    • 9.0.x → 9.0.2.0100
    • 8.0 through U3j → 8.0 U3k, or express patch 8.0 U2f
    • 7.0 → no build listed; the advisory says contact Broadcom Support. This guidance was added only at revision .2 on 19 August, three weeks after the original advisory.

    Cloud Foundation, vSphere Foundation, Telco Cloud Infrastructure and Telco Cloud Platform are also in scope. Note that CVE-2026-59309 was first fixed in 9.1.0.0200, but 9.1.0.0300 is the current build.

    CISA added CVE-2026-59310 to the Known Exploited Vulnerabilities catalog on 18 August, with a remediation deadline of 21 August — a three-day window, citing BOD 26-04 rather than the familiar BOD 22-01. CISA’s own enrichment record sets the exploitation status to Active, automatable, with total technical impact.

    The patch gap is the story

    QUIRSO, a German DFIR firm, published a campaign timeline that is the most useful thing written about this flaw. Advisory published 29 July. First signs of CVE-2026-59309 exploitation on 1 August. First victim callbacks for CVE-2026-59310 on 3 August — five days after the fix was available. Roughly 95% of the eventual victims were compromised by 5 August.

    That is a one-week window between a public patch and mass compromise, and it is the number worth carrying into your next patching conversation. The failure mode here was not an unknown flaw. It was a known flaw on an appliance nobody had a maintenance window for.

    QUIRSO counts 361 unique victim IP addresses across 47 countries. The top five: Germany (55), the United States (41), Turkey (38), Iran (26), France (25). None in mainland China.

    What the attackers leave behind

    From a single incident response engagement on one compromised appliance, QUIRSO documents a persistence chain with heavy redundancy:

    • reverse_ssh, an open-source SSH-based remote access tool, making outbound connections to attacker infrastructure for shell, file transfer, and network forwarding
    • A systemd service, sys-9436d8.service, continuously restarting a backdoor binary named linuxFile in /root/.local/share/cg4nQW9TOxeq/
    • Cron jobs masquerading as legitimate VMware tasks: vmware-vpxd-stats-*, vmware-perf-collect-*, vmware-perf-sync-*
    • A JSP webshell, vmware-perf-update.jsp, dropped into Perfcharts directories
    • Root SSH keys appended to authorized_keys, plus sudoers entries granting passwordless sudo
    • Rogue SSO administrator accounts: adminuser, vcadmin, svc_<ID>

    Six independent footholds, three of them named to blend into VMware’s own scheduled work. Applying the patch removes none of them.

    On attribution, QUIRSO assesses “with moderate confidence that the exploitation campaign targeting CVE-2026-59310 is operated by a Chinese-speaking threat actor,” citing Chinese-language artifacts, tooling, victimology, and UTC+8 activity patterns. They are explicit about the limits: “QUIRSO currently has insufficient evidence to associate the campaign with a named Chinese threat group or determine that it is directed by the Chinese state.” We are reporting that as they wrote it.

    Three things the coverage is getting wrong

    Broadcom has not confirmed exploitation. VMSA-2026-0006 contains no exploitation statement through revision .2, published 19 August — one day after the KEV listing. The word “exploit” appears only in the generic “a malicious actor may exploit this issue” phrasing that every advisory carries. Any sentence of the form “Broadcom warned that attackers are exploiting” or “VMware confirmed active exploitation” is wrong. The parties asserting exploitation are CISA and QUIRSO.

    This is not a zero-day. Several outlets have run it as one. By QUIRSO’s own timeline, exploitation began five days after the patch shipped. That is patch-gap exploitation, which is a different problem with a different fix — and frankly a more uncomfortable one, because it is entirely within your control.

    The ransomware claim has no source. At least one aggregator asserts Babuk-derived ransomware in connection with this CVE, attributing it to “social media reports.” QUIRSO’s own forensic report describes no ransomware whatsoever. We are not running it, and neither should anyone else without something to point at.

    What to do

    • Patch to the builds above. On 7.0, you need to contact Broadcom Support — there is no published build, and that guidance did not exist until three weeks after the advisory.
    • If your vCenter was network-reachable and unpatched at any point between 29 July and now, hunt before you assume you are fine. Look for unexpected systemd services, cron entries impersonating VMware tasks, JSP files in Perfcharts directories, additions to root’s authorized_keys, sudoers modifications, and SSO administrator accounts nobody created.
    • Rotate SSO credentials on any appliance you cannot rule out.
    • Do not treat patching as remediation. The documented persistence survives it, by design.

    Sourcing note

    The CVE description and CVSS come from Broadcom as CNA; NVD carries no independent primary score. KEV add and due dates were confirmed through NVD’s mirrored CISA fields and a second catalog mirror, as cisa.gov itself is not retrievable from here. Exploitation is asserted by CISA and by QUIRSO, not by Broadcom, whose advisory remains silent. The 361 figure counts unique victim IP addresses observed contacting attacker infrastructure — it is not 361 forensic investigations, and the detailed persistence chain above comes from a single IR case. Attribution is QUIRSO’s, at moderate confidence, with the firm itself stating it cannot tie the activity to a named group or to state direction. An earlier Rapid7 assessment finding no evidence of exploitation predates both the QUIRSO report and the KEV listing and should not be quoted as current. We could not verify the KEV catalog’s ransomware-use flag for this entry.

  • PaperCut is under active attack with no CVE, and the emergency patch skipped its own release process

    PaperCut is under active attack with no CVE, and the emergency patch skipped its own release process

    PaperCut has confirmed that customers are being attacked through an unpatched flaw in its NG and MF print management servers. There is no CVE. There is no entry in CISA’s Known Exploited Vulnerabilities catalog. The emergency builds that shipped overnight do not appear on PaperCut’s own release history, and the vendor says they did not go through its normal release process. If you run PaperCut, the mitigation is the response.

    What happened

    PaperCut published an urgent security bulletin on 27 August 2026 covering PaperCut NG and PaperCut MF. In the vendor’s own words, quoted identically by four outlets that read the bulletin: “We are aware of confirmed customer incidents and are treating this matter with the highest priority.” The company adds that its investigation is ongoing, and has not disclosed the vulnerability itself, the attack method, or who is behind it.

    No CVE identifier has been assigned. This matters more than it sounds: KEV entries are keyed on CVE IDs, so PaperCut’s absence from the catalog is not an oversight by CISA, it is structurally impossible until an identifier exists. Federal remediation deadlines do not attach to this yet, and may not for days.

    Be careful with the CVE search results. Two PaperCut CVEs were published on 3 August 2026 — CVE-2026-8793 (excessive authentication attempts, CVSS 6.9) and CVE-2026-8794 (a timing discrepancy enabling username enumeration, CVSS 6.9) — both fixed in 26.0.3 back in July. Neither is this flaw. At least one vulnerability database frames CVE-2026-8794 as “the August 2026 bulletin,” which invites exactly the wrong conclusion.

    PaperCut’s stated mitigation is unambiguous: “If your PaperCut NG/MF Application Server is accessible from the public internet, immediately restrict web access to trusted IP addresses only.” Reporting indicates the guidance extends to taking servers offline entirely where access cannot be restricted, and that administrators should act even without evidence of compromise.

    The indicators of compromise, consistent across every outlet that read the bulletin:

    • Suspicious activity from the pc-app.exe process
    • Missing, truncated, or deleted server.log files
    • ERROR No suitable driver found for jdbc:no:x
    • ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST
    • IDS, EDR, or network monitoring alerts referencing the Application Server

    PaperCut also warns that the absence of these indicators does not mean a server is clean, because the attackers delete logs behind them. That is an unusually honest thing for a vendor to put in writing, and it should shape how you interpret a quiet hunt.

    The patch that isn’t quite a patch

    Emergency builds went out at approximately 2:10 a.m. AEST on 28 August, covering the version 25 and version 26 branches across Windows, Linux, and macOS. Version 24 had no fix at the time of writing.

    Four build numbers are circulating: PaperCut MF 26.0.4 build 76494, NG 26.0.4 build 76495, MF 25.0.12 build 76496, and NG 25.0.12 build 76497. Huntress lists the 25.0.12 pair; two other outlets list all four, matching exactly.

    None of these builds appear on PaperCut’s own release history pages. As of checking, NG and MF 26.0 release history still show 26.0.3 as newest, dated 28 July. The 25.0 histories still show 25.0.11, dated 5 May. PaperCut’s MF version-check page still advises upgrading to 26.0.3.

    There is a coherent explanation, and it is itself the newsworthy part. The Register reports PaperCut is distributing an emergency patch that “has not gone through our usual release process.” A second outlet carries the same characterization. These appear to be genuine out-of-band builds shipped outside the normal channel — which is why the version checker does not know about them.

    That is a defensible decision by a vendor under fire. It is also a decision whose risk you inherit when you install it: a build that skipped the usual QA, applied to a server that sits in the middle of your network.

    What exploitation actually looks like

    Huntress reports limited exploitation across two customer environments, the first on 26 August and the second on 27 August. In the first, the exploitation window lasted under two minutes.

    The observed activity: base64-encoded reconnaissance commands written into server.log — whoami & ver and whoami & ver & tasklist. Malicious Java class files recovered from an infected Windows host, named Udydn.class and Moo97.class, writing output to Udydn.out and Udydn.cmd. The tooling is OS-agnostic across Linux and Windows, and it self-deletes along with its logs. A further log artifact worth grepping for: DB URL: jdbc:derby:memory:pwn.

    Separately, and in a lab rather than in the wild, Huntress reproduced a pre-authentication remote configuration takeover and a full remote code execution chain against build 25.0.11.75758. Their description of the root cause: “A specifically crafted request can refer to one page that is rendered for the response, and another page that owns the component or action being executed,” such that “PaperCut’s authorization check could trust the rendered page and miss the permissions required by the component behind it.”

    That is an authorization-bypass-to-RCE characterization from Huntress. PaperCut has published no technical detail of its own. The “pre-auth RCE” framing in today’s headlines traces to Huntress’s lab work, not to the vendor.

    Why it matters

    Print management is one of those categories that acquires enormous privilege without anyone deciding it should. The Application Server holds credentials, reaches directory services, touches file systems across the estate, and tends to be exempted from the network segmentation applied to things people think of as sensitive.

    The 2023 precedent is the reason this is being taken seriously: CVE-2023-27350 in PaperCut MF/NG ended with Cl0p and LockBit deployments against organizations that did not move fast. No connection between that flaw and this one has been established by anyone, and searching for PaperCut attacks surfaces a great deal of 2023 attribution — Cl0p, LockBit, Lace Tempest, Iranian state-backed groups — that belongs to a different vulnerability. Nobody has named an actor in this campaign. PaperCut explicitly has not.

    One practical trap: PaperCut’s product pages currently carry an “URGENT security message for all NG/MF customers” banner. It links to a bulletin titled “URGENT MF/NG vulnerability bulletin (March 2023)” — the CVE-2023-27350 advisory. Anyone following the site’s own banner lands on a three-year-old page.

    What to do

    • Restrict Application Server web access to trusted IP ranges now, or take it off the internet. This is the vendor’s instruction and it does not depend on a build number existing, being verifiable, or having passed QA.
    • Hunt the indicators above, and treat a clean result as inconclusive. The vendor says so itself. Deleted or truncated server.log files are the signal, and their absence is not an all-clear.
    • If you apply the emergency build, do it knowing it bypassed normal release QA. That is a tradeoff to make deliberately, not a free action.
    • On version 24, there was no fix at the time of writing. Mitigation is all you have.
    • Do not follow the banner on PaperCut’s product pages. It goes to the 2023 advisory.

    Sourcing note

    PaperCut’s bulletin body does not render to automated retrieval; every vendor quotation above is taken from outlets that read it directly, and the quoted lines appear near-identically across BleepingComputer, Help Net Security, Security Affairs, and The Register. The build numbers are reported by Huntress and two other outlets and do not appear on PaperCut’s own release history pages — treat them as reported, not vendor-confirmed. The technical root-cause analysis and the exploitation observations are Huntress’s, not PaperCut’s. No CVE has been assigned. Not in CISA KEV, which requires a CVE. No threat actor has been named by anyone, and ransomware attribution found in search results belongs to the 2023 PaperCut flaw, not this one. A report that the vulnerability was discovered by a university customer’s internal security team appears in one outlet only and is not vendor-confirmed.