Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-18922

  • A 10.0 under attack, two unfixed 9.8s, and not a version number among them

    A 10.0 under attack, two unfixed 9.8s, and not a version number among them

    Adobe published APSB26-146 on Labor Day afternoon and said, in one sentence of its own, that it is “aware of CVE-2026-75650 being exploited in the wild” — a CVSS 10.0 unauthenticated code-execution flaw reaching every supported branch of Adobe Commerce and Magento Open Source. That is the day’s top item, and the timing says more than the score does. Adobe’s regularly scheduled September release is set for September 8. It shipped out of band anyway, into a US federal holiday evening, with the NVD record landing after 5 p.m. Eastern. A vendor that gives up one day of coordination on a product this widely deployed is making a judgment about how bad this is, and that judgment is the more honest read.

    The day had a thread, and it is not a record-quality problem. Today’s records are clear. What they lack is a version. Adobe’s “Updated Version” column contains the string “Hotfix for CVE-2026-75650” — prose where a build number belongs — so nothing that answers “are we patched?” by comparing a version to a range can confirm this fix. Red Hat published two 9.8s and was equally plain: the FreeIPA record lists no fixed package for any affected product, and the 389 Directory Server record lists 31 affected products, one unaffected, and zero fixed. Neither record is wrong. The remediation does not exist yet, and the vendor says so in the remediation field.

    Those two Red Hat records are the second thing to deal with, and they are one attack chain rather than two bugs. FreeIPA’s description says the flaw is exploited “combined with a related flaw in the underlying directory server’s ACI evaluation (tracked separately)”; that companion, CVE-2026-76560, published an hour later and scored 7.5, is the load-bearing half of the 9.8. Red Hat says it independently confirmed the technique against a default, unmodified installation. What it offers in the meantime is a firewall rule for FreeIPA and, for the directory server, removing PLAIN from the SASL mechanisms the server will negotiate — the better of the two, because it addresses the mechanism instead of the reachability, though it asks administrators to introduce an explicit allow-list into deployments that, by Red Hat’s own account, mostly do not have one.

    The inverse case is Advantech’s WISE-6610 gateway, where the fix shipped weeks ago in firmware 1.2.4_20260821 and no advisory was published for any of the three root command injections it closes — one of which has had a working public exploit since February. Below that the day turns to scoring and record quality rather than urgency: MediaTek labels three flaws High that its own CVSS v3.1 scores put at Medium, on a bulletin that states it grades by CVSS v3.1; h3’s cookie-loop hang is Moderate to the project and High to VulnCheck, and the whole 2.2-point gap is one availability metric, with the only fix a pre-release build; the Knowns batch closed five flaws in 0.30.0 and left a sixth described as reaching 0.33.0, the current release, with nowhere to upgrade to; and Bilibili Desktop turns off TLS certificate verification process-wide and names no fixed version either. Ardent Health’s 8-K is the one item that is not a vulnerability at all: the SEC made the company drop $97.7 million in non-GAAP add-backs, and the carve-out for its November 2023 ransomware attack survived untouched.

    Still open. CVE-2026-75650 is not in CISA’s Known Exploited Vulnerabilities catalog as of this writing, so the one flaw confirmed under attack today carries no federal remediation deadline. Adobe’s next scheduled release is September 8, and APSB26-146 credits researchers against five CVE identifiers that do not appear in its own vulnerability table. The publication date of Sansec’s StyleSmuggler writeup — September 5 or September 7 — is unresolved. And Red Hat’s zero-fixed count now spans 31 products on one record and 41 on the other, eleven days after an earlier FreeIPA privilege-escalation flaw that still has none.

  • A failed SASL PLAIN bind leaves its identity on the connection, and 389 Directory Server hands the next bind full Directory Manager rights

    A failed SASL PLAIN bind leaves its identity on the connection, and 389 Directory Server hands the next bind full Directory Manager rights

    CVE-2026-18922 needs no account and no unusual configuration, and Red Hat’s own product data lists 31 affected products, one unaffected, and zero with a fix.

    What happened

    Red Hat published CVE-2026-18922 to the National Vulnerability Database on September 7, 2026, at 3:17 p.m. UTC. The record is in NVD’s Received state, carries a single CVSS score from the assigning CNA [email protected] — 9.8, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — and is classified CWE-287, improper authentication.

    The description is unusually specific about how to do it:

    A flaw was found in 389 Directory Server. During SASL PLAIN authentication, a stale identity carried in a Cyrus SASL auxiliary property from a prior failed bind attempt can be installed on a connection following a subsequent, unrelated successful bind, regardless of which SASL mechanism completes that second bind. An attacker can send a SASL PLAIN bind as cn=Directory Manager with an incorrect password, then complete a SASL ANONYMOUS bind on the same connection, causing the server to grant Directory Manager authority without any valid credentials. A variant using a valid low-privileged account’s own successful bind instead of an anonymous one is also possible.

    Red Hat’s CSAF VEX document, released at 2:47 p.m. UTC the same day, is titled “389-ds-base: SASL PLAIN authentication allows privilege escalation to Directory Manager via stale identity in Cyrus SASL auxiliary property.” Its statement:

    This flaw is rated Critical because it allows a remote, unauthenticated attacker to gain full Directory Manager privileges over an LDAPS connection — with no valid account, no user interaction, and no non-default configuration required.

    The remediation Red Hat offers is a configuration change, not a package:

    Administrators can restrict nsslapd-allowed-sasl-mechanisms to only the mechanisms actually required (e.g. GSSAPI, EXTERNAL, GSS-SPNEGO), excluding PLAIN.

    The VEX product status lists 31 products under known_affected — Red Hat Directory Server 11 and 12, and the 389-ds-base packages across Red Hat Enterprise Linux 6, 7, 8, 9, and 10. One product sits under known_not_affected: Red Hat Directory Server 13. Nothing is listed as fixed.

    Four more in the same batch

    CVE-2026-18922 arrived with four other 389 Directory Server records published by Red Hat on September 7, none of which has a fix either:

    • CVE-2026-19843, 8.4, CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H — command injection through an unescaped LDAP distinguished name in the Cockpit 389 Console LDAP editor. Thirty products affected, eight not affected, zero fixed. Deployments without the Cockpit console are not affected.
    • CVE-2026-18355, 7.5, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H — a heap buffer overflow in sasl_io_start_packet(), where the wrapped-record length read from the wire is validated only against an upper bound. Twenty-nine affected, four not affected, zero fixed. Red Hat’s workaround field reads: “Red Hat has investigated whether a possible mitigation exists for this issue, and has not been able to identify a practical example.”
    • CVE-2026-18453, 7.5 — a missing NULL pointer check in paged-results handling that lets an unauthenticated remote attacker crash ns-slapd.
    • CVE-2026-76560, 7.5 — the SELFDN ACI bind-rule evaluator matching an anonymous client’s empty bind DN against an empty stored attribute value. This is the directory-server half of the unauthenticated FreeIPA administrator chain published the same day, covered separately.

    Red Hat Directory Server 13 is listed as not affected by CVE-2026-18922, CVE-2026-18355 and CVE-2026-76560. It is the only product that appears on the clean side of all three.

    Why it matters

    Directory Manager is not a privileged role inside 389 Directory Server. It is the account that exists outside the access-control system entirely — the superuser DN that ACIs do not constrain, used to bootstrap the directory and repair it when its own permissions are broken. Obtaining it is not privilege escalation within a directory. It is the point at which the directory stops being an authority about anything, because every answer it gives afterward could have been written by the person asking.

    What makes this bug worth studying is that the authentication check works correctly. SASL PLAIN receives cn=Directory Manager with the wrong password, evaluates it, and rejects the bind. The failure is not in the decision; it is in what the failed decision leaves behind. The identity from the rejected attempt stays in a Cyrus SASL auxiliary property on the connection, and the next successful bind — “regardless of which SASL mechanism completes that second bind,” in Red Hat’s words — picks it up. This is an error-path cleanup defect wearing an authentication bypass’s clothes, and it belongs to a family that keeps recurring: code that is careful about the success path and casual about state left over from failure.

    The choice of second bind is what removes the last obstacle. A reader skimming “following a subsequent successful bind” might reasonably assume the attacker needs some credential to produce that success. They do not. SASL ANONYMOUS is a bind that succeeds by design while proving nothing, and Red Hat names it explicitly in the attack sequence. The precondition that sounds like a barrier is a single unauthenticated round trip.

    That has a direct consequence for anyone reaching for the obvious defense. Disabling anonymous binds is the standard hardening answer to almost every LDAP problem, and it is the right instinct — but the description closes it off in its own last sentence: “A variant using a valid low-privileged account’s own successful bind instead of an anonymous one is also possible.” In a directory, a valid low-privileged account is not a scarce resource. It is every employee. The mitigation Red Hat actually offers targets the first step instead, removing PLAIN from the mechanisms the server will negotiate at all.

    That mitigation is better than the network-segmentation advice Red Hat is giving for the FreeIPA flaw published the same day, because it is narrow and it addresses the mechanism rather than the reachability. It also carries a wrinkle worth stating plainly. The statement says the attack requires “no non-default configuration” — which means the exposure exists where nsslapd-allowed-sasl-mechanisms has never been set, and where it is unset the server offers whatever Cyrus SASL makes available. So the fix-by-configuration requires administrators to introduce an explicit allow-list into deployments that, by the vendor’s own account, mostly do not have one. Before setting it, you have to know which mechanisms your clients genuinely use, and getting that list wrong takes the directory down for everyone.

    One more line in the statement deserves reading closely: full Directory Manager privileges “over an LDAPS connection.” Transport encryption is not a mitigating factor here, and organizations that treat LDAPS-only as a hardening milestone should note that it does not touch this. Nor does the record carry any CISA KEV fields — cisaExploitAdd, cisaActionDue, cisaVulnerabilityName and cisaRequiredAction are all absent from NVD — and no exploitation has been reported by any vendor, agency, or researcher. This is severity without observed attacks, which is the window in which acting is cheapest.

    What to do

    • Set nsslapd-allowed-sasl-mechanisms explicitly, listing only the mechanisms your clients use and excluding PLAIN. Red Hat’s examples are GSSAPI, EXTERNAL, and GSS-SPNEGO. Confirm what is actually in use from your access logs before you set it — an incomplete list breaks binds.
    • Do not treat disabling anonymous binds as the mitigation. Red Hat’s own description says the attack also works using a valid low-privileged account’s successful bind.
    • Check what you are running. Red Hat lists Directory Server 13 as not affected; Directory Server 11 and 12 and the 389-ds-base packages on RHEL 6 through 10 are affected, with no fix in any stream as of today.
    • Search access logs for the shape of the attack: a failed SASL PLAIN BIND followed on the same connection by a successful BIND, and any operation attributed to cn=Directory Manager from a source that has no business issuing one.
    • Restrict access to the Cockpit 389 Console and to delegated LDAP add and rename privileges, per Red Hat’s workaround for CVE-2026-19843. Plain deployments without the console are unaffected by that one.
    • Restrict LDAP on 389 and 636 to trusted hosts while no package exists, and track Red Hat’s CVE pages for errata directly — these records have no CPE data while they sit in Received, so CPE-matching scanners will not flag them.

    Sourcing note

    Checked: the NVD API record for CVE-2026-18922, retrieved September 7, 2026, showing vulnStatus Received, lastModified equal to its publication timestamp, and no CISA KEV fields; Red Hat’s CVE page for the same; and Red Hat’s CSAF VEX documents for CVE-2026-18922, CVE-2026-19843, CVE-2026-18355 and CVE-2026-76560 at security.access.redhat.com, which are the source for all product-status counts and remediation text. Every description, statement, and mitigation passage above is quoted verbatim from Red Hat’s records.

    Could not reach: no Red Hat errata exists for any of these CVEs; a search of Red Hat’s advisory index returned only RHSA-2026:36195, a 389-ds-base update issued July 7, 2026 for CVE-2026-11610 and CVE-2026-11774, which are unrelated. Bugzilla 2511388 is referenced by the CVE-2026-18922 record but was not read. cisa.gov returns 403 to automated fetching, so KEV status is taken from the CISA fields republished inside NVD, where they are absent.

    Unresolved: the CVE-2026-18453 entry above is summarized from Red Hat’s published CVE listing rather than from its own VEX document, which was not separately retrieved; its affected-product counts are therefore not stated here. Third-party vulnerability aggregators list a CVE-2026-18043 for a Cockpit 389 LDAP editor command injection that appears to describe the same defect as CVE-2026-19843; no Red Hat record for that identifier was found, and this story reports only the identifier Red Hat itself published. Product counts are Red Hat’s figures as retrieved today and will move as triage continues.