Severity Daily

IT and AI security incidents, checked against the primary source

Tag: Dependabot

  • Ten Renovate CVEs arrive 34 days after the fixes, in GitHub records that name no affected package

    Ten Renovate CVEs arrive 34 days after the fixes, in GitHub records that name no affected package

    Ten CVE records for Renovate were published on September 10, 2026, for flaws the project fixed in npm on August 4 and August 7 — and the copies of those records in GitHub’s global advisory database are marked unreviewed and name no affected package at all.

    What happened

    At 2:17 p.m. UTC on September 10, 2026, ten CVE records for Renovate reached NVD: CVE-2026-88880 through CVE-2026-88889. The assigning CNA on all ten is VulnCheck ([email protected]), not Mend and not the Renovate project.

    Renovate is a dependency-update bot. It runs inside CI holding a token for the source platform plus credentials for every private registry it reads. That is the asset at stake in most of this batch.

    Four of the ten are one bug in four places. Renovate followed the pagination URL supplied by a remote server in the HTTP Link header and attached that host’s credentials to the follow-up request, without checking that the pagination target shared an origin with the server originally contacted. The four instances are GitLab (CVE-2026-88880), GitHub (CVE-2026-88881), NuGet registries (CVE-2026-88882), and container registries listing tags and digests (CVE-2026-88887). All four are CWE-601, each carrying two VulnCheck scores: 8.6 High on CVSS v3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) and 9.2 Critical on CVSS v4.0.

    CVE-2026-88883 is a logging flaw: in versions before 44.14.4, as the record puts it, “log sanitisation for TLS private keys used for Mutual TLS was incomplete” — keys configured through hostRules[].httpsPrivateKey without the secrets option could reach the logs. It is CWE-532, 7.7 on v3.1. CVE-2026-88884, the mildest at 5.8, let digest updates escape the minimumReleaseAge check.

    The remaining four are command injection, CWE-78, in managers that read attacker-influenced strings out of the repository being updated: gomod via an unescaped depName in an import-path update (CVE-2026-88885), the Gradle Wrapper via distributionUrl (CVE-2026-88886), Mix via organization (CVE-2026-88888), and the Maven Wrapper via distributionType (CVE-2026-88889). Scores run 7.0 to 7.8 on v3.1. The gomod case is gated on configuration — the maintainers’ advisory says it applies where binarySource=docker runs with postUpdateOptions=['gomodUpdateImportPaths'] enabled.

    The fixes are not new. The batch has four fix floors, each timestamped by the npm registry: 44.11.2 at 8:22 a.m. UTC on August 4, 2026, 44.11.3 at 8:57 a.m. UTC the same morning, 44.14.4 at 9:57 a.m. UTC on August 7, and 44.14.7 at 1:50 p.m. UTC that afternoon. Mend’s self-hosted builds are fixed at 15.4.0 for the Renovate CE and EE images and charts, and 10.4.0 for the mend-renovate-enterprise-edition Helm chart.

    The maintainers published their own advisories on the project repository on August 27, 2026 — twenty days after the last of those fixes shipped. The CVE IDs arrived today, thirty-four days after 44.14.7. Renovate’s current release, 44.79.1, went to npm at 2:36 p.m. UTC today, nineteen minutes after the CVE records.

    The record is three records, and none of them is whole

    The maintainers’ advisories carry the complete engineering picture. GHSA-rh7w-ccch-gh49, the NuGet one, lists fifteen package coordinates with a patched version for each — npm renovate at 44.11.2, docker.io/renovate/renovate at 44.11.2, helm mend-renovate-enterprise-edition at 10.4.0. Its title, verbatim, is “Malicious Nuget registries could send a malicious Link header to allow exflitrating credentials.” As of this check its CVE field still reads “No known CVE,” as do those of the GitLab advisory, GHSA-9hmg-9h89-jhmx, and the gomod advisory, GHSA-mpf8-qxrw-gq3w. The linkage runs one way: NVD cites the repository advisories; they do not cite the CVEs back.

    GitHub’s global advisory database — the one Dependabot consumes — now holds a second, separate GHSA for each flaw, minted today from the CVE. The NuGet flaw is GHSA-rh7w-ccch-gh49 on the repository and GHSA-978f-wwpx-5hh6 in the global database; the Maven Wrapper flaw is GHSA-f2v7-35mm-3hx7 and GHSA-q946-5qg8-8wmj respectively. Two identifiers, one flaw, and the CVE record points at the one the global database does not use.

    Those global entries are where the damage is. Both read in full this run — GHSA-978f-wwpx-5hh6 for CVE-2026-88882 and GHSA-q946-5qg8-8wmj for CVE-2026-88889 — are marked Unreviewed, and their affected-package field reads “No package listed,” with affected and patched versions both “Unknown.” GitHub’s own documentation is explicit: “Dependabot doesn’t create Dependabot alerts for unreviewed advisories as this type of advisory isn’t checked for validity or completion.” The repository advisories carrying the version data were never promoted into the global database; the global entries carrying the CVE do not carry the versions.

    The severity label splits along the same seam. The maintainers scored the Link header flaws High, 8.6, on a v3.1 vector. GitHub’s global entry for the same flaw reads Critical, 9.2, having taken VulnCheck’s v4.0 vector. NVD publishes both and marks the v3.1 primary. Nothing here is a scoring error — v4.0’s SC:H prices the same judgment v3.1 encodes as S:C, and prices it higher. But the High/Critical boundary sits between the two numbers, so a shop running “Critical in seven days, High in thirty” takes its answer from which schema its scanner parses.

    Why it matters

    The severity is narrower than 9.2 Critical suggests, and the maintainers say so: “if the registry you are talking to is compromised, they likely already have your credentials from the initial request(s).” That is honest, and right for the obvious threat model. Where the bug actually buys an attacker something is narrower — a server that is not compromised but a single response that is, through an intercepted connection, a poisoned cache, a third-party mirror, or a compromised edge in front of a healthy registry. There the Link header is a redirect primitive handing over credentials the attacker did not already hold.

    The more durable problem is the thirty-four days and what filled them. For that month the fix existed and the identifier did not. A pipeline gate reading “no known CVEs in the running image” passed a vulnerable Renovate every day of it. Dependabot said nothing. The one channel carrying the complete, accurate, actionable picture from August 27 onward was a page on a GitHub repository — readable by a human, invisible to a scanner. Today’s records move that gap rather than close it: the record has gone from complete but unidentified to identified but incomplete, and Dependabot is still silent.

    Release velocity sharpens who is left holding it. Renovate has 11,977 published versions on npm and shipped five of them within three and a half hours this morning. Anyone tracking the floating tag cleared all four fix floors weeks ago without knowing there was anything to clear. The population still exposed is the one that deliberately does not float: pinned digests, self-hosted Mend CE and EE, internal mirrors, change-controlled environments where the bot’s version moves only on a ticket. Those are the same deployments whose upgrade trigger is a CVE feed. The record failure and the exposed population are one fact seen twice.

    This site has found the shape often enough to name it: a GHSA reading “no known CVE” for a flaw NVD has published, a CNA’s records arriving weeks after the vendor shipped. The common cause is that “the vulnerability record” does not exist. There is a maintainer’s advisory, a CVE record, and a database entry, written to three completeness standards with no obligation to reconcile — and each tool reads exactly one.

    What to do

    Upgrade Renovate to 44.14.7 or later. It is the highest of the four fix floors and covers all ten records; current is 44.79.1. For Mend’s self-hosted builds the targets are Renovate CE and EE 15.4.0 or later and mend-renovate-enterprise-edition Helm chart 10.4.0 or later.

    If you pin a digest rather than floating, check the version behind it. The floors are 44.11.2, 44.11.3, 44.14.4, and 44.14.7, so a pin below 44.14.7 leaves at least one of the ten open, and a pin below 44.11.2 leaves all four credential-exfiltration cases open. Do not wait for Dependabot; on the evidence above it will not fire.

    If your Renovate may have talked to a platform or registry host outside your control, rotate the platform token and the registry credentials. Treat CVE-2026-88883 separately, because upgrading does not fix it retroactively: a mutual-TLS private key set through hostRules[].httpsPrivateKey without the secrets option may already sit in logs you have shipped elsewhere. Rotate the key and deal with those copies.

    If you run Renovate against repositories you do not control, prioritize the four command-injection records, which read their injection point out of the target repository’s own files; check whether your configuration sets binarySource=docker with postUpdateOptions=['gomodUpdateImportPaths'], the gate on the gomod case. No exploitation has been reported, and neither the maintainers, VulnCheck, nor CISA claims any.

    Sourcing note

    Checked directly: the NVD 2.0 API records for CVE-2026-88880 through CVE-2026-88889, read for descriptions, timestamps, CVSS vectors, CWE, affected ranges, and references; the Renovate repository advisories GHSA-9hmg-9h89-jhmx, GHSA-rh7w-ccch-gh49, and GHSA-mpf8-qxrw-gq3w; the global database entries GHSA-978f-wwpx-5hh6 and GHSA-q946-5qg8-8wmj; VulnCheck’s advisory page for CVE-2026-88882; GitHub’s advisory-database documentation, for the Dependabot sentence quoted above; and npm registry metadata for renovate, which supplied every release timestamp here.

    Not established: whether the eight global advisory entries not opened individually share the “No package listed” defect of the two that were. The two read in full come from different halves of the batch, but the claim is made only for them. Whether the maintainers will add the new CVE IDs to their advisories is unknown; they had not as of this check. The reasoning about which deployments remain exposed is this publication’s, not any vendor’s. CISA’s KEV catalog was read through the cisagov/kev-data GitHub mirror, because cisa.gov returns 403 to automated fetching from this container; it stood at version 2026.09.09 with 1,703 entries and contains none of these CVEs.