Severity Daily

IT and AI security incidents, checked against the primary source

Tag: NVD

  • A libuser flaw on a federal clock scores 5.1 for denial of service. Red Hat, Qualys, and a Metasploit module all say it yields root.

    A libuser flaw on a federal clock scores 5.1 for denial of service. Red Hat, Qualys, and a Metasploit module all say it yields root.

    What happened

    CISA added CVE-2015-3246 to the Known Exploited Vulnerabilities catalog on August 26, 2026. NVD’s record republishes CISA’s fields verbatim: cisaExploitAdd of 2026-08-26, cisaActionDue of 2026-09-09, and cisaVulnerabilityName of “Red Hat Libuser Race Condition Vulnerability.” Federal civilian agencies have until September 9, 2026.

    What changed four days ago is the federal obligation. The vulnerability was published on August 11, 2015. What makes it worth reading now is that the score most vulnerability tools will show for it describes a different, and far less serious, vulnerability than the one Red Hat, the original researchers, CISA, and a Metasploit module all describe.

    NVD’s description reads: “libuser before 0.56.13-8 and 0.60 before 0.60-7, as used in the userhelper program in the usermode package, directly modifies /etc/passwd, which allows local users to cause a denial of service (inconsistent file state) by causing an error during the modification.” Denial of service. Nothing about privileges.

    The scoring is where it gets awkward. NVD’s record carries exactly two metrics entries, and they are not the same kind of thing. The CVSS v3.1 entry is secondary, sourced to 134c704f-9b21-4f2e-91b3-4a467353bcc0 — Red Hat’s CNA identifier — at 5.1 medium, vector CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. Read that vector: confidentiality none, integrity none, availability high. It says this bug cannot read anything and cannot change anything. There is no CVSS v3 primary from [email protected] at all. The only NVD primary entry on the record is a CVSS v2.0 score of 7.2, vector AV:L/AC:L/Au:N/C:C/I:C/A:C — complete confidentiality, complete integrity, complete availability impact. The record is listed as “Analyzed.” Its weaknesses are CWE-264 as primary and CWE-367, time-of-check to time-of-use, as secondary.

    So the same government record contains a 2015-era score saying total system compromise and a modern score saying availability-only, with no modern score from NVD itself to arbitrate. Almost every scanner, ticketing integration, and risk dashboard built in the last decade surfaces the v3 number.

    Everyone who has looked at the bug directly says it yields root.

    Red Hat’s own page for the CVE rates it Important and describes it this way: “A flaw was found in the way the libuser library handled the /etc/passwd file. A local attacker could use an application compiled against libuser (for example, userhelper) to manipulate the /etc/passwd file, which could result in a denial of service or possibly allow the attacker to escalate their privileges to root.” Red Hat’s own CVSS v2 base score is 6.8.

    Qualys, which disclosed the issue in July 2015 alongside CVE-2015-3245, was explicit about which half of the pair carried the impact. In its advisory, CVE-2015-3245 on its own is a local denial of service; CVE-2015-3246 is the one Qualys turned into a local root exploit against userhelper. CISA added CVE-2015-3246 and left CVE-2015-3245 off the catalog, which matches the research. The catalog got the selection right and inherited a description that got the impact wrong.

    A packaged exploit has been public for eight years. Exploit-DB entry 44633, “Libuser – ‘roothelper’ Local Privilege Escalation (Metasploit),” dated May 16, 2018, credits Brendan Coles working from the Qualys research. It inserts a UID 0 account into /etc/passwd and lists tested targets across CentOS 6.0 through 7.1, Fedora 13 through 22, and Red Hat 6.6 through 7.0. It requires the current user’s password.

    The exploitation evidence behind the KEV addition is a single vendor’s research. Cisco Talos published a report on August 20, 2026 on an actor it tracks as UAT-10147, which it characterizes as a “Chinese-speaking cybercrime group.” That report names this CVE directly: “CVE-2015-3246 abuses a flaw in libuser’s roothelper component, where improper file handling allows a local attacker to corrupt the ‘/etc/passwd’ file and gain root-level access.” Talos names six Linux local privilege escalation vulnerabilities in the actor’s post-compromise toolkit. Three of them — this one, CVE-2015-5287 in Red Hat’s Automatic Bug Reporting Tool, and CVE-2022-0995 in the Linux kernel’s watch_queue subsystem — were added to KEV on August 26, 2026 with the same September 9 deadline. The other three were already listed: CVE-2021-3156 since April 6, 2022 and CVE-2022-0847 since April 25, 2022, with CVE-2010-3904 the remaining name.

    Counting the initial-access side, that single August 20 report accounts for four of the six vulnerabilities CISA added on August 26. The fourth is CVE-2021-23758 in AjaxPro, whose record has problems of its own. The two additions that do not trace to Talos are the Citrix NetScaler flaw and a 2019 Microsoft SQL Server bug.

    Why it matters

    A federal deadline is a queue-ordering instruction, and the queue is ordered by score. An agency or a company that pulls this CVE into a sprint sees 5.1, medium, availability-only, and a 2015 publication date. Nothing in the v3 vector suggests that clearing it is urgent, because the vector explicitly states the flaw cannot compromise confidentiality or integrity. The entry that says otherwise is a CVSS v2 score, and v2 has been formally superseded for so long that a great deal of tooling neither displays it nor lets you sort on it.

    This is a specific failure mode worth naming: a CVE old enough to have been scored under v2 by NVD, then scored under v3 only by its CNA, ends up with its most authoritative modern number supplied by a party that scored a narrower reading of the flaw. NVD’s own backfill never reached it. The result is not a disputed score in the ordinary sense, where two parties assess the same behavior differently. It is a record where the two numbers are describing different vulnerabilities and nothing on the page says so.

    The catalog listing partially repairs this, which is the argument for KEV mattering more than severity. But the repair is incomplete, because CISA’s required action is the standard text and carries no impact information. An operator who reads the KEV entry, then clicks through to the CVE to understand what they are fixing, lands on the denial-of-service description and the 5.1.

    The provenance is also worth stating plainly, because it is unusual. Four of six additions in one batch resting on one vendor’s report is not a criticism of the report — Talos names the CVEs, quotes the mechanism, and the underlying exploits are old and public, so nothing here is speculative. It is a statement about concentration. There is currently no second vendor’s telemetry in public confirming that this specific 2015 flaw is being exploited in 2026. That is the sourcing an agency is acting on, and it should be visible in the ticket rather than implied by the catalog’s authority.

    What to do

    Fixed packages are libuser 0.56.13-8 or later on the 0.56 line and 0.60-7 or later on the 0.60 line, shipped in RHSA-2015-1482 and RHSA-2015-1483. Any supported Red Hat Enterprise Linux, CentOS, or Fedora build patched since late 2015 already carries them.

    The exposure is old systems, and Red Hat says so directly: it lists the RHEL 5 packages as not currently planned to be addressed in future updates. If you are running RHEL 5 or a derivative of that vintage — and the reason this bug is in an active toolkit is that such systems are still reachable — there is no vendor fix coming. Removing the setuid bit from /usr/sbin/userhelper, or removing the usermode package where nothing depends on it, closes the path that the public exploit uses.

    Check what actually calls libuser rather than assuming the library alone is the risk. The exploit path runs through userhelper in the usermode package; that binary being setuid root is what turns file corruption into privilege escalation.

    For detection, the public exploit writes a UID 0 entry into /etc/passwd. Alert on new accounts with UID 0 and on unexpected modifications to /etc/passwd. That is a cheap rule and it covers the packaged technique directly. Because this is a local privilege escalation, it also implies something upstream already went wrong — treat a hit as post-compromise activity and look for the initial access, not just the escalation.

    If you are triaging by score, override this one. The 5.1 is not describing what the exploit does.

    Sourcing note

    KEV dates come from NVD’s record for CVE-2015-3246, which republishes CISA’s cisaExploitAdd, cisaActionDue and cisaVulnerabilityName fields. CISA’s catalog pages return 403 to automated fetching, so the catalog was not read directly; the values here are NIST’s republication, and the August 26 batch was cross-checked against a third-party KEV mirror and against the individual NVD records for each CVE named. Metrics, weakness identifiers, and reference lists were read from NVD; the CVE-2015-3245 record was checked and confirmed to carry no CISA fields. Red Hat’s description, severity rating and lifecycle statement come from its own CVE page. The Qualys advisory of July 2015 was read for the division of impact between the two CVEs. The Metasploit module details come from Exploit-DB entry 44633. Exploitation is single-sourced to Cisco Talos’s August 20, 2026 report on UAT-10147; we found no independent corroboration.

    One inconsistency we could not resolve: NVD’s reference lists for CVE-2015-3246, CVE-2015-5287 and CVE-2021-23758 all carry the Talos report, but the reference list for CVE-2022-0995 — added the same day, named in the same report — does not. We do not know whether that is a backfill lag or a deliberate difference. Also unresolved is whether NVD intends to add a v3 primary score to a record whose only modern score comes from the CNA and reads availability-only.

  • AjaxPro shipped a deserialization fix in November 2021. The CVE now on a federal clock still says no fixed version exists.

    AjaxPro shipped a deserialization fix in November 2021. The CVE now on a federal clock still says no fixed version exists.

    What happened

    CISA added CVE-2021-23758 to the Known Exploited Vulnerabilities catalog on August 26, 2026. NVD’s copy of the record carries CISA’s own fields verbatim: a cisaExploitAdd of 2026-08-26, a cisaActionDue of 2026-09-09, and a cisaVulnerabilityName of “Ajax.NET Professional Deserialization of Untrusted Data Vulnerability.” Federal civilian agencies have until September 9, 2026. NVD last modified the record on August 27, 2026 and marks its status “Analyzed.”

    What changed on August 26 is the federal obligation, not the bug: the vulnerability was published on December 3, 2021. What makes the addition worth reading is that the record an agency will consult to satisfy the deadline does not agree with itself about whether a patched version exists.

    AjaxPro, or Ajax.NET Professional, is one of the oldest AJAX frameworks for ASP.NET, supporting .NET versions back to 1.1. CVE-2021-23758 is a deserialization flaw in it. The CVE record, assigned by Snyk, describes it in one sentence: “All versions of package ajaxpro.2 are vulnerable to Deserialization of Untrusted Data due to the possibility of deserialization of arbitrary .NET classes, which can be abused to gain remote code execution.” The credited reporter is Hans-Martin Münch of MOGWAI LABS, with a disclosure date of November 21, 2021.

    Three things in the public record do not line up.

    Whether a fix exists. Snyk’s advisory for this CVE states flatly that there is no fixed version for AjaxPro.2, and the CVE record’s affected-version array says the same thing structurally: version 0, status affected, no upper bound. The GitHub Advisory Database entry for the same CVE, GHSA-6r7c-6w96-8pvw, says the opposite. It lists the affected range as 21.11.29 and earlier and names a patched version: 21.11.29.1. That entry was published on December 5, 2021 and last updated on February 3, 2026.

    Whether the vendor acted. The vendor’s own release history supports GitHub’s reading. Release v21.11.22.1, dated November 22, 2021, is described in its notes as having “Changed behavior of types deserialization to deny.” Release v21.11.29.1, dated November 29, 2021, is described as having “Fixed missing custom deserialization filter for converters” and having removed a default converter. The commit that introduced the allow-and-deny list for deserializable types, “added allowed customized types,” is dated October 27, 2021 — and it is cited as a reference on the CVE record itself. The maintainer shipped a deserialization control before the CVE was published, and the CVE links to that commit while still describing every version as vulnerable.

    Which package this is. The CVE names the package ajaxpro.2. On NuGet, the package published under that identifier has exactly two versions, the newer of them 6.10.6.2, published on July 5, 2016, with 129,890 downloads. It never received the 2021 changes and it displays no vulnerability banner. The maintained package is published under a different identifier, AjaxNetProfessional, whose latest version is 24.10.10.1, published on October 10, 2024, with roughly 33,900 downloads across all versions. That is the package GitHub’s advisory maps the CVE to. NuGet does flag several 2021-era AjaxNetProfessional versions as carrying critical- or high-severity vulnerabilities. It flags nothing on the package whose name appears in the CVE.

    The scores diverge too. NVD carries two CVSS v3.1 entries: a primary from [email protected] at 9.8 critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and a secondary from [email protected] at 8.1 high, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Identical but for attack complexity. GitHub carries the 9.8 figure.

    The exploitation evidence is a single vendor’s research. Cisco Talos published a report on August 20, 2026 on an actor it tracks as UAT-10147, which it characterizes as a “Chinese-speaking cybercrime group” and, with moderate-to-high confidence, as representing “an emerging class of financially motivated intrusion operators leveraging agentic AI systems.” Talos describes “AI-generated operational playbooks, exploit automation scripts, and troubleshooting logic supporting real-world intrusions.” CVE-2021-23758 is one of four initial-access vulnerabilities named, alongside CVE-2022-27925 in Zimbra, CVE-2019-18935 in Telerik UI for ASP.NET AJAX, and CVE-2021-29441 and CVE-2021-29442 in Nacos. Talos reports a target list of approximately 170,000 URLs and victims in Brazil, Bolivia, China, Canada, and Vietnam across government, education, media, technology, and gaming. A target list is not a victim count, and the report does not put a number on successful compromises.

    Why it matters

    CISA’s required action for this entry is the current boilerplate: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s ‘Forensics Triage Requirements.’ Follow applicable BOD 26-04 guidance for cloud services or discontinue use if mitigations are unavailable.” We have written before about how little that sentence distinguishes one entry from another.

    Here it distinguishes a great deal, because the clause that fires depends on which database the agency read. “Apply mitigations in accordance with vendor instructions” and “discontinue use if mitigations are unavailable” are very different orders. An agency that resolves the CVE through GitHub’s advisory sees a patched version, upgrades, and closes the ticket. An agency that resolves it through the CNA’s own advisory — the authority that assigned the identifier — sees that no fixed version exists, and the required action tells it to rip the framework out of whatever application depends on it, inside 14 days. The record does not adjudicate between those two outcomes. It supports both.

    The package-identity split compounds it, in a way specific to how this work is actually done. Nobody reads CVE prose to find affected assets; they match package identifiers against a bill of materials. A scanner keyed to the CVE’s identifier looks for ajaxpro.2 and finds a package frozen in 2016 that the registry flags with nothing — while the CVE naming it says every version is vulnerable. The two most likely automated answers to “am I affected” are wrong in opposite directions.

    None of this is exotic. It is the ordinary consequence of a record written once in 2021, describing a package by an identifier that was already stale, and never revised as the vendor fixed the flaw and moved distribution elsewhere. For five years that cost nothing. BOD 26-04 derives federal remediation deadlines partly from KEV listing, which converts a dormant record into a dated obligation. Its defects become operational on the day it is added, and are inherited exactly as written.

    The exploitation evidence carries a second-order point. On Talos’s account, a 2021 flaw in an obscure AJAX framework is being worked at scale in 2026 because building an exploitation workflow for an obscure target no longer costs an operator much. If that holds, the population of old, low-profile CVEs worth weaponizing gets larger, and more of them will arrive on federal clocks carrying record defects nobody has examined in years.

    What to do

    Search your inventory for both identifiers, not one: AjaxPro.2 and AjaxNetProfessional. Search the assembly name too — the October 2021 commit renamed it from AjaxPro to AjaxPro.2 — and the vendored copies a framework of this vintage leaves in bin directories rather than a package manifest.

    If you are on AjaxNetProfessional, GitHub’s advisory puts the patched version at 21.11.29.1; the current release is 24.10.10.1, published October 10, 2024. Move to the current release rather than to the minimum that clears the advisory.

    If you are on the AjaxPro.2 NuGet package, treat the absence of a registry warning as meaningless. That package has not been updated since July 5, 2016 and cannot contain the November 2021 deserialization changes. Migrate to the maintained package or drop the dependency.

    Whichever package you are on, set the deserialization allow list. The vendor’s configuration exposes a jsonDeserializationCustomTypes setting with allow and deny lists governing which classes can be instantiated during deserialization; the default posture was changed to deny in November 2021. Confirm the setting is present and restrictive in your own configuration rather than assuming the version’s default.

    Check exposure as well as version. This is a framework endpoint reachable without authentication, so the question is whether an AjaxPro handler is routable from the internet, not only whether the assembly is current. Federal agencies working the September 9 deadline should also document which advisory they relied on: given that the CNA record says no fix exists, an assessor reading that same record could reasonably ask why the framework was upgraded rather than discontinued.

    Sourcing note

    KEV dates come from NVD’s record for CVE-2021-23758, which republishes CISA’s cisaExploitAdd, cisaActionDue, cisaVulnerabilityName and cisaRequiredAction fields. CISA’s own catalog pages return 403 to automated fetching, so the catalog was not read directly; the values here are NIST’s republication, cross-checked against a third-party KEV mirror. Affected-version data, CNA identity, and CVSS metrics were read from the CVE Program’s API record and from NVD. The competing patched-version claim comes from the GitHub Advisory Database entry GHSA-6r7c-6w96-8pvw and the no-fix claim from Snyk’s advisory SNYK-DOTNET-AJAXPRO2-1925971. Release dates, release-note wording, and the commit message were read from the vendor’s GitHub repository. Package version and download figures were read from NuGet’s package pages. Exploitation is single-sourced to Cisco Talos’s August 20, 2026 report on UAT-10147; we found no independent corroboration, and the 170,000 figure is Talos’s count of a target list, not of victims. The Packet Storm exploit file referenced by the CVE record could not be retrieved — the host disallows automated fetching — so its contents are not characterized here beyond the title NVD carries.

    Unresolved: whether Snyk intends to revise an advisory that says no fix exists for a package the vendor stopped shipping in 2016, and whether NVD will reconcile a description that calls all versions vulnerable with the fix commit its own reference list links to. The attack-complexity split behind the 9.8 and 8.1 scores is also unexplained publicly.

  • Unitree G1 robots take root code execution from Bluetooth range, and no one has named a fixed firmware version

    Unitree G1 robots take root code execution from Bluetooth range, and no one has named a fixed firmware version

    Two CVE records published August 27 describe unauthenticated root code execution on the Unitree G1 EDU humanoid, one of them reachable from Bluetooth range with no pairing — and neither the CVE records, the assigning CNA, nor Unitree names a firmware version that fixes it.

    What happened

    On Thursday, August 27, 2026, security researcher Olivier Laflamme published a technical writeup of two remote code execution chains in the Unitree G1 EDU humanoid robot, along with a proof-of-concept toolkit on GitHub. NVD published both CVE records the same day at 8:18 p.m. UTC. VulnCheck is the assigning CNA for both.

    CVE-2026-76639 carries a CVSS 3.1 base score of 8.8 and a CVSS 4.0 base score of 8.7, both supplied by VulnCheck. NVD’s record describes “an unauthenticated remote code execution vulnerability that allows network-adjacent attackers to execute arbitrary commands as root by chaining three weaknesses: an unauthenticated WebRTC-to-DDS bridge on TCP port 9991, a static AES-128 key stored with world-readable permissions, and a path traversal flaw in the chat_go knowledge upload API.” The researcher adds the last step: files written through the knowledge-base upload are executed by a service whose command whitelist is evaluated only once, at import time.

    CVE-2026-76640 is scored 7.5 on CVSS 3.1 and 7.7 on CVSS 4.0. VulnCheck titles it “Unitree G1 EDU 1.5.2 BLE GATT RCE via WiFi Provisioning Stack” and describes chained flaws that “allow unauthenticated proximate attackers to achieve root code execution without pairing or credentials.” The chain runs five links deep: a Bluetooth Low Energy characteristic that accepts writes with no authentication requirement, retrieval of the device’s RSA-wrapped AES key, a cloud API that decrypted and returned that key without verifying the requester owned the robot, an unquoted heredoc variable in the WiFi provisioning path, and a buffer overflow in the SSID chunk accumulator that overruns a 500-byte buffer and corrupts a function pointer.

    Both VulnCheck advisories give affected versions as “G1 EDU <= 1.5.2.” Neither names a patched version. Both CVE records carry an NVD vulnStatus of Received, meaning NVD has not yet performed its own analysis and the CNA’s scores are the only ones that exist.

    This is single-researcher work on a single product line, covering four G1 EDU units running firmware 1.5.1.1 and 1.5.2. The robot lists at roughly $20,000 and sells primarily into universities, research groups, and industrial pilots. There is no public count of how many are deployed, and this page does not estimate one.

    Unitree’s role was not adversarial. The researcher’s timeline records the robot arriving on April 29, 2026, the first chain working by May 10 and verified by Unitree on May 14, the second completed June 25 and validated June 30, a $5,000 bounty paid August 6, and CVE requests filed August 18. He describes the vendor’s security team as “were awesome to work with” and notes that “Unitree was already aware of some of these issues internally.” Unitree implemented at least one fix in that window: “an account-to-robot cloud binding ownership check before returning the AES-128 key.”

    Why it matters

    The most useful thing here is not either chain individually. It is that the highest-leverage repair was made in a cloud backend, and the rest was not made anywhere an owner can see.

    Consider what the ownership check fixed. The BLE chain did not break because Bluetooth is insecure; the designers knew the transport was open and layered encryption on top of it. It broke because the key for that encryption could be obtained by asking a cloud API for it, and the API answered without checking whether the asker owned the robot. That is an authorization bug in a web service, and Unitree fixed it server-side. No owner had to do anything. No owner could have done anything. No owner can verify it was done, roll it back, or confirm which robots it covers. For a class of device where firmware updates are slow, physically inconvenient, and sometimes skipped entirely, the vendor’s ability to repair the important link centrally is a genuine advantage, and it should be counted as one.

    It is also why the silence on firmware is the operative finding. The unquoted heredoc variable, the SSID buffer overflow, the DDS bridge on port 9991, the path traversal in the upload API, and the whitelist evaluated only at import time are all defects in code running on the robot. Fixing the cloud ownership check removes one link from one of the two chains. It does not touch the others. An owner reading these records today learns that firmware through 1.5.2 is vulnerable, that a working toolkit is published, and that there is no version number above 1.5.2 named by anyone as the fix. There is nothing to write on a change ticket. Searching for a Unitree security advisory turns up coverage of the research and no vendor page. The Hacker News reports it asked Unitree to confirm fixed firmware versions and affected scope and had not received an answer.

    The provisioning path is the recurring lesson, and it is not specific to robots. Any device set up out of the box has to accept its first configuration over a channel that cannot be authenticated, because no credential exists yet. That bootstrapping path is unauthenticated by construction — the hardest surface in the product to get right and, judging by how often it fails, one of the least reviewed. A BLE characteristic accepting bare writes is not itself the bug; it is the design premise. The bug is what the code behind it does with what it receives, and here it accumulated attacker-controlled SSID chunks into a fixed buffer without bounding them.

    Then there is what root on this device reaches. A humanoid robot is a Linux computer with a real-time kernel, microphones, cameras, and limbs, standing in a room with people in it; the security and safety questions stop being separable. The researcher also found production third-party API credentials on the robot’s locomotion computer — keys for cloud speech synthesis, voice recognition, and music services from several providers — so root on one robot reaches the vendor’s paid accounts with third parties, a billing and abuse exposure that extends past both the owner and Unitree. An API signing secret was likewise hardcoded in the vendor’s Android app; the literal value is in the published writeup and is not reproduced here, because it offers a defender nothing.

    Finally, the researcher’s own framing deserves to be carried rather than dropped, because it is the honest one and because coverage tends to strip it. He states plainly that the work is “a point-in-time account of the platform as I found it during the research and disclosure period, not as a description of its current security posture.” Between June and now, Unitree may have shipped firmware that closes some or all of these paths. Nothing published says so. The gap between “may have been fixed” and “was fixed in version X” is the entire distance between a security program and hoping.

    What to do

    There is no fixed firmware version to give, because none has been published. If you operate G1 EDU units, ask Unitree directly for the release that remediates CVE-2026-76639 and CVE-2026-76640 and for the models and branches in scope. Until that answer exists, treat every unit as affected.

    Put the robots on an isolated segment with nothing else of value on it, and do not treat them as trusted hosts. The first chain reaches the device from an adjacent network position, and TCP port 9991 is the named entry point — it should not be reachable from any general-purpose user network. Both records score the attack vector as adjacent rather than network, so segmentation is a real control here, not a token one.

    Treat physical Bluetooth range as part of the perimeter. The second chain needs proximity and no credentials, so the control surface is who can get close to the robot and when it is powered on. Powering units down when not in use reduces exposure and costs nothing.

    Rotate any credential a robot has held or could have observed. If your units were provisioned before Unitree’s cloud ownership check went in, treat the AES key protecting the BLE setup channel as having been obtainable by anyone who asked.

    Sourcing note

    Checked: the NVD records for CVE-2026-76639 and CVE-2026-76640, which supplied the publication timestamps, the CNA identity, the description text, and every CVSS vector and score quoted here; VulnCheck’s advisories for both identifiers, which supplied the titles and the “G1 EDU <= 1.5.2” affected-version string and confirmed no patched version is named; the researcher’s writeup at boschko.ca, which supplied the disclosure timeline, tested firmware versions, bounty amount, and vendor-response quotations; and the public GitHub repository holding the proof-of-concept toolkit, which confirms the artifacts are inspectable.

    Single-source limitations, stated plainly: this is one researcher’s work on four robots of one model. The vulnerability details have been validated by the vendor per the researcher’s timeline and accepted by a CNA, but there is no independent reproduction and no second research team. The deployed population is unknown and is not estimated above.

    Could not reach: any Unitree security advisory. Searches surfaced no vendor bulletin, no firmware release note referencing either CVE, and no Unitree PSIRT page. That is an absence, not a claim that Unitree has said nothing privately to customers.

    Unresolved: which firmware release, if any, fixes the on-device defects, and whether the cloud-side ownership check applies to previously provisioned units or only to new bindings. Neither CVE appears in the KEV catalog as of publication, and no party has reported exploitation in the wild.

  • cPanel says a parked-domain flaw gives any account root on the whole server, and the CVE it names has no record

    cPanel says a parked-domain flaw gives any account root on the whole server, and the CVE it names has no record

    cPanel’s August 27 advisory says any account holder who can add a parked domain can execute code as root on the whole server — and three days later the CVE identifier in the advisory’s own title has no record at the CVE Program or NVD.

    What happened

    On Thursday, August 27, 2026, cPanel published a support advisory titled “Security: CVE-2026-65643 Vulnerability in cPanel’s Domain Parking Functionality.” It describes the problem in one sentence: “An authenticated cPanel account holder who is able to add parked or addon domains can create arbitrary files on the server.”

    The impact statement is the second sentence, and it is not hedged: “Successful exploitation leads to code execution as the root user, giving an attacker full control of the server and every account, website, and database on it.”

    Fixed builds are named across five branches: 11.110.0.141 or later, 11.134.0.53 or later, 11.136.0.37 or later, 11.138.0.2 or later, and 11.138.1.7 or later for WP Squared. All supported versions below those builds are affected.

    That is the entire advisory. It carries no CVSS score. It carries no severity rating of cPanel’s own. It names no researcher and no credit. It gives no technical detail beyond the two sentences quoted above — no affected component path, no explanation of how file creation becomes root code execution, no proof-of-concept constraints. And it makes no statement in either direction about whether the flaw has been exploited.

    As of Sunday, August 30, 2026, three days after that advisory, CVE-2026-65643 has no published record anywhere in the vulnerability record system. A query to NVD’s API for the identifier returns an empty result set. A query to the CVE Program’s own services API for the same identifier returns HTTP 404. As a control on that second result, the same API returns a fully populated record for CVE-2026-76581, published on August 28, so the 404 reflects the absence of a record rather than a failed lookup.

    Why it matters

    Shared hosting has exactly one security boundary that matters, and this is a bug in it. The premise of the product is that hundreds or thousands of unrelated customers can be packed onto one machine because the control panel keeps each of them inside their own account. A flaw that turns an ordinary account into root does not primarily harm the account holder who exploits it. It harms every other customer on that server — their files, their databases, their mail, their customers’ data — none of whom have any relationship with the attacker, any visibility into the machine, or any way to find out.

    The privilege the attacker needs is the cheapest thing on the menu. Adding a parked or addon domain is not an administrative capability; it is a standard feature of entry-level hosting plans, the kind of thing a customer does to point a second domain at the same site. So the cost of entry is the price of a hosting account, and the attacker can buy that account from the same provider whose server they intend to take. There is no need to compromise anyone first. This is the structural reason that local privilege escalation in a multi-tenant control panel deserves to be read as remote code execution with a small purchase order attached, and why “authenticated” in the advisory’s first sentence is doing much less work than it looks like it is doing.

    Which brings up the missing record, and it is worth being fair about what that does and does not mean. A gap of days between a vendor’s own advisory and the appearance of a CVE record is ordinary. Identifiers get reserved before they get published, CNAs publish on their own schedules, and cPanel has done nothing improper by shipping a fix and telling customers about it before the paperwork caught up. The vendor got the patch out and said what it was for. That is the important part and cPanel did it.

    The consequence is still real, and it falls on the operator rather than the vendor. Most organizations do not learn about vulnerabilities by reading vendor knowledge bases. They learn about them from a feed — a scanner, an SBOM tool, a vulnerability management platform, a ticket that opens itself when a CVE matching an inventoried product crosses a threshold. Every one of those systems is keyed on the CVE record. For three days there has been nothing for them to key on. A hosting provider whose patch process is driven by CVE ingestion has not seen this, will not see it until the record publishes, and has no way to notice its absence, because the thing that is missing is precisely the thing that would have told them.

    The same gap runs through prioritization. CISA’s BOD 26-04, in force since June 10, 2026, derives federal remediation deadlines from four binary variables: internet exposure, KEV listing, exploit automation, and total versus partial technical impact. Two of those — KEV listing, and any scoring input a triage process layers on top — require a record to exist. A vulnerability with no CVE record cannot be listed in KEV and has no published score to feed a risk model. None of that changes what the flaw does to a server. It changes only whether the machinery organizations have built to notice such things will notice it. The directive binds federal agencies, but the prioritization pattern it formalizes is the one most private-sector patching programs already run on, and it has the same blind spot.

    The absence of a severity rating in the advisory compounds this in a smaller way. An operator deciding between an emergency maintenance window tonight and the next scheduled one has to weigh this against everything else in the queue, and the only signal cPanel provides is the phrase “code execution as the root user.” That phrase is a strong signal and it should be treated as one. But it is prose, and queues are sorted by numbers. cPanel has published severity ratings on advisories before; there is none here, and no explanation of why.

    What is genuinely unknown, and worth stating rather than glossing, is whether anyone has used this. The advisory does not say the flaw has been exploited, and it does not say it has not. Silence is not a denial. Given that a patch shipped across five branches simultaneously, and given that the advisory gives no credit to an outside researcher, the two most common explanations — an internal audit finding, or a report from a hosting partner who noticed something — point in opposite directions on urgency, and nothing public distinguishes them.

    What to do

    Check the installed build with /usr/local/cpanel/cpanel -V and compare it against the fixed build for your branch, not against a single version number. The five thresholds are 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, and 11.138.1.7 for WP Squared. Because cPanel servers track different release tiers, the correct target depends on which tier the machine is on, and a build number that looks lower than another server’s may still be patched.

    Confirm that automatic updates are enabled and have actually completed, rather than assuming they have. Check that upcp has run since August 27 and that it finished, then re-check the version rather than trusting the schedule.

    The advisory offers no mitigation and no workaround. Its own wording implies that an account without the ability to add parked or addon domains cannot reach the flaw, so restricting that feature at the package level would narrow exposure — but cPanel does not present this as a mitigation, has not validated it as one, and it should be treated as an inference from the vendor’s sentence rather than as vendor guidance. Updating is the only remediation cPanel names.

    For retrospective review on a multi-tenant server, the artifact to look for is file creation outside an account’s own home directory attributed to that account’s activity, and any new or modified files in root-owned paths that do not correspond to a package operation. Reconcile recent parked and addon domain additions against the customers who should have made them.

    Sourcing note

    Checked: cPanel’s own support advisory for CVE-2026-65643, dated August 27, 2026, which is the source of every quoted sentence and every fixed build listed above; NVD’s API by CVE ID, which returned no record; and the CVE Program’s CVE Services API for the same identifier, which returned HTTP 404. The control lookup against CVE-2026-76581 on the same API returned a published record, confirming the API was functioning at the time of the check.

    Not established: whether the flaw has been exploited, who reported it, what the underlying component is, and what severity cPanel assigns it. None of these appear in the advisory, and there is no second primary source — no CVE record, no NVD entry, no researcher writeup — to check them against. The vulnerability’s real severity is inferred here from cPanel’s own impact sentence, which is the strongest statement available and the only one.

    Unresolved: when CVE-2026-65643 will publish, and which CNA holds it. The identifier’s numeric range does not reliably indicate the assigner, and with no record present there is nothing to read it from. This page will not be updated silently if that changes; a new development gets its own note.

  • PaperCut needed a second emergency patch, and the record spent the day contradicting its own authors

    PaperCut needed a second emergency patch, and the record spent the day contradicting its own authors

    The most consequential item on the site today is that PaperCut’s zero-day now needs a second emergency patch, because researchers bypassed the first one. Anyone who patched on August 27 is not protected. The flaw now has two numbers — CVE-2026-81578, an unauthenticated access-control bypass in the web management interface, and CVE-2026-82078, unsafe dynamic class loading — and they chain. Huntress has found evidence of exploitation in two customer environments. That outranks the bigger-sounding story of the day. Manchester Airports Group confirmed that roughly 8.7 million customers’ details were taken from a third-party-hosted database, and the number is real, but nobody reading this can act on it tonight. An internet-facing print server running a build that a public bypass defeats is a task, not a headline.

    The day had a thread, and it is a sharper version of yesterday’s: the record did not merely lag the risk, it contradicted its own authors. CISA’s machine-readable assessment of both PaperCut CVEs, timestamped August 28, records exploitation as “none” — written a day after PaperCut told its own customers they were under attack. Wordfence’s advisory for a CVSS 9.8 unauthenticated remote code execution flaw in the Avada theme conditions exploitation on site content an administrator has to have created, while the researchers who found it told reporters that any site with the theme installed is exploitable. GiveWP shipped the fix for an unauthenticated CVSS 10.0 remote code execution chain and called it “additional hardening” in its changelog. TranslatePress’s fixing release does not appear in the vendor changelog at all. In each case the authoritative document disagrees with something the same organization said out loud.

    Order of business after PaperCut. Gitea’s three-day federal deadline for CVE-2026-60004 expired on August 28 with Shadowserver counting 8,393 vulnerable instances the day before; the fix shipped on July 27, so this is a patch nobody applied rather than a patch nobody had. Then ServiceNow, which published four of its own CVEs on August 27 and scored three of them at a flat CVSS v4.0 10.0 with byte-identical vectors, all unauthenticated, all citing one knowledge base article. Then the WordPress set — GiveWP on more than 100,000 sites, Avada, and TranslatePress on more than 400,000, where what leaked was administrator password-reset links readable by any visitor. Cosmos EVM operators should read the post-mortem: Cosmos Labs confirmed on August 13 that every EVM chain was exposed and began notifying operators on August 21, after exploitation had begun. Below that, VulnCheck’s two new Zbtlink router implants — one a service that runs commands as root on an unauthenticated UDP port, though VulnCheck’s own internet-facing count is 203 devices — and the deleted Log4j deserialization report that Apache says is a known non-finding while the public exploit labs stay up.

    Three disclosures moved today without handing anyone a task: ATF confirmed a breach of a standalone system that the Justice Department has already designated a major incident, Berlin confirmed it is being extorted and rejected the ultimatum eleven days after announcing the compromise without mentioning it, and Hasbro’s employee notification letters surfaced in a state attorney general filing.

    Still open. CISA’s assessment of the PaperCut chain still records exploitation as “none” — the field that drives federal prioritization, on the one item confirmed under attack. ATF has not said what was on the standalone system, and no data has appeared. Zbtlink disputes VulnCheck’s characterization, and no CVE has been assigned to either implant. Hasbro’s own public account of the March breach has not moved since April 4, while the letters go out now. And the ICO has asked MAG not to name the group behind the theft, so the attribution most readers want is the one thing that will not be published.

  • Wordfence’s Avada advisory says exploitation needs particular site content; its researchers told reporters every Avada install is exploitable

    Wordfence’s Avada advisory says exploitation needs particular site content; its researchers told reporters every Avada install is exploitable

    The CVE record for a CVSS 9.8 unauthenticated remote code execution flaw in the Avada theme conditions exploitation on site content an administrator has to have created; the researchers who found it told reporters that any site with the theme installed is exploitable.

    What happened

    CVE-2026-18431 entered the National Vulnerability Database at 7:16 a.m. UTC on August 26, 2026, three days ago, carrying a CVSS 3.1 base score of 9.8 assigned by Wordfence, which is the CNA for this record. The record was revised once, on August 27, 2026. ThemeFusion shipped the fixes on August 26, 2026: Avada 7.16.1 and Fusion Builder 3.16.1. According to BleepingComputer, ThemeFusion acknowledged the report on August 10, 2026.

    The flaw itself is an arbitrary file write that becomes remote code execution. The record’s description, which Wordfence authored and NVD republishes, reads in full:

    “The Avada theme for WordPress is vulnerable to Arbitrary File Write in all versions up to, and including, 7.16 when the Fusion Builder plugin is installed and active in versions up to, and including, 3.16. This is due to a chain of authorization and input validation weaknesses across the two components that makes it possible for unauthenticated attackers to write attacker-controlled files to the server. This can be used to create and execute arbitrary PHP files, resulting in remote code execution and complete site compromise. Successful exploitation requires both Avada and Fusion Builder to be installed and active, as well as certain administrator-authored content to be present.”

    Read the last sentence again, because it is the one doing the work. The advisory states two preconditions. Both components active is the easy one — Fusion Builder ships as a required companion to the Avada theme, so in practice that condition is satisfied nearly everywhere the theme runs. The second condition is not easy at all: certain administrator-authored content must already exist on the site. The record does not say what that content is.

    Coverage of the flaw says something different. BleepingComputer, reporting on August 26, 2026, quotes the position that “Any site that has the Avada theme installed is going to be exploitable,” reasoning from the fact that Fusion Builder installs alongside the theme. That sentence accounts for the first precondition and passes over the second entirely. The advisory says exploitation requires particular content to be present. The public characterization says installation is sufficient. Those cannot both be true, and the difference is not academic: it is the difference between “every Avada site is a live target” and “an unknown subset of Avada sites is a live target, and nobody outside Wordfence currently knows which.”

    One more detail from the record: NVD lists CVE-2026-18431 with a vulnerability status of Deferred. That is NVD’s marker for records it does not plan to enrich further with its own analysis — no NVD-assigned CVSS vector, no independently built list of affected configurations. On a three-day-old unauthenticated remote code execution flaw scored 9.8, it means the Wordfence description quoted above is not merely the first word on scope. For the foreseeable future it is the only word in the authoritative record.

    The flaw is not in the CISA Known Exploited Vulnerabilities catalog. The NVD record carries no cisaExploitAdd, cisaActionDue, cisaVulnerabilityName, or cisaRequiredAction fields, so there is no federal remediation deadline attached to it. No vendor or research firm has reported exploitation in the wild.

    Why it matters

    Avada is not a niche theme. ThemeFusion advertises more than a million sales, and the theme has been a fixture of the commercial WordPress market for over a decade. A precondition sentence in a CVE description is therefore not a footnote — it is the input to a triage decision being made this weekend by people who run hundreds or thousands of client sites and have to decide what to do first.

    Those two readings produce opposite work plans. If installation is sufficient, the correct move is to treat every Avada site as compromised-until-proven-otherwise and patch on an emergency footing tonight. If particular administrator-authored content is required, the correct move is still to patch, but the panic is misplaced and the scarce hours are better spent on hunting: figuring out which sites carry the triggering content and checking those for files that should not exist. An operator who picks the wrong reading either burns a weekend on sites that were never reachable, or skips a hunt on the ones that were.

    What makes this worth writing up rather than shrugging at is that the ambiguity is unnecessary. Wordfence knows what the triggering content is — it wrote the sentence. Withholding the specifics is a defensible choice while patch adoption is low; publishing an exact exploitation recipe for a 9.8 on a million-install theme days after the fix ships would be reckless, and there is a real argument for vagueness here. But vagueness in the advisory and confidence in the press quote are a bad combination. If the precondition is real and narrow, the public statement overstates the blast radius and will burn other people’s time. If the precondition is real but so commonly satisfied as to be no barrier, the advisory understates the risk and will cause some operators to deprioritize. Either way, one of the two statements is misleading somebody, and the party best positioned to reconcile them is the party that produced both.

    The Deferred status compounds it. Under normal enrichment, NVD analysts build their own affected-configuration list, which frequently surfaces exactly this kind of scope question — the analyst has to decide what to encode, and encoding forces precision. A deferred record gets none of that. The CNA’s prose stands unchallenged, ambiguity and all, and every downstream scanner, dependency checker, and managed-service dashboard inherits it verbatim. This is a structural consequence of how NVD has been triaging its backlog, and it is going to keep producing records where the only description of scope is the one the finder chose to write.

    There is also a disclosure-provenance question worth flagging. BleepingComputer reports that Wordfence found this flaw with an internal AI system it calls the Argus framework. If accurate, that is notable in itself — an AI-discovered chain of authorization and input-validation weaknesses spanning two components, at CVSS 9.8, on a million-install theme. It also raises a question this page cannot answer: whether an automatically derived precondition statement is as reliable as one written by a human who reproduced the exploit end to end. We flag it as a question, not a finding.

    What to do

    • Update Avada to 7.16.1 and Fusion Builder to 3.16.1. Both. The chain crosses the two components, and patching one is not a fix. Do this regardless of which reading of the preconditions you believe.
    • Do not wait for clarification on the precondition to patch. The disagreement affects hunting priority, not whether to update.
    • Hunt on the assumption that the flaw was reachable. Look for PHP files written into upload and theme directories since August 10, 2026, the date the vendor is reported to have been notified — not since August 26. Compare file modification times against your deployment history.
    • Check for unexpected administrator accounts and for scheduled tasks or must-use plugins added in the same window.
    • If you manage sites at scale, inventory by both components rather than by the theme alone, and record the Fusion Builder version. Version pairing is what determines exposure in the record as written.
    • There is no federal deadline here. This is not a KEV entry, and nothing obliges a federal agency to act on a schedule. Prioritize it on severity and install base.

    Sourcing note

    The CVE description, CVSS score and source, publication and modification timestamps, and vulnerability status are quoted from the NVD API record for CVE-2026-18431, retrieved August 29, 2026: published 2026-08-26T07:16:45.500, last modified 2026-08-27T17:17:29.533, vulnStatus of Deferred, CVSS 3.1 base 9.8 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, source [email protected]. The identical description text appears on WPScan’s entry for the same CVE. The record contains no CISA KEV fields; cisa.gov returns 403 to automated fetching, so KEV status was checked through NVD’s republication of CISA’s own fields rather than against the catalog page directly.

    We could not retrieve Wordfence’s own advisory page, which returned empty content on repeated attempts, so the description above is sourced through NVD and WPScan rather than from the publisher directly. The quoted characterization that “Any site that has the Avada theme installed is going to be exploitable,” the report that ThemeFusion acknowledged the issue on August 10, 2026, the more-than-one-million sales figure, and the attribution of discovery to an internal AI framework called Argus all come from BleepingComputer’s August 26, 2026 report. Those are secondary and we have not confirmed them against Wordfence or ThemeFusion. We did not reach ThemeFusion for comment and found no vendor statement addressing the precondition question.

    Unresolved: what the “certain administrator-authored content” consists of, what fraction of Avada installations carry it, whether Wordfence considers the press characterization or the advisory text the accurate one, and whether NVD will lift the Deferred status and enrich the record.

  • CISA’s own assessment of both PaperCut CVEs says exploitation “none,” written a day after PaperCut said customers were under attack

    CISA’s own assessment of both PaperCut CVEs says exploitation “none,” written a day after PaperCut said customers were under attack

    CISA’s own machine-readable assessments of both PaperCut CVEs, timestamped August 28, 2026, record the exploitation status as “none” — a day after PaperCut told customers they were under attack, and hours before the vendor shipped its second emergency patch.

    What happened

    NVD published CVE-2026-81578 and CVE-2026-82078 on August 28, 2026. Both records carry an SSVC block attributed to source UUID 134c704f-9b21-4f2e-91b3-4a467353bcc0, role “CISA Coordinator,” version 2.0.3 — NIST republishing CISA’s own decision-point values, the same relay that carries the KEV fields.

    For CVE-2026-81578, the improper access control flaw in the PaperCut web management interface: SSVC timestamp 2026-08-28T00:12:00 a.m.+00:00, Exploitation none, Automatable yes, Technical Impact partial. For CVE-2026-82078, the unsafe dynamic class-loading flaw: SSVC timestamp 2026-08-28T15:35:13.512853Z, Exploitation none, Automatable no, Technical Impact total.

    Set those timestamps against the public record of the same week. On August 27, 2026 PaperCut published an urgent bulletin telling customers they were being attacked through its NG and MF print servers. Huntress published its analysis on August 28, updated 2:45 p.m. Eastern, stating: “Huntress has found evidence of exploitation in two customer environments,” the first on August 26, the second on August 27. Huntress describes PaperCut’s August 27 advisory as saying attackers are actively exploiting a pre-authentication remote code execution flaw “with confirmed customer incidents.” PaperCut then shipped Emergency Patch Release 2 on August 28 at approximately 2:45 p.m. Eastern — 6:45 p.m. UTC.

    The CVE-2026-82078 assessment is stamped 3:35 p.m. UTC on August 28. That is roughly a day after the vendor’s own confirmation of attacks, and roughly three hours before the vendor shipped its second emergency patch. It reads “Exploitation: none.”

    Neither CVE appears in the Known Exploited Vulnerabilities catalog. Neither record carries a cisaExploitAdd, a cisaActionDue, or any other KEV field. As of this writing there is no federal deadline attached to either.

    One further detail: CVE-2026-81578 was last modified on August 29, 2026 at 04:18 UTC. The record was touched today. The exploitation value still reads “none.”

    We covered the CVE pair and the patch bypass separately, and that story stands: the two flaws chain into unauthenticated remote code execution, and anyone who applied only the August 27 patch is not protected. This story is about a different field — not the severity scores, which are judgments, but the exploitation flag, which is a claim about the world.

    Why it matters

    SSVC decision points are not severity opinions. “Exploitation” is meant to answer a factual question: is there evidence this is being used against real systems? The values are defined so that “none” means no evidence of active exploitation and no public proof of concept. That is a statement about the state of the world, and it is checkable. Here the vendor had said the opposite in public a day earlier, and a security firm had published host-level detail.

    The difference between this and a disputed CVSS score matters. Reasonable people argue about whether a scope change applies or whether an impact is high or low, and two analysts can score the same bug differently without either being wrong. There is no comparable room here. Either exploitation had been observed by 3:35 p.m. UTC on August 28 or it had not, and the vendor and at least one incident response firm had already said it had.

    The most likely explanation is mundane and is worth stating rather than implying something worse: an SSVC assessment is generated at a moment, from the information in front of the analyst, on a CVE record that was hours old and still in Received status. The vendor bulletin that started this named no CVE at all — there was nothing to attach exploitation evidence to until the identifiers existed on August 28. Nothing about the pipeline forces a re-look when the world changes underneath a published value. That is the problem. It is not that someone got it wrong once; it is that the field is written as a snapshot and read as a fact, and nothing in between marks the difference.

    The reason this is worth a page rather than a footnote is what these fields feed. BOD 26-04 derives federal remediation deadlines from four binary variables: internet exposure, KEV listing, exploit automation, and whether technical impact is total or partial. Two of those names — automation and total-versus-partial technical impact — are also SSVC decision point names, and the third, KEV listing, is the catalog that exploitation evidence ordinarily drives.

    We are not going to tell you which combination earns which deadline, and neither can anyone else with confidence. CISA publishes that mapping as Table 1 in Appendix A of BOD 26-04, as PNG images with no alt text, and the vendors who have transcribed it by eye disagree with one another about which combinations get three days. That is a standing problem we have written about separately. What can be said without the table is narrower and still enough: the inputs to a federally mandated deadline calculation are being published in machine-readable form, at least one of them is a factual claim, and on this pair of CVEs that claim was contradicted by the vendor before it was written.

    There is a practical consequence for anyone outside the federal space too. Plenty of private-sector vulnerability programs have adopted SSVC because it is better than sorting by CVSS, and plenty of them ingest the decision points from NVD because that is where they are available in bulk. A queue built that way, on August 28, would have placed both PaperCut CVEs below anything flagged as exploited — while the vendor was shipping its second emergency patch in two days because researchers had bypassed the first one.

    The narrower fix is obvious and is a question for CISA rather than for readers: an exploitation value with no expiry and no re-evaluation trigger is a fact-shaped object that decays into a historical note without changing its appearance. The broader point for everyone else is the one we keep arriving at from different directions. The authoritative record is authoritative about when it was written, not about now, and the gap between those two things is where the operational risk lives.

    What to do

    Patch PaperCut. Emergency Patch Release 2, on August 28, sets the fix boundaries at 24.1.10, 25.0.13 and 26.0.5. If you applied the August 27 builds — 26.0.4 or 25.0.12 — you are not covered; watchTowr found multiple bypasses of that first patch. Version 24, which had no fix when the original bulletin appeared, now has one.

    Do not use the SSVC exploitation value in these two records as a triage input. Treat PaperCut NG/MF as actively exploited on the vendor’s own statement of August 27.

    More generally: if your vulnerability management tooling consumes SSVC decision points from NVD, check whether it treats Exploitation as a live field or as a timestamped observation, and whether anything in your pipeline re-evaluates it when a vendor publishes an exploitation advisory. If the answer is that a value written once stands until someone edits it upstream, you have inherited this problem. The same applies to any process keyed on KEV membership alone: neither of these CVEs is in KEV, and both are being exploited.

    Sourcing note

    Checked: NVD API records for CVE-2026-81578 and CVE-2026-82078, retrieved August 29, 2026. All SSVC values, source UUIDs, roles, versions and timestamps quoted above come from those records — NIST republishing CISA’s decision points, a government primary source at one remove. Publication and last-modified timestamps are from the same records.

    cisa.gov returns 403 to automated fetching, so we did not read CISA’s own pages. We routed around that by taking the CISA-sourced SSVC block from NVD’s republication, the same method this publication uses for KEV dates. We could not check whether CISA has published an alert of its own on PaperCut, or whether the SSVC values have been revised at the source since NVD last synced.

    Exploitation evidence: Huntress’s own writeup, published and updated August 28, 2026, quoted verbatim above. PaperCut’s August 27 bulletin language is taken from Huntress’s account of it and from reporting; we did not retrieve PaperCut’s bulletin directly, and the knowledge base URL we tried returned 404. The patch-bypass finding is attributed to watchTowr via Rapid7 and BleepingComputer, single-sourced to watchTowr’s research.

    Unresolved: why the assessments read “none” is not established — we are describing the record, not the reasoning behind it, and we did not put the question to CISA. Whether either CVE has since been added to KEV is not established beyond the NVD records as retrieved. Huntress’s telemetry describes two customer environments; that is the real scale of independently documented exploitation, and it is small. PaperCut has said the attacks “appear limited and targeted.”

  • GiveWP patched an unauthenticated CVSS 10.0 remote code execution flaw and called it additional hardening

    GiveWP patched an unauthenticated CVSS 10.0 remote code execution flaw and called it additional hardening

    GiveWP, a donation plugin installed on more than 100,000 WordPress sites, released version 4.16.7.2 on August 27, 2026. The plugin’s own changelog describes the release in one line: “Security: Added additional hardening for serialized data handling in the donation flow.”

    The following day, Patchstack published the advisory. The thing being hardened is CVE-2026-82222, an unauthenticated PHP object injection chain that ends in operating-system command execution, scored 10.0 on CVSS v3.1. On a default installation of an affected version, the only prerequisites are a published donation form and an active payment gateway.

    What happened

    NVD published the record on August 28 at 12:16 p.m. UTC. Its description, verbatim: “Deserialization of Untrusted Data vulnerability in Liquid Web / StellarWP GiveWP allows Object Injection. This issue affects GiveWP: from n/a through 4.16.7.1.” The weakness is CWE-502. The fixed version is 4.16.7.2.

    The 10.0 is worth reading precisely, because of where it comes from. NVD carries no score of its own here; the record’s vulnStatus is Deferred, meaning NVD is not performing its own analysis. The only score attached is a secondary one submitted by [email protected], the CNA: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network attack vector, low complexity, no privileges, no user interaction, scope changed, high impact across confidentiality, integrity, and availability. If you query NVD for a government-analyzed severity on this CVE, you will get nothing back, and that absence is a property of the current NVD backlog rather than a judgment about the flaw.

    The chain Patchstack documents has three parts, and it is the kind of bug that only exists because a safety measure was applied in one place and not the next.

    First, GiveWP’s safeUnserialize() helper calls PHP’s unserialize() with allowed_classes => false. That is the recommended defensive setting, and it works as documented: rather than instantiating an attacker’s class, PHP produces a __PHP_Incomplete_Class placeholder. The catch is that the placeholder is not inert. It retains the original class name and properties, and when the value is serialized again on its way into storage, it re-emits them. The dangerous string survives the safe read.

    Second, the donation flow carries the payload into the database. Patchstack’s write-up describes planting a serialized gadget in an account’s last_name user meta, then submitting a donation without the give_last parameter so that the stored value is pulled through the unsafe helper and written into the wp_give_sessions table with the payload intact.

    Third, the gadget chain is already on disk. GiveWP bundles the TCPDF library and its own Give\TestData classes; ProviderForwarder::__call() passes attacker-controlled callables to call_user_func_array(), which reaches system(). Loading any front-end page deserializes the poisoned session and fires the chain, executing commands as the web server user.

    The entry point is the part that removes the last obstacle. Patchstack describes an unauthenticated give_action=user_register action that creates a WordPress account even on sites where user registration is switched off. So the five steps are: register through the plugin’s own action, plant the gadget in the profile field, submit a donation that poisons the session table, load a page, and get a shell. Patchstack states that on versions 4.16.5.1 and below the requirements are met by a default install, because GiveWP ships manual and offline gateways enabled.

    The vulnerability was reported by Udin Chan on July 28, 2026 and disclosed publicly on August 28. Patchstack’s advisory carries no claim of observed exploitation; its language is forward-looking, calling the flaw “highly dangerous and expected to become exploited” and noting that “vulnerabilities like this one are used in mass-exploit campaigns.” That is a prediction, not an observation, and we have found no report of exploitation in the wild.

    To the vendor’s credit, the fix is not a single-point patch. Patchstack describes GiveWP breaking the chain in several places at once: rejecting serialized data at write time, enforcing allowed_classes => false at multiple read sinks, validating gadget providers before they are invoked, and running a migration that sanitizes payloads already sitting in the database. That last item matters more than it sounds. It means the vendor assumed some sites were already poisoned.

    Why it matters

    Start with the changelog, because the gap between the release note and the advisory is the operational problem here.

    “Added additional hardening for serialized data handling in the donation flow” is not false. Every word of it is accurate. It is also the sentence a site owner reads inside their WordPress dashboard when deciding whether to click update today or next month, and nothing in it distinguishes this release from routine maintenance. There is no severity, no CVE, no indication that an unauthenticated stranger can run commands on the server. The advisory containing that information landed on a security vendor’s website a day later, where the site owner is not looking.

    This is the WordPress patch-gap mechanism in miniature, and it is why plugin flaws convert to mass exploitation so reliably. The population is enormous and mostly unmanaged: 100,000 active installations of a donation plugin means charities, churches, schools, volunteer-run nonprofits, and small agencies, many with auto-updates off because a plugin update broke something once. The defenders read release notes; the attackers read Patchstack and the diff. A patch is a disclosure, and an understated changelog does not slow an attacker down by a single minute—it only slows down the person who has to decide whether to interrupt their weekend. Understatement in a release note transfers risk from the vendor’s support queue to the customer’s server.

    The technical lesson is narrower and more useful. allowed_classes => false is the canonical safe-deserialization advice for PHP, and this chain runs straight through it. The reason is that the flag makes the read safe without making the value safe: __PHP_Incomplete_Class is a faithful record of a hostile object, and any code path that re-serializes it hands the payload forward to a sink that may not be so careful. If your codebase reads with allowed_classes => false and then writes the result back to a database, a cache, or a session store, you have a laundering step, not a defense. The durable fix is to refuse serialized strings at the boundary rather than to neutralize them on the way in—which is precisely what GiveWP did on the second pass.

    Two of today’s stories are CWE-502 — this one and the disputed Log4j deserialization report. That is not a coincidence so much as a reminder: object deserialization keeps producing critical bugs because it is a feature that turns data into behavior, and every mitigation built on top of it—allowlists, class filters, safe flags—is a partial one.

    What to do

    Update GiveWP to 4.16.7.2 or later. Anything at or below 4.16.7.1 is affected, and version 4.16.7.1 itself is only three days older than the fix—it shipped on August 24 and addressed an unrelated PayPal validation issue, so a site patched last week is still exposed.

    Because the vendor shipped a sanitizing migration, treat the update as remediation and not merely as prevention: it exists because payloads may already be stored. On any site running an affected version that has been reachable from the internet, do not stop at the update. Check wp_give_sessions for session data containing serialized object markers such as O: or __PHP_Incomplete_Class. Review the users table for accounts created without your knowledge, particularly with registration disabled, and inspect the last_name user meta on any account you do not recognize. Look for web-server-user processes, new or modified PHP files under wp-content, and outbound connections from the web host. Post-exploitation as the web server user is the ordinary outcome of this class of bug, and an update does not remove a shell.

    If you run many WordPress sites for other people, this is a case for reading the vulnerability feed rather than the changelog. The information you need to prioritize this release was not in the release.

    Sourcing note

    Primary sources: the NVD record for CVE-2026-82222, fetched from the NIST API, for the description, CWE, affected range, CVSS vector and score, the score’s Secondary provenance from [email protected], and the Deferred analysis status; and the GiveWP plugin listing on WordPress.org for the current version, the 100,000+ active-installation figure, and the 4.16.7.2 changelog line quoted verbatim, dated August 27, 2026.

    Technical detail of the exploit chain—the safeUnserialize() behavior, the wp_give_sessions poisoning step, the TCPDF and Give\TestData gadget path, the unauthenticated give_action=user_register entry point, the 4.16.5.1-and-below default-install claim, the July 28 report date, and the multi-point fix—comes from Patchstack’s own advisory and accompanying write-up. This is single-source vendor research: Patchstack is the CNA that assigned the CVE, the credited researcher reported through its program, and we have not independently reproduced the chain.

    The NVD record contains no cisaExploitAdd or cisaActionDue field; this CVE is not in the KEV catalog and carries no federal deadline. We found no report of exploitation in the wild. Patchstack’s “expected to become exploited” is a forecast by the disclosing vendor and is presented as such.

    Unresolved: how many of the 100,000-plus installations run an affected version, a figure nobody publishes; and whether GiveWP will amend its changelog entry to name the CVE.

  • Gitea’s federal deadline expired with 8,393 servers still vulnerable, and the exploitation record is one CPU alert

    Gitea’s federal deadline expired with 8,393 servers still vulnerable, and the exploitation record is one CPU alert

    CISA gave federal agencies three days to fix a critical Gitea remote code execution flaw. The clock ran out on August 28; the day before, Shadowserver counted 8,393 vulnerable instances — and the entire public record of exploitation is one developer’s blog post about a high CPU alert.

    What happened

    CVE-2026-60004 is a remote code execution flaw in Gitea, the self-hosted Git service. NVD published the record on August 26, 2026, last modified it on August 27, and lists it as Analyzed. The description, verbatim: “Gitea before 1.27.1 allows remote code execution via the diffpatch API through Git hook installation.” MITRE scored it CVSS v3.1 9.8, Critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-94. Affected versions run from 1.17.0 through 1.27.0.

    The federal timeline, from NVD’s republication of CISA’s catalog fields: cisaExploitAdd of August 25, 2026, cisaActionDue of August 28, 2026, catalog name “Gitea Code Injection Vulnerability.” That is a three-day clock under BOD 26-04, and it expired yesterday. CISA’s SSVC decision points on the record read Exploitation: active, Automatable: yes, Technical Impact: total.

    The fix has been available for a month. Gitea 1.27.1 shipped on July 27, 2026, and the project’s security advisory, GHSA-rcr6-4jqh-j84m, went up on July 28, credited to a researcher going by NightRang3r.

    The mechanism is worth spelling out because it explains the exposure. The diffpatch endpoint lets a user apply a patch to a repository through the web interface. Submit the same patch twice and you produce an add/add collision. Git’s three-way merge fallback then checks out the indexed path despite the --cached flag. In a bare clone — which is how Gitea stores repositories — the repository root is $GIT_DIR, so a file written to hooks/post-index-change is not an inert file in a working tree. It is a live hook, and Git executes it during index operations.

    The precondition, in the advisory’s own words: “An attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user.” And then the sentence that turns a privileged bug into a 9.8: “With open registration enabled, the attack can be performed by an unauthenticated visitor after registering a normal account and creating a repository.”

    On August 27, the Shadowserver Foundation’s scanning reported 8,393 IP addresses found vulnerable — one day before the federal deadline, one month after the patch.

    Why it matters

    Start with the exploitation evidence, because it is thinner than the SSVC value suggests and readers deserve to know what “actively exploited” is resting on here.

    The public record we could find amounts to a single incident report, published on the Russian technical blog Habr by a full-stack developer describing his own organization’s self-hosted Gitea server. His hosting provider, HOSTKEY, flagged the machine for sustained CPU usage above 70 percent in breach of terms of service. Working backward, he determined that “an automated scanner was able to register an account, create its own repository, and trigger the exploit chain,” and that the active phase of the attack lasted roughly eleven seconds. On what was actually deployed, he is candid: “I do not have confirmed information regarding the mining pool, wallet, miner family, or specific operator.”

    That is one host, one operator’s account, no vendor telemetry, no second observer, and no named payload family. Coverage has rendered it as cryptocurrency mining malware, which is a reasonable inference from a CPU alert and is not what the reporter says he can confirm. CISA’s catalog entry, as usual, does not cite its evidence, so we cannot tell whether the agency is working from this report or from something it has not published.

    None of which means the listing is wrong. This is a case where the thin exploitation record and the aggressive federal clock are both defensible, and the reason is in the mechanism rather than the telemetry. The advisory shipped with a proof of concept. The attack requires no credential when open registration is on, which is a common configuration for internal and community instances. The whole chain — register, create repo, submit a patch twice — is three HTTP interactions a scanner can automate end to end, which is exactly what the Habr report describes happening in eleven seconds. Automatable: yes is the honest reading. When a bug is that cheap to fire, one confirmed hit and a published PoC really is enough to justify treating it as a live threat, because the gap between one and thousands is a scan cycle.

    The more uncomfortable number is 8,393. A patch that has been public for a month, a CVSS 9.8, a proof of concept in the advisory, a federal deadline — and the day before that deadline, more than eight thousand instances still answering. Self-hosted Git is a specific kind of blind spot. It gets stood up by a platform team or a research group, it does not appear in a SaaS inventory or a software bill of materials, nobody has an agent on it, and it accumulates exactly the assets an attacker wants: source, CI configuration, deploy keys, and the tokens that let a build pipeline reach production. Code execution as the Gitea OS user on that box is not a mining problem. Mining is what you notice.

    There is a second lesson in how the advisory reads. “An attacker with ordinary write access to a repository” is the first sentence, and taken alone it sounds like an insider-risk item — the kind of finding a team defers because everyone with repository access is already trusted. The open-registration clause that removes the precondition entirely is the sentence after. Gitea wrote both, plainly and in order, and the project deserves credit for that. But the sequencing matters when a busy administrator skims, and the 9.8 with PR:N is the score that reflects the second sentence, not the first. If your instance requires an administrator to create accounts, your practical exposure is genuinely lower than 9.8 implies. If it does not, the score is right and the first sentence is misleading you.

    Finally, the deadline itself. It passed on August 28, quietly: there is no published compliance figure and no notification anyone receives. For the many organizations that ingest KEV as a prioritization input, an elapsed due date sorts as lower priority in a lot of tooling, when it should sort as higher.

    What to do

    • Upgrade to Gitea 1.27.1 or later. Everything from 1.17.0 through 1.27.0 is affected — a range covering several years of releases, so “we are on a recent 1.2x” is not an answer.
    • Find the instances first. Look for listeners on 3000/tcp, the Gitea default, and search DNS and reverse proxy configurations for git. hostnames. The instance most likely to be unpatched is the one no inventory knows about.
    • Turn off open registration if you cannot upgrade immediately. In app.ini, set DISABLE_REGISTRATION = true under [service]. This does not fix the bug — any authenticated user with write access to any repository can still trigger it — but it removes the unauthenticated path, which is the one the scanners are using.
    • Check for hooks nobody wrote. On each repository under Gitea’s data directory, inspect the hooks/ directory, and treat post-index-change with particular suspicion — Gitea does not normally place one there. Compare modification times against your patch date.
    • Look at CPU before you look at logs. In the one documented case, the alert came from the hosting provider, not from security tooling. Sustained unexplained load on a Git server is worth an hour of somebody’s time.
    • Rotate what the box held. If you find evidence of execution, deploy keys, CI runner tokens, webhook secrets and any credentials in repository settings should be treated as disclosed. Patching returns the server; it does not return the secrets.
    • FCEB agencies: the due date was August 28. If you are not there, you are past it, and the remediation obligation does not lapse with the date.

    Sourcing note

    Checked: NVD’s API record for CVE-2026-60004, which supplied the description, CVSS v3.1 score and vector, CWE, affected range, and the CISA catalog fields — cisaExploitAdd August 25, 2026, cisaActionDue August 28, 2026, catalog name, and the SSVC decision points — as NIST republishes them verbatim from CISA. cisa.gov blocks automated fetching, so the catalog page itself was not read. Gitea’s security advisory GHSA-rcr6-4jqh-j84m on GitHub supplied the mechanism, the affected and patched versions, the researcher credit and both quoted sentences about write access and open registration.

    Single-sourced and labeled as such: the exploitation account is one developer’s report on Habr, reaching us through Help Net Security and The Hacker News, both of August 26, which agree on its substance. We did not read the Habr post directly. No vendor has published corroborating telemetry, no payload family is named by the reporter, and the characterization of the payload as a cryptocurrency miner is an inference drawn in coverage from a CPU alert, not a confirmed identification.

    The figure of 8,393 vulnerable IP addresses on August 27, 2026 is the Shadowserver Foundation’s, reported by BleepingComputer on August 28; we could not read Shadowserver’s own posting and carry the number as reported. It counts internet-reachable instances that answered a scan — a floor, not a census. Instances behind VPNs or reverse proxies are not in it, and are not therefore safe.

    Unresolved: what evidence CISA relied on for the KEV addition, which is not published; whether any payload family has been identified; and what federal compliance with the August 28 deadline actually looks like, for which no figure exists.

  • ServiceNow scored three of its own AI Platform flaws at a flat 10.0, and a fourth record contradicts itself on authentication

    ServiceNow scored three of its own AI Platform flaws at a flat 10.0, and a fourth record contradicts itself on authentication

    ServiceNow’s PSIRT published four CVEs on August 27 and scored three of them at a flat CVSS v4.0 10.0 with byte-identical vectors — while the fourth record describes an unauthenticated attacker and scores one who needs an account.

    What happened

    NVD published four ServiceNow CVEs on August 27, 2026, three of them at 8:17 p.m. UTC and the fourth a minute later. All four are still in Received status and were last modified on August 29. All four are scored by [email protected] — ServiceNow is the CNA here, and these are the vendor’s own numbers for the vendor’s own product. All four cite a single reference: ServiceNow’s knowledge base article KB3152242.

    Three carry a CVSS v4.0 base score of 10.0, Critical:

    • CVE-2026-18885 — CWE-94, code injection in ServiceNow AI Platform. The description says it lets unauthenticated users “execute arbitrary code in the ServiceNow platform and gain access to, or modify, instance data.”
    • CVE-2026-18886 — CWE-284, improper access control, letting unauthenticated users “create or modify instance data beyond what was intended, resulting in privilege escalation.”
    • CVE-2026-74820 — CWE-89, SQL injection, letting unauthenticated users “execute arbitrary SQL statements against the instance’s underlying database and gain access to, or modify, instance data.”

    All three carry exactly the same vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

    The fourth, CVE-2026-6876, is a sandbox escape in the Now Platform, CWE-94 with CWE-693 and CWE-1284, scored 8.7, High, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

    The affected-version list in the CVE records is long, and it is the useful part. ServiceNow AI Platform is vulnerable below each of: Xanadu Patch 11 Hot Fix 7a; Yokohama Patch 12 Hot Fix 3b and Patch 13 Hot Fix 4; Zurich Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m on the m-branch, Patch 10 Hot Fix 3 on the standard branch, Patch 11 and Patch 12; and Australia Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4 and Patch 5.

    On exploitation, ServiceNow’s position as reported is: “We are not currently aware of malicious exploitation against ServiceNow instances. We recommend customers promptly apply appropriate updates or upgrade to a patched release if they have not already done so.” The company patched its own hosted fleet and directed customers to secure self-hosted instances.

    CISA’s SSVC decision points on all three 10.0 records read Exploitation: none, Automatable: yes, Technical Impact: total. On CVE-2026-6876 they read Exploitation: none, Automatable: no, Technical Impact: total. None of the four carries a cisaExploitAdd or cisaActionDue field, so there is no KEV entry and no federal remediation deadline attached.

    Why it matters

    A CVSS v4.0 10.0 is a harder thing to reach than a CVSS v3.1 9.8, and the difference is worth understanding before deciding what these numbers are telling you.

    Under v3.1, an unauthenticated network attack with total confidentiality, integrity and availability impact caps out at 9.8. Under v4.0, that same shape lands around 9.3. Getting to a flat 10.0 requires all three subsequent system metrics to be High as well — SC:H/SI:H/SA:H. That is a specific, deliberate assertion: compromise of the vulnerable component propagates to systems beyond it. It is not a rounding artifact and it is not the scale’s default ceiling. Somebody chose it, three times.

    The somebody is ServiceNow. As the CNA for its own products, ServiceNow assigns the CVE, writes the description and sets the vector. That is normal and it is how CNA scoring is supposed to work — the vendor knows the architecture. But it means these are self-assessments, and the assessment being made is that a defect in the ServiceNow AI Platform reaches past the ServiceNow AI Platform. For a system that typically holds the CMDB, the ticket history, the HR case records and privileged integration credentials into most of the rest of an estate, that is a claim worth taking at face value, because the vendor is the party best placed to know and it is not a flattering thing to publish about yourself.

    Now notice what the identical vectors do not tell you. Three structurally different defects — a code injection, an access control failure and a SQL injection — produced the same eleven metric values. That is possible, and for a platform where any unauthenticated write is game over it may be exactly right. But it also means the score is describing the platform’s blast radius rather than the individual bug. You cannot use these numbers to rank the three against each other, because they were not built to distinguish them. Anyone whose remediation process sorts by base score is going to find all three tied at the top of the list with nothing to break the tie, and will have to read the descriptions to sequence the work — which is the correct outcome, arrived at by accident.

    Then there is CVE-2026-6876, where two fields of one record disagree. The description says the flaw lets unauthenticated users “execute arbitrary code within the Now Platform.” The vector says PR:L — privileges required, low — which means the attacker holds at least a basic account. Both fields come from the same CNA in the same submission. They cannot both be right.

    This is not a pedantic complaint. Whether an attacker needs an account is the difference between a flaw exposed to the internet and a flaw exposed to your user population, and it changes both the urgency and the compensating control. A tool ingesting the vector will queue this behind the unauthenticated three. A human reading the description will not. The record does not settle it, and in the specific case of a sandbox escape — where the standard precondition is the ability to get code into the sandbox in the first place — PR:L is the more plausible of the two readings. We are flagging the contradiction rather than resolving it, because resolving it is ServiceNow’s job.

    One last piece of context, offered as context and not as a finding. CVE-2026-6876 sits in a low-numbered 2026 block, near CVE-2026-6875 — a separate ServiceNow flaw from July that drew in-the-wild activity which one threat intelligence firm characterized as matching published proof-of-concept code rather than original research. Adjacent CVE numbers usually mean adjacent reservation dates, not related bugs, and we have no evidence connecting the two. What the July episode does establish is the tempo: ServiceNow flaws attract scanning quickly once a PoC exists, and “no exploitation observed” is a statement about today.

    What to do

    • Establish hosted versus self-hosted first. ServiceNow has patched instances it operates. If your instance runs on ServiceNow’s cloud, confirm your patch level rather than assuming, but the work is likely done. If you run it yourself, all of it is yours.
    • Patch to the boundaries in the CVE records, which are more precise than any summary. Xanadu: Patch 11 Hot Fix 7a or later. Yokohama: Patch 12 Hot Fix 3b, or Patch 13 Hot Fix 4. Zurich: Patch 7b Hot Fix 3, Patch 8 Hot Fix 5, Patch 9 Hot Fix 6, Patch 10 Hot Fix 2m or 3 depending on branch, Patch 11, or Patch 12. Australia: Patch 2 Hot Fix 3, Patch 3 Hot Fix 2, Patch 3m, Patch 4, or Patch 5.
    • Mind the m-branches. Zurich Patch 10 and Australia Patch 3 each have separate m-branch and standard-branch fix levels. Getting the branch wrong means installing a build that is not the fix.
    • Do not sequence by score. The three 10.0s are tied by construction. Sequence by exposure: the SQL injection and the code injection give data access and execution; the access-control flaw gives privilege escalation that persists after you close the other two.
    • Treat integration credentials as in scope. If you conclude an instance may have been reached, the credentials it holds for downstream systems are the real loss, and they are not fixed by patching ServiceNow.
    • Watch for a KEV addition. There is none today. Given Automatable: yes on all three 10.0s and a vendor advisory that is now public, a proof of concept is the only missing ingredient.

    Sourcing note

    Checked: NVD API records for CVE-2026-18885, CVE-2026-18886, CVE-2026-74820 and CVE-2026-6876, which supplied the publication timestamps, descriptions, CVSS v4.0 vectors and scores, CWE assignments, the full affected-version list, the CISA SSVC decision points, and the confirmation that none of the four carries a KEV date. The CNA on all four is [email protected].

    Could not reach: ServiceNow’s advisory KB3152242 at support.servicenow.com, the single reference on all four records, which returned only page furniture to us. ServiceNow’s quoted statement on exploitation and its guidance to self-hosted customers are therefore taken from BleepingComputer’s report of August 28, which read the advisory, and are labeled as secondary rather than quoted as primary. The description of CVE-2026-18885 as sitting in the GraphQL Composite Data API and CVE-2026-18886 in configuration image upload comes from other secondary coverage and is not in the NVD records; we have not repeated those specifics above as fact.

    Unresolved: whether CVE-2026-6876 requires authentication, which the record answers two ways; who reported the four flaws, which no source we checked identifies; and whether the July CVE-2026-6875 activity has any bearing here, which we have no evidence for either way.

  • PaperCut’s zero-day is now two chained CVEs, and the first emergency patch does not stop the chain

    PaperCut’s zero-day is now two chained CVEs, and the first emergency patch does not stop the chain

    PaperCut’s unnamed zero-day now has two CVE numbers, a confirmed chain, and a second emergency patch — because researchers bypassed the first one. Anyone who patched on August 27 is not protected.

    What happened

    On August 27, 2026, PaperCut published an urgent security bulletin saying customers were being attacked through a flaw in its NG and MF print management servers. There was no CVE identifier, no description of the vulnerability, and no entry in CISA’s Known Exploited Vulnerabilities catalog. We covered that bulletin, and the out-of-band builds that shipped alongside it, here.

    Two things changed on August 28.

    First, the flaw got numbers. NVD published CVE-2026-82078 at 4:18 p.m. UTC on August 28 and CVE-2026-81578 the same day. Both records are still in Received status and were last modified on August 29.

    CVE-2026-82078 carries a CVSS v4.0 base score of 9.4, Critical, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, and is classed CWE-470. The NVD description reads, verbatim: “An unsafe dynamic class loading vulnerability exists in the database connection utilities of PaperCut MF and PaperCut NG. The application instantiates database driver classes based on configurable driver names without validating against an allowlist of approved drivers.”

    CVE-2026-81578 carries a CVSS v4.0 base score of 8.8, High, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N. It is an improper access control flaw in the web management interface: unauthenticated remote requests aimed at administrative functions can trigger backend actions before access validation finishes, which is enough to modify configuration.

    Second, the patch changed. PaperCut shipped Emergency Patch Release 2 on August 28 at approximately 2:45 p.m. Eastern, covering versions 24, 25 and 26 on Windows, Linux and macOS. The NVD records place the fix boundaries at 24.1.10, 25.0.13 and 26.0.5, which supersedes the 26.0.4 and 25.0.12 builds that went out on August 27. Version 24, which had no fix at all when the bulletin first appeared, now has one.

    The reason for the second patch is the part worth reading twice. According to reporting that both Rapid7 and BleepingComputer carry, watchTowr reproduced the vulnerabilities in full, found multiple bypasses of the first emergency patch, and identified a further authentication bypass. Help Net Security reports PaperCut’s guidance as: install Release 2 even if you have already applied the original emergency patch. Rapid7 puts it more bluntly — an organization running the first patch is not protected.

    Huntress, which observed the attacks, states the relationship between the two flaws directly: “Chained together these flaws enable pre-authentication remote code execution in the PaperCut Application Server.” Its telemetry still describes two customer environments, the first on August 26 lasting under two minutes, the second on August 27 on a server running 24.1.5.71847. PaperCut told reporters the attacks “appear limited and targeted” and that it is withholding post-exploitation detail while it investigates.

    Why it matters

    Look at what the two vectors say on their own, because this is where score-driven triage fails.

    CVE-2026-82078 is the 9.4, and it requires high privileges: PR:H. Read alone, it is an administrator-only bug — serious, but not the thing you drop a Friday for. CVE-2026-81578 needs no privileges at all, but its confidentiality impact is low and its scope is unchanged; read alone, it is a configuration-tampering flaw. Neither record, on its own terms, describes an unauthenticated attacker getting code execution on a print server.

    Together they do, and the mechanism is visible in the two records without anyone having to explain it. The 8.8 lets an unauthenticated request reach an administrative function and change configuration. The 9.4 is a class loader that instantiates “database driver classes based on configurable driver names” with no allowlist. Change the configurable name, and the thing that needed admin rights is handed to you by the thing that did not.

    That reading also lines up with an indicator PaperCut published on August 27, before either CVE existed: ERROR No suitable driver found for jdbc:no:x. A JDBC driver string that resolves to nothing is exactly the residue of an attempt to make the application load a class by name. PaperCut has not said the two are connected and we are not reporting that it has — but the vendor was publishing the fingerprint of the class-loading path a full day before the class-loading CVE was assigned.

    CVSS has no way to express any of this. There is no chain field. Both scores are correct for what they measure and both understate the situation, and an organization sorting a patch queue by base score would put a PR:H 9.4 behind any number of unauthenticated 9.8s. This is a recurring problem and it is worth naming: the chain, not the component, is the unit of risk, and the record is organized around components.

    The second point is about the federal record, and it is a live discrepancy rather than a theory. Both NVD entries carry CISA’s SSVC decision points. On CVE-2026-82078 they read Exploitation: none, Automatable: no, Technical Impact: total. On CVE-2026-81578 they read Exploitation: none, Automatable: yes, Technical Impact: partial.

    “Exploitation: none” is on both, on August 29, on a vulnerability the vendor has confirmed is being used against its customers and for which it has now shipped two emergency patches in two days. Neither record carries a cisaExploitAdd date, so there is no KEV entry and no federal remediation deadline attached to any of this.

    We do not read that as CISA getting it wrong. These records went up hours after assignment and are still in Received status; SSVC values on a fresh record are an initial assessment, and they get revised. The point is operational: right now, anyone pulling PaperCut’s risk posture from the machine-readable record gets “not exploited,” while the vendor bulletin says the opposite. If your prioritization is automated off NVD, this is the case where it is wrong in the direction that costs you.

    It is also worth noting which words those decision points use. Exploit automation and total-versus-partial technical impact are two of the four variables BOD 26-04 uses to derive federal remediation deadlines. We are not asserting a mapping — CISA publishes the authoritative schedule only as images, and public transcriptions of it disagree with one another. But the inputs to that schedule are, for this vulnerability, currently recorded as “not exploited.”

    Third: watchTowr’s further authentication bypass is, as reported, an additional flaw rather than one of the two numbered here, and we found no CVE for it and no PaperCut statement naming it. Release 2 is described as fixing it. That leaves an unnumbered vulnerability inside a shipped patch — a thing to watch, not a thing to act on.

    What to do

    • Apply Emergency Patch Release 2. Target 24.1.10, 25.0.13 or 26.0.5 or later, per the fix boundaries in the NVD records. If you patched on August 27 to 26.0.4 or 25.0.12, you are on the bypassed build.
    • Version 24 now has a fix where it did not before. If you deferred because nothing was available, re-check.
    • Keep the network restriction in place regardless. PaperCut’s original mitigation stands: if the Application Server is reachable from the public internet, restrict web access to trusted IP addresses. Given a patch that has already been bypassed once, treat exposure reduction as the control and the patch as the backup.
    • Hunt for the pre-patch window. The original indicators still apply, and they matter more now that we know the mechanism: ERROR No suitable driver found for jdbc:no:x in server.log, base64 strings in server.log, missing or truncated logs, and stray .class files. Huntress recovered Udydn.class and Moo97.class, which self-delete. Absence of indicators is not evidence of cleanliness — the vendor said so itself.
    • If you run v23 or older, you have no patch. Huntress reports 47 percent of the roughly 2,500 PaperCut installations it tracks are on v23 or earlier. That is one vendor’s visibility, not a global census, but for those servers network isolation is the entire answer.
    • Do not wait for a KEV entry. There is none, and if your process keys on federal deadlines this will not trip it.

    Sourcing note

    Checked: NVD’s API records for CVE-2026-82078 and CVE-2026-81578, which supplied the descriptions, CVSS v4.0 vectors, CWE, affected-version boundaries and CISA SSVC decision points quoted above, and which confirm no cisaExploitAdd or cisaActionDue on either; Huntress’s own writeup for the exploitation observations, the chaining statement and the installed-base figure.

    Could not reach: PaperCut’s security bulletin at papercut.com renders its body through client-side script and returned only navigation to us on repeated attempts, so every quotation attributed to PaperCut here is taken from outlets that read the bulletin — Rapid7, BleepingComputer and Help Net Security — and is labeled as such rather than quoted as primary. watchTowr’s findings were published to LinkedIn, which we could not fetch; they are reported here as secondary, via Rapid7 and BleepingComputer, which agree on the substance.

    One record oddity: at approximately 11:50 UTC on August 29, a direct NVD lookup by cveId=CVE-2026-81578 returned zero results while a keyword query returned the full record. That is an indexing lag, not a retraction.

    Unresolved: exact build numbers for Emergency Patch Release 2, which we could not confirm from a primary source — use the version boundaries instead. Whether watchTowr’s additional authentication bypass will receive its own CVE. Whether CISA will add either CVE to the KEV catalog, and whether the SSVC decision points on these records will be revised from “Exploitation: none.” We will follow the KEV catalog and update if that changes.