Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-89080

  • Seven of today’s nine stories describe a fix that never reaches the running install

    Seven of today’s nine stories describe a fix that never reaches the running install

    The most important thing published today is not the day’s highest score. HAProxy CVE-2026-90678 is a 7.5, against a 9.8 for sngrep’s stack overflow. HAProxy outranks it on where it sits and on what a reader can do about it. A remote, unauthenticated HTTP/3 client can desynchronize reused backend connections, slip requests past a frontend deny rule, and swallow other users’ Authorization headers — at the edge, in front of everything behind it. And the fix is a commit, not a release: 3.3.14 and 3.4.4 are the newest builds on their maintained branches and both sit inside the affected range, which makes “update to the latest version,” the advice most coverage will give, wrong. sngrep’s 9.8 is real, but it is a terminal SIP viewer an operator points at traffic by hand, the blast radius is one workstation, and its fix is likewise a commit on master that no tagged release and no Debian package carries.

    There is a thread, and it is the day’s actual story. In seven of the nine stories published today, a fix exists somewhere other than in something you can install. HAProxy’s and sngrep’s are commits. snappy-java’s 7.5 out-of-bounds write has no fix at all — the newest artifact on Maven Central was published in July 2025 and is the top of the affected range. LangBot 4.10.11 generates its new recovery key only when none exists, so upgrading leaves an existing installation holding the 24-bit secret the release was cut to replace. ESPnet’s patched release raises an error below PyTorch 2.6 while its own metadata still declares torch>=2.3.1, so an install that satisfies the declared dependencies gets a fixed path that throws and unfixed paths that run. Nodemailer’s denial of service was introduced by the security fix in 9.1.0 and repaired only in 10.x, so a 9.x user has to cross a major version to escape it. And Really Simple Security’s fix has been auto-updating to three million sites since September 1 under a changelog line that reads like a display bug: the code arrived, the reason to care did not.

    Order of business behind HAProxy. LangBot next, because the reset endpoint is unauthenticated and the remedy is a key rotation by hand that the upgrade will not perform for you. Then ESPnet and Nodemailer, both dependency audits rather than emergencies. Really Simple Security mostly needs confirmation that auto-update ran. snappy-java is availability-only and lands on the one decompression call that makes the caller size its own output buffer. Two records close the day: Flowise’s cross-workspace credential flaw, patched in July and given CVE IDs on Friday, six weeks later and by a third-party CNA rather than the vendor; and Internet Download Manager’s kernel driver, where a public proof of concept turns idmwfp.sys into an arbitrary registry write for any logged-in user and the vendor, by the CVE record’s account, has not responded.

    Still open at the end of the day. Two federal deadlines come due tomorrow: NVD’s records for ConnectWise ScreenConnect CVE-2026-84869 and GitLab CVE-2026-85706 both carry a cisaActionDue of 2026-09-14, Monday, September 14, 2026. Tonec has said nothing about the IDM driver, so there is no patch to wait for. snappy-java has shipped no release in more than a year. And Flowise is the day’s inverse case, worth keeping in view: the code was fixed on time, and the record took six weeks to say so.

  • Really Simple Security’s email 2FA can be cleared by an unauthenticated request — the fix has been in 9.8.1 since September 1

    Really Simple Security’s email 2FA can be cleared by an unauthenticated request — the fix has been in 9.8.1 since September 1

    A 7.5 record published this morning describes a way to strip an account’s completed email second factor without a session; the code fix has been shipping since September 1 under a changelog line that reads like a display bug.

    What happened

    NVD published CVE-2026-89080 at 6:16 a.m. UTC on Sunday, September 13, 2026, and revised it again at 11:16 a.m. UTC the same morning. The assigning source is WPScan, whose own advisory for the issue is dated September 11, 2026 and is the record’s only reference. The base score is 7.5 under CVSS v3.1, with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, and the weakness is classified CWE-287, improper authentication.

    The description is worth reading in full, because the useful detail is in its clauses. The plugin “does not prevent an unauthenticated request from resetting an account’s completed email two-factor enrolment, allowing an attacker who already knows the account’s password to bypass the second factor and obtain that user’s session, up to administrator.” WPScan titles the same finding “Really Simple Security < 9.8.1 – Unauthenticated 2FA Bypass via Email Provider State Demotion,” and credits the researcher Charles Vosburgh.

    Affected versions run from 9.5.10.1 up to, but not including, 9.8.1. The record does not say why the range starts where it does rather than at the beginning of the plugin’s history.

    The product is Really Simple Security, formerly Really Simple SSL, which WordPress.org lists at more than three million active installations. Version 9.8.1 is current and was published on September 1, 2026 — twelve days before the record describing what it fixed. Its changelog carries three security lines, and one of them is this flaw: “Security: Prevented a bug that incorrectly changed the 2FA status from active to open.” The other two read “Security: Prevented unexpected deletion of the login nonce” and “Security: Prevent XML-RPC logins without 2FA for users with 2FA configured.” This morning’s WPScan batch, which carried nine WordPress plugin records in a single minute, contained one for this plugin.

    What “unauthenticated” means here, and what it does not

    The word will travel further than the sentence around it, so it is worth pinning down. The record and the WPScan title both say unauthenticated, and the CVSS vector says PR:L — privileges required, low. Those are not in conflict; they describe different steps.

    The request that demotes the second-factor state needs no session. That is the unauthenticated part, and it is what makes this reachable by anyone who can send HTTP to the site. But clearing the second factor is not the same as logging in. To convert it into a session, the attacker still has to pass the first factor, which means already holding the account’s password — from reuse, from an unrelated breach, from a phish, or from a prior compromise. That requirement is what the vector encodes.

    So this is not a pre-authentication administrator takeover, and anyone reporting it as one is overstating it. What it is, precisely, is the removal of the control whose entire job is to make a stolen password insufficient. The blast radius is every account on the site whose password is already known or knowable, and for those accounts the second factor stops counting. AC:H reflects the conditions; C:H/I:H/A:H reflects what follows once they are met.

    Why it matters

    The uncomfortable part is what the software is for. This is not an ecommerce plugin that happens to hold sessions — it is the component an administrator installed specifically to add a second factor, and the finding is that the second factor could be taken away by an unauthenticated request. Anyone who deployed it to satisfy an insurer, an auditor, or a client requirement was, for the length of the affected range, in a worse position than they believed. Not an unprotected one, since the password still had to be known, but not the position described on the box either.

    There is precedent inside this same plugin, and it is close enough to be instructive. In November 2024 the project shipped a fix for CVE-2024-10924, a 9.8 rated AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which NVD describes as “improper user check error handling in the two-factor REST API actions” that made it “possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, when the ‘Two-Factor Authentication’ setting is enabled.” Versions 9.0.0 through 9.1.1.1 were affected. That one required no password at all. Today’s is narrower and less severe, but it is the second authentication defect in two years in the same subsystem, which suggests the two-factor code path deserves attention rather than a single fix.

    The twelve-day gap between the fix and the record is where a reader’s operational attention belongs. The order — patch first, disclosure later — is correct, and it is what coordinated disclosure looks like from the outside. But a fix nobody can identify as a fix has a shorter reach than one that is labeled. “Prevented a bug that incorrectly changed the 2FA status from active to open” is an accurate sentence. It is also a sentence that a site owner reading a September 1 update notice, deciding whether to apply an update to a production site on a Tuesday, would reasonably file under cosmetic. Nothing in it says an unauthenticated request could cause the change, and nothing in it says the consequence was a lost second factor.

    That matters less for this plugin than it would for most, because a security plugin is one of the categories site owners most often leave on auto-update, and 9.8.1 has had twelve days to propagate. A large share of the three million installations are very likely already patched, and nobody should be told to panic. But auto-update is a setting, not a guarantee. The sites least likely to have it on are the ones running a managed stack with pinned versions, a staging-to-production promotion process, or a maintenance contract that batches updates monthly — which is to say, disproportionately the sites with real users and real administrator accounts.

    The affected range’s floor is the remaining loose thread. Ranges in WordPress plugin records usually begin at 0 or at the release that introduced a feature; this one begins at 9.5.10.1, a maintenance-level version. The record does not explain it, and the plausible reading — that the email two-factor enrollment state was reshaped in that release and the missing check came with it — is an inference, not something either source states.

    What to do

    • Confirm the installed version, do not assume it. In Plugins, Really Simple Security should read 9.8.1 or later. Anything from 9.5.10.1 up to 9.8.0 inclusive is in the affected range. On a fleet, wp plugin get really-simple-ssl --field=version across sites answers this faster than clicking through.
    • If the version is older, update. The fix has been available since September 1, 2026, there is no interim mitigation published by either source, and no workaround is described in the record.
    • Check whether auto-updates are actually on for this plugin, rather than assuming they are because they are on somewhere. A site that was behind on this one is probably behind on others.
    • Treat known-password accounts as the exposure. If any administrator on an affected site has a password that appears in a credential dump, is reused elsewhere, or predates a known incident, rotate it — updating the plugin restores the second factor but does not undo a session obtained before the update.
    • Look for the signature of use. An account whose email two-factor enrollment moved from configured back to unenrolled without the user doing it is the artifact worth searching for in logs and in the plugin’s own user records.
    • No exploitation has been reported, by WPScan, by the vendor, or in the NVD record. This is a patch-soon item, not a fire.

    Sourcing note

    Checked: the NVD record for CVE-2026-89080, read directly from the NVD API, for the description, score, vector, weakness, timestamps, references, and affected version range. The WPScan advisory referenced by that record, for its title, publication date, credited researcher, and fixed version. The plugin’s WordPress.org listing, for the active-installation figure, current version, and changelog entries for 9.8.1 and 9.8.0. The NVD record for CVE-2024-10924, read directly, for the 2024 background quoted above rather than relying on secondary accounts of it.

    Conflicting dates, shown as conflicting: WPScan dates its advisory September 11, 2026; the CVE record reached NVD on September 13, 2026. Both are reported above rather than reconciled.

    Unresolved: why the affected range begins at 9.5.10.1; the reading offered above is an inference and is labeled as one. Whether the other two security lines in the 9.8.1 changelog have records of their own — none appeared for this plugin in the same WPScan batch, which is not the same as none existing. The installed-base figure is WordPress.org’s own rounded “3+ million” and no more precise number is available. There is no vendor security advisory separate from the changelog, and none is referenced by the record.