Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CNA

  • Two CNAs backfilled thirteen CVEs onto Craft CMS advisories that say “No known CVE,” and one record’s description belongs to a different bug

    Two CNAs backfilled thirteen CVEs onto Craft CMS advisories that say “No known CVE,” and one record’s description belongs to a different bug

    Thirteen Craft CMS CVEs appeared on September 2, 2026 from two CVE Numbering Authorities, neither of them Craft — one advisory drew two separate CVE IDs, and a third record’s description belongs to a different bug entirely.

    What happened

    Craft CMS publishes its own security advisories on GitHub. It does not request CVE identifiers for them. Every one of the advisories discussed below carries the same line in its CVE field: “No known CVE.”

    On September 2, 2026, thirteen Craft CMS CVEs were published anyway, by two CNAs that are not the vendor.

    VulnCheck published eleven of them — CVE-2026-84792 through CVE-2026-84802 — at 12:17 p.m. UTC. They map onto a set of Craft advisories published August 18, 2026 and fixed in Craft CMS 5.10.11, and they run from a 4.3 broken-access-control issue in the element index up to a 9.8 privilege escalation.

    Three hours later, at 3:17 p.m. UTC, a second CNA called Hackrate published two more: CVE-2026-79990 and CVE-2026-79991. Both cite Craft advisories, both cite a Hackrate “hacktivity” page, and CVE-2026-79991 credits a reporter, @Uncle_cui233, with Hackrate as coordinator. That ID was reserved on August 25, 2026.

    One advisory, two CVE IDs

    Craft’s advisory GHSA-3wcr-p33w-528f, “GQL entry mutation siteId bypasses schema site scope, enabling cross-site content read/write/delete,” is rated High by the vendor and fixed in 5.10.11. It now has two CVE identifiers.

    VulnCheck’s CVE-2026-84796 references it and scores it CVSS 3.1 base 8.8 and CVSS 4.0 base 8.7, CWE-639. Hackrate’s CVE-2026-79990 references the same advisory and the same 5.10.11 release, scores it CVSS 4.0 base 8.7 with no CVSS 3.1 metric at all, and also assigns CWE-639. Same bug, same advisory, same fix, two identifiers, three hours apart.

    One record describing a different bug

    The second Hackrate record is the more serious problem. CVE-2026-79991 references Craft’s advisory GHSA-4mgp-5vf2-7c9m and the 5.10.13 release, carries CWE-89 — SQL injection — and scores CVSS 4.0 base 7.1 with an SSVC Technical Impact of partial.

    Its description is this:

    “Craft CMS GraphQL entry mutation resolvers (saveEntry, deleteEntry) read siteId directly from $arguments without passing through ArgumentManager prepareArguments(), which is the function that enforces site-scope filtering via array_intersect against the GraphQL schema’s allowed sites. The query path (ElementResolver prepareElementQuery) correctly calls prepareArguments(), so queries to unauthorized sites return empty. But mutations bypass this entirely — an attacker with a token scoped to Site A can create, modify, or delete entries in Site B by passing siteId in the mutations argument.”

    That is the description on CVE-2026-79990, word for word. It is the GraphQL site-scope bypass, fixed in 5.10.11, classified CWE-639.

    The advisory CVE-2026-79991 actually points at is titled “Authenticated SQL Injection via nested eager-loading criteria,” rated High, published September 1, 2026, and fixed in 5.10.13. Its description reads: “A non-admin, low-privileged Control Panel user (whose permission set is limited to the single baseline permission accessCp) can perform blind SQL injection against the element-index endpoint (element-indexes/get-elements and siblings), gaining arbitrary read access to the database.”

    So the record’s CWE, its reference, its fixed version, and its score all describe a blind SQL injection reachable by a low-privileged Control Panel user. Its description describes an unrelated GraphQL authorization bypass reachable with a scoped API token. The CWE is the giveaway: CWE-89 sits on top of a paragraph that never mentions SQL.

    The vendor said Moderate

    The largest number in the batch is CVE-2026-84795, VulnCheck’s identifier for Craft’s advisory GHSA-242m-9wq7-vhwq, “Public registration inherits admin flag from deactivated admin accounts via missing guard.” Craft, which wrote the patch, labels that advisory Moderate.

    VulnCheck scores it CVSS 3.1 base 9.8 on AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and CVSS 4.0 base 9.2. NVD carries the 9.8 with a type of “Primary” — the ecosystem’s headline number for this issue is the third party’s, not the vendor’s.

    The underlying condition, per Craft’s own text, is narrow: an attacker registers using the email address of an admin account that was deactivated rather than deleted, and the admin flag persists onto the new account. It requires public registration to be enabled and email verification to be disabled.

    NVD’s handling of the batch is not consistent either. CVE-2026-84795 sits at vulnStatus “Received.” CVE-2026-84796, published in the same minute by the same CNA, is already “Deferred,” as are both Hackrate records.

    Why it matters

    This site reported on September 1 that Kyverno drew six CVEs in 38 seconds from a third-party CNA, one of them scored 3.7 and 9.3 for the same issue. This is the second instance in three days, and the failure is a different one: not a scoring conflict inside a record but duplicate identifiers across two CNAs, and a description transplanted from one bug onto another.

    Third-party backfill exists for a real reason. A project that publishes GitHub advisories and never requests CVE IDs is invisible to every tool that keys on CVE identifiers — most vulnerability scanners, most SBOM pipelines, most procurement questionnaires. Someone filling that gap is doing work the ecosystem needs. Craft’s advisories are unusually good: they name the method, the endpoint, and the guard that was missing. They are exactly the kind of source a backfiller can work from.

    The cost appears when that work is done at volume without the vendor in the loop. Every defect above is one the maintainer would have caught in a minute. Craft knows GHSA-3wcr-p33w-528f is one bug, not two. Craft knows what GHSA-4mgp-5vf2-7c9m says, having written it the day before. And Craft’s own advisories still read “No known CVE” for issues that now carry identifiers, because nothing tells a maintainer that a stranger assigned CVEs to their advisories.

    Duplication is not a cosmetic problem. Deduplication is a core CNA function — the whole value of a CVE identifier is that it is one name for one flaw, so that two tools reporting the same issue can be recognized as reporting the same issue. An organization counting Craft CMS vulnerabilities for a risk register now counts the GraphQL site-scope bypass twice. A tool that maps 84796 and 79990 to different remediation tickets will chase a fix that was already applied.

    The wrong description is worse, because it is actively misleading in the direction of doing nothing. A defender who reads CVE-2026-79991 as written will conclude the issue is a GraphQL API token problem and check whether GraphQL is even enabled. The advisory it points at describes an attack available to any authenticated Control Panel user holding a single baseline permission. Those are different threat models, different mitigations, and different sets of people to worry about. The record contains both, and only one of them is right.

    The severity gap is the least alarming of the three, and worth stating carefully. Vendors and third parties disagree about scores all the time, and a CVSS base score is not supposed to model deployment conditions. Craft’s Moderate reflects a bug that needs public registration on, verification off, and a deactivated-not-deleted admin whose email the attacker knows. VulnCheck’s 9.8 reflects what happens when those conditions hold. Neither is dishonest. What matters is which one the ecosystem inherits, and NVD’s “Primary” flag answers that: the 9.8. The vendor’s judgment is one page away, on an advisory that says no CVE exists.

    What to do

    Upgrade Craft CMS 5 to 5.10.13 or later. That covers both batches: 5.10.11 fixed the August 18 advisories behind CVE-2026-84792 through CVE-2026-84802, and 5.10.13’s release notes list seven further advisories including GHSA-4mgp-5vf2-7c9m and three high-severity remote code execution issues (GHSA-5jmw-g85v-7jv2, GHSA-9c4j-cjw3-r3xx, GHSA-5r92-75j8-c534).

    If public registration is enabled on a Craft site, check whether email verification is required, and audit for deactivated admin accounts. Deleting a departed administrator’s account, or changing its email address, removes the precondition for CVE-2026-84795 independently of the patch.

    When scoping any of these, read Craft’s GitHub advisories rather than the CVE records. The advisories name the endpoint and the missing check; several of the CVE records do not, and one of them names the wrong bug. Treat CVE-2026-84796 and CVE-2026-79990 as a single issue. Ignore CVE-2026-79991’s description and follow its reference instead.

    Sourcing note

    Checked: NVD records for CVE-2026-84792 through CVE-2026-84802, CVE-2026-79990, and CVE-2026-79991, giving publication timestamps, source identifiers, metrics with source and type, CWEs, references, and vulnStatus values. Checked: the CVE Program record for CVE-2026-79991, giving Hackrate as assigner with organization ID 7004884b-51e2-48e8-b4a2-5ca29e80453e, a reserved date of August 25, 2026, the credited reporter, and the affected range of 5.0.0-RC1 through 5.10.12. Checked: Craft’s advisories GHSA-242m-9wq7-vhwq, GHSA-3wcr-p33w-528f, and GHSA-4mgp-5vf2-7c9m for their titles, vendor severity labels, CVE fields, and descriptions, all quoted above. Checked: VulnCheck’s advisory page for CVE-2026-84795.

    Not resolved: whether the duplicate assignment on GHSA-3wcr-p33w-528f will be rejected on one side, and which one. Not resolved: whether CVE-2026-79991’s description will be corrected, or whether Craft has been notified of any of this — neither CNA’s record shows vendor coordination, and Craft’s advisories still read “No known CVE.” The publication date shown on the 5.10.13 release page did not parse reliably on this fetch, so the release date is not stated here; the advisory it fixes is dated September 1, 2026. No exploitation of any CVE in this batch has been reported, and none is in the KEV catalog as of this writing.

  • A joined cluster can write lines into submariner’s ipsec.conf and run as root on the gateway, and Red Hat lists no fixed version

    A joined cluster can write lines into submariner’s ipsec.conf and run as root on the gateway, and Red Hat lists no fixed version

    CVE-2026-66786 reached the public CVE record on September 2, 2026, carrying a 9.1 that Red Hat marks as a draft, a severity rating of Moderate, and no fixed version for anything.

    What happened

    Red Hat, acting as CNA, published CVE-2026-66786 to the CVE record on September 2, 2026. NVD received it at 6:21 p.m. UTC and has it at status “Received,” meaning no NVD analysis has been done. Red Hat’s own machine-readable entry gives the flaw a public date of August 21, 2026, at 4:43 p.m. UTC, so the record is twelve days behind the disclosure.

    The description is short: “A flaw was found in submariner. In cert-auth mode, the connection configuration is built using free-form strings from the Custom Resource Definition (CRD) without proper validation.” Submariner is the component that stitches separate Kubernetes clusters into one flat network, and it builds IPsec tunnels between gateway nodes to do it. The Bugzilla entry behind the CVE, number 2507531, is more specific about the mechanism than the CVE description is: “submariner: ipsec.conf stanza injection via remote-supplied CableName and Subnets.”

    That is the whole flaw. A cluster on the other end of the mesh publishes a cable name containing newlines and IPsec directives. Those strings are written into the local ipsec.conf without validation, so the remote cluster is not supplying a name — it is supplying configuration. Red Hat’s write-up says the result is “remote code execution as root on the gateway node.”

    The scoring is where the record gets interesting. Red Hat’s [email protected] supplied CVSS 3.1 base score 9.1, vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H — network vector, high privileges required, scope changed, everything else high. Red Hat’s record marks that score’s status as draft. Its own threat severity for the same flaw is Moderate, and it explains why: “Red Hat rates this flaw as Moderate severity rather than Important because exploitation requires two non-default configurations that must both be explicitly enabled.” Cert-auth mode is off by default and exists for optional OVN-Kubernetes integration.

    The named affected product is Red Hat Advanced Cluster Management for Kubernetes 2, across the submariner gateway, operator, route-agent, and addon packages. What the record does not contain is any affected_release entry and any package_state entry — no errata number, no release date, and no per-product fix state, not even “will not fix” or “affected.” The remediation on offer is a configuration change:

    “PSK mode provides equivalent inter-cluster IPsec tunnel encryption and is not affected by this vulnerability.”

    Administrators are told to set IPSecCertAuthMode: false in the SubmarinerConfig CR. Checked on September 2, 2026, the upstream project’s GitHub security advisories page for submariner-io/submariner says “There aren’t any published security advisories,” and the OSV database returns a 404 for the CVE ID. There is no fixed version to upgrade to on the public record, from Red Hat or from upstream.

    Why it matters

    Multi-cluster networking has a trust model that is easy to state and easy to forget. When you join a cluster to a submariner broker, that cluster publishes Endpoint objects describing itself, and every other cluster in the mesh consumes them. The cable name is one of those self-declared fields. It has always been remote-supplied input; what this CVE establishes is that it was being handed to a line-oriented config format that treats a newline as the start of a new instruction. The privilege boundary a mesh operator thinks they have — peer clusters can route to me — turns out to have been peer clusters can run commands as root on my gateway node, in the one mode where the tunnels are authenticated by certificates rather than a shared key.

    The severity gap is worth being precise about rather than picking a side. Both numbers are defensible and they measure different things. CVSS 9.1 with PR:H and S:C describes what happens once an attacker is a peer: total compromise of a node outside the vulnerable component’s own scope. Red Hat’s Moderate describes how likely you are to be in that position at all, given that cert-auth mode has to be turned on deliberately. Neither is wrong. The practical problem is that they travel separately. A scanner that ingests the CVSS base score raises a critical finding on every RHACM cluster in the estate. A dashboard that ingests the vendor severity shows Moderate and may not surface it at all. The same record produces both answers, and the field that reconciles them — whether IPSecCertAuthMode is set — is not in either feed. It is in a custom resource on your own clusters, and it is the only thing that actually decides whether this applies to you.

    The draft flag on the CVSS is a second reason not to over-anchor on 9.1. Red Hat is telling readers, in the record itself, that the score has not been finalized. That is more transparency than most vendors offer, and it is also a warning that a number now circulating through every downstream feed may not be the number that survives.

    The blank fix state is the part with the sharpest operational edge. RHACM 2 is named as affected. There is no errata, no fixed package version, and no upstream advisory. Twelve days after Red Hat’s own public date, a team that reads the record correctly can answer “are we exposed” — check one CR field — and cannot answer “what do we upgrade to.” That is a familiar shape on this site: last week the same gap turned up as a fixed-version range that named a release still carrying the vulnerable line. Here the range is simply absent, which is at least honest, but it leaves the mitigation doing the work a patch would normally do.

    One more thing links this to the other record published on this site today. The mechanism is not a memory bug or a cryptographic mistake. It is a name field that flows unescaped into a configuration file whose grammar is “one directive per line.” That is the same shape as a repository’s .git/config setting core.fsmonitor to a command: a value nobody thought of as executable, in a format that turns text into instructions. Config formats are being handed attacker-controlled strings by software that treats them as inert data, and the fix in both cases is validation at the boundary, not a smarter parser.

    What to do

    Check whether this applies at all. Look at IPSecCertAuthMode in the SubmarinerConfig CR on each managed cluster. If it is unset or false, you are on PSK mode and Red Hat says you are not affected. If it is true, you are in scope.

    If it is true, switch it. Red Hat’s stated mitigation is to set IPSecCertAuthMode: false, returning to pre-shared key authentication, which it says provides equivalent tunnel encryption. Treat that as the remediation for now, because there is nothing to upgrade to.

    If you need cert-auth for OVN-Kubernetes integration and cannot switch, the operating assumption until a fix ships is that any cluster able to publish an Endpoint to your broker can execute code as root on your gateway nodes. Audit which clusters are joined and who can create or edit those objects, and treat broker access as equivalent to node-level access.

    Watch for an errata. Red Hat’s CVE page is the place a fixed version will appear first. As of this writing there is none, and the absence is in the machine-readable record, not just the human-readable page — so an automated check for “is there a fix yet” will keep returning nothing until Red Hat files one.

    No urgency beyond that. There is no reported exploitation, the CVE is not in CISA’s Known Exploited Vulnerabilities catalog, and no federal remediation deadline attaches to it. This is a configuration check to run this week, not tonight.

    Sourcing note

    Checked against primary sources: the NVD record for CVE-2026-66786, published and last modified September 2, 2026, at 6:21 p.m. UTC with status “Received”; Red Hat’s machine-readable security data entry for the same CVE, which supplied the Moderate threat severity, the August 21, 2026, public date, the draft status on the 9.1 CVSS, the Bugzilla title, and the mitigation text quoted above; Red Hat’s public CVE page; the GitHub security advisories page for submariner-io/submariner; and the OSV API, which has no record for this identifier.

    Not reached: Bugzilla 2507531 itself, which is referenced by the record but was not retrieved for this story, so the “CableName and Subnets” phrasing is taken from the Bugzilla description field carried inside Red Hat’s security data rather than from the bug report. cisa.gov returns 403 to automated fetching; the KEV status above was checked against the catalog data published through CISA’s own GitHub channel, which is known to lag by a day or more, so read it as “no evidence of a KEV listing” rather than a positive confirmation of absence.

    Unresolved: whether the Subnets field is a second injection path or the same one described differently; whether an RHACM errata is in preparation; why the CVE record reached the public catalog twelve days after Red Hat’s stated public date; and whether upstream submariner considers itself affected, given that it has published nothing.