Severity Daily

IT and AI security incidents, checked against the primary source

Tag: npm

  • A 9.8 CVE for hulumi describes the project’s own CI sandbox, not anything users install

    A 9.8 CVE for hulumi describes the project’s own CI sandbox, not anything users install

    CVE-2026-82857 carries a 9.8 CVSS v3.1 base score for an over-permissive IAM policy in the hulumi project’s own AWS sandbox account — a resource nobody who installs hulumi has, described with a version range that implies they do.

    What happened

    NVD published two CVE records for the open-source project kerberosmansour/hulumi on Monday, August 31, 2026, both at 9:17 a.m. UTC, both assigned by VulnCheck as CNA, and both scored 9.8 CRITICAL on CVSS v3.1 and 9.3 CRITICAL on CVSS v4.0.

    CVE-2026-82856 is a real defect in shipped code. NVD carries the description verbatim: “@hulumi/policies versions before 1.3.2 fail to properly validate set-qualified AWS IAM condition operators in GitHub OIDC trust policies. Attackers can use ForAnyValue:StringLike operators to hide wildcard GitHub Actions OIDC subject conditions from security guardrails.” The package is a policy inspector. Its job is to look at an AWS IAM trust policy and refuse the unsafe ones. Before 1.3.2 it matched only the bare StringLike and StringEquals condition operator keys, so a policy that wrote the same condition as ForAnyValue:StringLike sailed past the check — and a wildcard in a GitHub Actions OIDC sub claim is the condition that decides which repositories, branches, and forks may assume an AWS role. A guardrail that can be stepped around by spelling the operator differently is worth a CVE.

    CVE-2026-82857 is a different kind of thing. Its NVD description reads: “hulumi versions before v1.3.2 contain a privilege escalation vulnerability in the weekly integration IAM policy that allows role lifecycle operations on af-e2e-* roles without sufficient boundary restrictions. Attackers with the documented principal can create persistent higher-privilege roles in the sandbox account.”

    The weekly integration IAM policy. The sandbox account. The af-e2e-* role prefix. These are the project’s own continuous-integration plumbing. The maintainer’s advisory, GHSA-35qr-vx94-m5x3, describes the fix as removing unnecessary inline-policy and trust-update permissions and updating the documentation that recommended them. The affected resource is an IAM policy in an AWS account the project controls, and the qualifying condition is stated in the description itself: “Attackers with the documented principal.”

    Nothing about that reaches a downstream user. Installing hulumi 1.3.1 does not create the weekly integration policy in your account. It does not create af-e2e-* roles. It does not grant you, or anyone attacking you, the documented principal. The exposure described is the maintainer’s CI sandbox, and it was fixed there.

    The record does not say that. NVD lists vendor kerberosmansour, product hulumi, and a vulnerable range of versions 0 through 1.3.1, fixed in 1.3.2 — the standard shape of a record that means “upgrade or you are exposed.” The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. PR:N asserts that no privileges are required, in a record whose own description requires the attacker to hold a specific documented AWS principal. Those two statements cannot both be true.

    Two smaller record notes. CVE-2026-82856 was published on August 31, 2026 for a defect the maintainer disclosed publicly on May 15, 2026 in GHSA-q2f7-m237-v562, which GitHub reviewed on May 21, 2026 — the CVE arrives 108 days after public disclosure, and the GitHub advisory still shows “No known CVE.” And the two records give different CVSS v4.0 vectors for the same flaw: GitHub’s ends VC:H/VI:H/VA:N, VulnCheck’s ends VC:H/VI:H/VA:H. Both compute to 9.3, so the disagreement over whether availability is affected at all leaves no trace in the number anyone reads.

    On scale: @hulumi/policies recorded 4,739 downloads in the month ending August 29, 2026, per the npm registry’s own download API. This is a small package, and saying so is not a dismissal — it is the number that was missing.

    Why it matters

    This is the third batch of VulnCheck-assigned CVEs on small open-source projects that this site has had to check in three days, after the MCP server batch on August 30 and the MCPHub batch on August 31. The pattern across all three is the same, and it is worth naming plainly rather than repeating story by story: months-old maintainer advisories are being converted into CVE records in bulk, at CRITICAL scores, with version ranges and attack vectors that describe a more dangerous and more general situation than the underlying advisory does.

    Bulk CVE assignment is not a bad thing in itself. Plenty of real defects sit in GitHub advisories for months with no CVE, invisible to every scanner that keys on CVE IDs, and a CNA willing to do that unglamorous work is doing the ecosystem a favor. CVE-2026-82856 is a good example.

    The problem is what happens when the same pipeline meets something that is not a product defect. A CVE record is not a description; it is an instruction to machinery. Scanners read the version range and tell you that you are running vulnerable software. Dependency bots read it and open a pull request. Vendor-risk questionnaires read the score and ask you to attest that you have remediated all criticals. None of that machinery reads the description, and the description is the only place CVE-2026-82857 says the exposure is somebody else’s sandbox.

    So the cost is not that a maintainer’s CI hygiene got publicized. It is that everyone running hulumi will be told, by tools they trust, that they have a critical remotely exploitable vulnerability requiring no privileges — and when they read the advisory and find it does not apply to them, they learn that critical findings from this source can be safely ignored. That lesson generalizes. It will be applied next time to CVE-2026-82856, which does apply to them, and which is the one they should actually act on. Both records came out of the same batch at the same minute with the same score. Nothing in the metadata distinguishes the one that matters.

    PR:N is where this becomes concrete rather than philosophical. Privileges Required is not decoration; it is the field that separates “anyone on the internet” from “an insider with a specific credential,” and it is doing most of the work in the jump from a serious score to a 9.8. Setting it to None in a record whose description begins “Attackers with the documented principal” is not a judgment call about which reasonable people disagree. The description contradicts the vector, in the same record, in adjacent fields.

    There is a defensible way to publish an incident like this one. If a maintainer wants to disclose that their own CI account was over-permissioned, a repository advisory does that honestly, and hulumi’s does. What a CVE adds is a claim about affected installed versions, and where there are none, the honest range is empty. GHSA-35qr-vx94-m5x3 did not resolve in GitHub’s global Advisory Database when checked for this story; the repository is the correct home for a finding about a project’s own infrastructure.

    What to do

    If you use @hulumi/policies: upgrade to 1.3.2 or later. CVE-2026-82856 is real and the fix is in that release. Then audit the trust policies the old inspector approved: it is not enough to fix the inspector if it already waved through a policy containing a set-qualified wildcard. Grep your IAM trust policies for ForAnyValue: and ForAllValues: prefixes on StringLike and StringEquals, and check every GitHub OIDC sub condition for wildcards that widen the claim beyond the specific repository and ref you meant to trust.

    More generally, on GitHub OIDC to AWS: a trust policy that matches repo:org/name:* trusts every branch, tag, and pull request in that repository, including branches a fork contributor can create. Pin to the ref you mean — repo:org/name:ref:refs/heads/main — or to a named environment, and confirm the audience condition is present and exact.

    If CVE-2026-82857 appears in your scanner: it describes the hulumi project’s own AWS sandbox, not your installation. Upgrading to 1.3.2 will clear the finding because the version range says so, and there is no harm in upgrading. But do not treat it as evidence you were exposed, and do not let it set your expectations for the record next to it.

    If you run a CNA: the version range and the CVSS vector are the two fields that reach automation. When the description names a precondition — a specific principal, an internal account, a non-default deployment — the vector has to reflect it.

    Sourcing note

    Both CVE records were read from the NVD API at services.nvd.nist.gov/rest/json/cves/2.0, which supplied the descriptions quoted above, the CVSS v3.1 and v4.0 vectors and their scoring source ([email protected]), the CWE assignments (CWE-284 and CWE-269), the affected version ranges, and the publication timestamps of August 31, 2026 at 9:17 a.m. UTC. Neither record carried cisaExploitAdd, cisaActionDue, or cisaRequiredAction; neither vulnerability is in the KEV catalog and no federal deadline attaches to either.

    GHSA-q2f7-m237-v562 was read in the GitHub Advisory Database, which gives its publication date as May 15, 2026, its review date as May 21, 2026, a Critical severity, a CVSS v4.0 vector ending VA:N, and “No known CVE.” GHSA-35qr-vx94-m5x3 was read at its repository advisory URL; the corresponding global Advisory Database page returned 404 when checked. The download figure is from the npm registry download-counts API for the period ending August 29, 2026. Both CVSS v4.0 vectors were recomputed locally and both yield 9.3, which is stated above rather than inferred.

    Unresolved: whether VulnCheck intends CVE-2026-82857 to describe a downstream-reachable condition that the description does not convey, and whether the PR:N assignment was deliberate. VulnCheck was not contacted for this story, and its advisory pages were read as published. The maintainer was not contacted. No exploitation of either issue has been reported by anyone, and none is asserted here.

  • Eclipse Theia’s AI agent could write files outside the workspace, and the release that fixed it called the change a breaking API change

    Eclipse Theia’s AI agent could write files outside the workspace, and the release that fixed it called the change a breaking API change

    A path-traversal flaw let Theia’s AI Agent Mode write and delete files anywhere the backend user could reach, and the release that closed it described the change only as a breaking API change.

    What happened

    CVE-2026-82217 entered the National Vulnerability Database on Monday, August 31, 2026 at 9:17 a.m. Central. The Eclipse Foundation is the assigning authority, and the record scores the flaw 8.8 with the CVSS v3.1 vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, classified as CWE-22, path traversal.

    The record’s own description is unusually specific about the mechanism: “In Eclipse Theia versions 1.73.0 up to but not including 1.75.0, the AI ‘Agent Mode’ file-change tools (writeFileContent, suggestFileContent, and the replacement and state helpers) resolved a model-supplied file path without a workspace-containment check.” A crafted relative path, an absolute path, or a tilde-expanded path lets the agent write or delete files outside the workspace. Because the path argument comes from model output, indirect prompt injection can steer it. Agent Mode applies its writes without a confirmation dialog.

    Eclipse’s own vulnerability report, filed on its GitLab as work item 624, is blunter. It is titled “Remote Code Execution via AI Agent-Mode workspace-escape file write,” and it gives the payload directly: “a tool call such as writeFileContent({ path: "../.bashrc", content: "…" }) writes (or deletes) files outside the workspace with the privileges of the Theia backend OS user.” The route from a file write to code execution is the obvious one — shell startup files, or authorized_keys — and the report names both.

    The root cause named in the report is that five tool handlers in file-changeset-functions.ts called resolveRelativePath() directly, skipping the containment helpers that existed alongside it — resolveToUri(), ensureWithinWorkspace(), and ensureAccessible(). The path-normalization logic preserved leading .. segments. The guards were in the codebase. Five call sites did not use them.

    The report credits zenniskayy and gives a report date of July 24, 2026. Its remediation section closes with a line worth reading twice: “Do not rely on the model declining the request.”

    The fix is in 1.75.0, and the release notes do not say so

    Theia 1.75.0 reached npm on August 27, 2026 at 1:52 p.m. UTC, four days before the CVE record existed. It is the fixed version according to the CVE’s affected range, and it is the current release.

    The 1.75.0 changelog does document the change. It documents it as a breaking API change: “[ai-ide] removed WorkspaceFunctionScope.ensureWithinWorkspace(targetUri, workspaceRootUri). Every path-taking AI tool now resolves and checks its argument through WorkspaceFunctionScope.resolveAccessiblePath(pathOrUri), which in addition to the workspace roots accepts locations covered by the ai-features.workspaceFunctions.allowedExternalPaths preference or contributed via the new AccessibleRootContribution.”

    That entry is accurate and it is technically complete. It says nothing about security, a vulnerability, path traversal, or a workspace escape, and it names no CVE. A maintainer reading the 1.75.0 notes on August 27 to decide whether to upgrade would have read that paragraph as a refactor of a path-resolution API — one that broadened access, in fact, since the new resolver accepts allowlisted external paths the old one did not. Nothing in it says that the version they are running lets a prompt-injected agent write to ~/.bashrc.

    The commit the CVE record cites as its reference points the same direction. It is 28da106c254, and its message is “ai-ide: add Memory prompt capability (#17865)” — a feature commit touching seventeen files, adding a workspace memory feature, with the containment change carried inside it.

    Two conflicts in the record

    The Eclipse advisory and the CVE record do not agree on what is affected. The GitLab report names version 1.73.x, noting it was verified against a local commit, and does not name a fixed version at all. The CVE record names 1.73.0 up to but not including 1.75.0. The difference is the entire 1.74 line, released July 31, 2026 and current for most of August. Anyone who read the Eclipse report and concluded that 1.74 was clear read it correctly and was wrong.

    The two also disagree on severity language. Both carry the same 8.8 base score, but the Eclipse report labels that score “Critical.” On the CVSS v3.1 scale, 8.8 is High, which is what NVD’s record says. That gap matters only because a great many triage processes route on the word rather than the number.

    Why it matters

    The interesting thing here is not the path traversal. Unsanitized .. is the oldest bug in the catalog, and a fix that consists of calling the containment helper that was already sitting in the same file is not a research contribution. What is worth attention is where it was found, and what the surrounding design assumed.

    Agent Mode in an IDE is a component whose whole purpose is to take untrusted text — a model’s output, itself shaped by whatever files, issues, dependencies, and documentation the model was fed — and turn it into filesystem writes. That is the feature. Every argument that reaches those tools is attacker-influenceable by construction, in the same way every value in an HTTP request is. The IDE is not being tricked into an unusual state; it is doing exactly its job on input it was never in a position to trust.

    Which is why the Eclipse report’s closing line is the most useful sentence in the whole disclosure. “Do not rely on the model declining the request” is a statement about where the security boundary sits, and it points at the boundary that a lot of agent tooling currently gets wrong. Refusal is an alignment property of a model, not an access-control property of a system. It fails open, it is non-deterministic, and it is the thing an injection attack is specifically built to move. A containment check in resolveAccessiblePath fails closed and does not negotiate.

    The second point is about disclosure practice, and it is a pattern this publication keeps running into from a different angle. Nothing here was hidden. The report is public on Eclipse’s GitLab, the changelog entry is present and honest, the commit is in the tree, and the CVE arrived four days after the fix, which by the standards of the last week is fast. The problem is that none of those artifacts, on the day they appeared, told a user that they were exposed. The changelog described a mechanism, not a risk. The commit described a feature. The CVE, which is the artifact that would have said “you are exposed,” arrived after the upgrade decision had already been made by anyone who was paying attention on August 27.

    For conventional dependencies that lag is tolerable, because most shops upgrade on a schedule and the CVE catches the stragglers. For an AI agent with unconfirmed write access to a developer’s home directory, the population at risk is developer workstations and hosted browser IDEs, the exposure window is however long someone stays on 1.73 or 1.74, and the trigger is a poisoned README in a repository someone asked the agent to look at.

    What to do

    Upgrade Theia to 1.75.0 or later. Anything from 1.73.0 through the 1.74 line is affected per the CVE record, including 1.74 builds that the Eclipse report’s narrower version statement appears to clear.

    The upgrade is a breaking change for anyone who built on the old API: WorkspaceFunctionScope.ensureWithinWorkspace(targetUri, workspaceRootUri) is gone, replaced by resolveAccessiblePath(pathOrUri). If you maintain custom AI tools on top of Theia, that is the call to audit — any handler of your own that resolves a model-supplied path without going through the new resolver has the same bug the five built-in handlers had.

    Review the ai-features.workspaceFunctions.allowedExternalPaths preference after upgrading. The new resolver is an allowlist, and an over-broad entry there reopens the door deliberately.

    For hosted or browser deployments, the report’s defense-in-depth list is worth applying regardless of version: run the agent backend as an unprivileged user, canonicalize paths so symlinks cannot escape, and require explicit confirmation for any write outside the workspace. On unpatched builds where an immediate upgrade is not possible, disabling Agent Mode’s file-change tools removes the exposure, since the vulnerable path is reachable only through them.

    Sourcing note

    Checked: NVD’s API record for CVE-2026-82217, including its publication timestamp, source identifier, CVSS vector, CWE, affected version range, and description; the Eclipse Foundation vulnerability report at work item 624 on gitlab.eclipse.org, which supplied the title, the payload example, the root-cause analysis, the reporter credit, the July 24, 2026 report date, and the remediation guidance quoted above; the Theia CHANGELOG at the v1.75.0 tag; the commit referenced by the CVE record; and npm registry metadata for @theia/core, which supplied the 1.75.0 release timestamp.

    Not resolved: no exploitation has been reported by Eclipse, by the reporter, or by any vendor, and none is claimed here. NVD has not published an independent score, so the 8.8 is the Eclipse Foundation’s. The version-range difference between the Eclipse report and the CVE record is reproduced as found and has not been reconciled by either party; the CVE record’s wider range is the one used above, as it is the more conservative. The Eclipse report does not name a fixed version, so the identification of 1.75.0 as the fix rests on the CVE record’s affected range and the changelog entry, not on a statement from the project that 1.75.0 is a security release. Whether the containment change was deliberately bundled into the Memory feature commit or arrived alongside it is not established from the public record.

  • Eight MCPHub CVEs published in one second today, and the critical one was fixed in May

    Eight MCPHub CVEs published in one second today, and the critical one was fixed in May

    GitHub pushed eight CVE records for the Model Context Protocol hub into the National Vulnerability Database this afternoon, their fixes spread across six releases shipped between April 22 and August 23, and the path-traversal record among them is scored three different ways depending on where you read it.

    What happened

    Eight CVE records for MCPHub entered the National Vulnerability Database on Monday, August 31, 2026. The publication timestamps run from 6:17:19.610 p.m. UTC to 6:17:20.627 p.m. UTC — eight records in a little over one second. Every one carries [email protected] as its source identifier, and every one is still at NVD’s Received status, which means NVD has not analyzed any of them and every score on every record is GitHub’s.

    MCPHub is an open-source project by the developer samanhappy, published to npm as @samanhappy/mcphub. Its own description, repeated at the head of all eight CVE descriptions, is “a unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies.” It is the piece of software an organization puts in front of a fleet of MCP servers so that its agents have one address to talk to.

    Here is the batch, with the fixed release named in each advisory and the date that release actually reached npm:

    CVE Flaw Score (source: GitHub) Fixed in Released to npm
    CVE-2026-79743 Path traversal via MCPB manifest name 6.9 medium (CVSS v4.0) 0.12.13 April 22, 2026
    CVE-2026-79748 Non-admin remote code execution via POST /api/servers 9.9 critical (CVSS v3.1) 0.12.15 May 2, 2026
    CVE-2026-79744 No authorization check on PUT /api/system-config 8.8 high (CVSS v3.1) 1.0.29 August 17, 2026
    CVE-2026-79750 Cross-tenant tool execution 7.7 high (CVSS v3.1) 1.0.30 August 20, 2026
    CVE-2026-79746 Bearer key scoped to one server grants a whole group 8.1 high (CVSS v3.1) 1.0.31 August 22, 2026
    CVE-2026-79745 No role check on prompt and resource writes 7.1 high (CVSS v3.1) 1.0.32 August 23, 2026
    CVE-2026-79747 Server-side request forgery, no egress filtering 7.1 high (CVSS v3.1) 1.0.32 August 23, 2026
    CVE-2026-79749 SSRF guard bypassed by IPv6 transition addresses 7.6 high (CVSS v4.0) 1.0.32 August 23, 2026

    The critical one is the oldest. GHSA-mx89-jjx9-gjr8, titled “Authenticated non-admin user achieves RCE via POST /api/servers (missing authorization on stdio command/args),” states plainly that “There is no authorization check restricting these endpoints to admins, and there is no allowlist/sanitization on the command and args fields.” The impact section says the result is “Remote code execution as the MCPHub process owner from a low-privilege authenticated account. In the official Docker image and in typical npx deployments, that user is root — full host compromise.” The reporter is credited as offset. The fix, version 0.12.15, went to npm on May 2, 2026, almost four months before the CVE record existed.

    The 8.8 record is close behind in reach if not in score. GHSA-4gc8-885f-qj36 says PUT /api/system-config is “protected only by the app-wide authentication middleware and a rate limiter,” so any authenticated non-admin can rewrite the settings that govern the whole instance. Setting skipAuth = true, the advisory notes, “converts the entire dashboard API into an unauthenticated admin surface,” and repointing values such as smartRouting.openaiApiBaseUrl or install.npmRegistry turns the hub into an exfiltration or supply-chain vector. GitHub’s summary calls it “a complete compromise of the instance and every tenant on it.” That advisory was published on August 17, 2026, credited to waydeshi.

    One record does not agree with itself across mirrors. CVE-2026-79743, the MCPB path traversal, is carried by NVD at 6.9 medium with the CVSS v4.0 vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X. GitHub’s own advisory page for GHSA-p3h2-2j4p-p83g gives 7.2 with a different v4.0 vector, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H — privileges required low rather than none, and high integrity and availability impact rather than low and none. GitLab’s mirror of the same advisory publishes it as 8.1 high on CVSS v3.1. Same flaw, same assigning authority, three published severities, and the one that scanners consume from NVD is the only one that rates it medium. The two mirrors also disagree on the publication date: GitHub’s database gives April 19, 2026, GitLab’s gives April 22, 2026, which is the day the fixed release reached npm.

    The batch has no common scale. Six of the eight records carry a CVSS v3.1 vector and nothing else; two — CVE-2026-79743 and CVE-2026-79749 — carry a CVSS v4.0 vector and nothing else. Nothing on the records lets a reader rank the 7.6 against the 7.7, because they are not measured with the same instrument.

    The batch is also incomplete against its source. The repository’s advisory listing carries at least ten entries. Four — a template export that skips the ownership filter, an OAuth authorization server that does not enforce client authentication, cross-group tool execution via a missing group filter, and an open redirect in the OAuth denial flow — have no CVE at all. A keyword search of NVD for MCPHub returns twelve records in total: today’s eight plus four older ones from 2025 and April 2026. The cross-group tool execution advisory is rated high by GitHub and still has no CVE identifier.

    Why it matters

    An MCP hub is a credential concentrator by design. It holds every tenant’s server configuration, the OAuth client secrets, the JWT signing key, and the bearer keys, and it is wired to spawn processes and make outbound requests on behalf of whatever asks it to. That is the job. It means the interesting privilege boundary is not administrator versus anonymous, it is administrator versus ordinary authenticated user — and six of today’s eight records sit exactly on that line, requiring only low privileges.

    In a hub, “ordinary authenticated user” is frequently not a person. It is a service account, a CI job, or an agent holding its own bearer key. An agent that has been steered by a poisoned document or a hostile tool result is an authenticated low-privilege user with a shell, and CVE-2026-79748 turns that into code execution as root on the host in the project’s own container image. The defensive assumption that prompt injection is contained because the agent can only call approved tools does not survive a hub where calling an approved tool and registering a new one are the same permission.

    The timing is the second half of the problem, and it is the part that generalizes past this project. Severity Daily reported on Sunday that VulnCheck published thirteen MCP server CVEs in thirteen seconds. Today it is GitHub, eight records in about one second, for one project. The record for MCP infrastructure is arriving in bursts, months after the code was fixed, in batches large enough that no individual record gets read. An organization that patches on CVE feed learned today about a hole that was closed on May 2 — and if it is still on the 0.12 line, it learned about a hole it may still have.

    That inversion is worth naming. For most software the CVE is the early warning and the patch follows. Here the patch runs months ahead of the record, which makes the CVE feed a poor instrument for knowing whether your agent plumbing is current. Version currency is the better one, and few organizations yet apply it to the components their agents talk through.

    What to do

    Upgrade to 1.0.33, which reached npm on August 30, 2026 and is past every fixed version named in the eight advisories. There is no release that fixes only some of these; the fixes accumulated across 0.12.13, 0.12.15, 1.0.29, 1.0.30, 1.0.31, and 1.0.32.

    If you are pinned to the 0.12 line, know what that leaves you with: 0.12.15 closes the 9.9 and 0.12.13 closes the path traversal, but the 0.12 line carries none of the six August fixes, including the system-config authorization bypass and both SSRF issues.

    Independent of version, check three things. Confirm skipAuth is not set on your instance. Enumerate every non-admin account and bearer key that can reach the hub, including service and agent identities, and treat each as capable of everything described above on an unpatched build. And do not run the hub as root: the 9.9 advisory names the official Docker image and typical npx deployments as the case where the process owner is root, which is what converts a permissions bug into host compromise. Egress filtering in front of the hub limits both SSRF records; the IPv6 bypass in CVE-2026-79749 shows why the application’s own guard is not the place to rely on.

    Sourcing note

    Checked: NVD’s API records for CVE-2026-79743 through CVE-2026-79750, including publication timestamps, source identifiers, vulnerability status, and CVSS vectors; a keyword search of NVD for MCPHub, which returned twelve records; GitHub advisories GHSA-mx89-jjx9-gjr8, GHSA-4gc8-885f-qj36, and GHSA-p3h2-2j4p-p83g; the MCPHub repository’s advisory listing; GitLab’s advisory-database mirror of GHSA-p3h2-2j4p-p83g; and the npm registry metadata for @samanhappy/mcphub, which supplied the release dates for every version named above.

    Not resolved: NVD has not analyzed any of the eight records, so there is no independent score on any of them, and the medium rating on CVE-2026-79743 may change if NVD scores it. GitHub’s advisory page for GHSA-p3h2-2j4p-p83g did not show a CVE identifier at the time of checking even though NVD now maps CVE-2026-79743 to it. The two published dates for that advisory, April 19 and April 22, 2026, are reproduced as found rather than reconciled. No exploitation of any of the eight has been reported by GitHub, the maintainer, or any vendor, and none is claimed here. The four repository advisories without CVE identifiers are described from the repository’s own listing; whether identifiers are pending was not established.

  • Nodemailer’s new critical CVE marks 8.0.3 as fixed. The shipped 8.0.3 still has the vulnerable line

    Nodemailer’s new critical CVE marks 8.0.3 as fixed. The shipped 8.0.3 still has the vulnerable line

    A CVE published this morning rates a five-month-old Nodemailer flaw at 9.8 and names 8.0.3 as the version that fixes it. The 8.0.3 tarball on the npm registry still contains the vulnerable line.

    What happened

    CVE-2026-82854 entered the National Vulnerability Database at 9:17 a.m. UTC on August 31, 2026. VulnCheck is the assigning CNA and supplied both scores on the record: 9.8 CRITICAL under CVSS v3.1 as the primary metric, and 9.3 CRITICAL under CVSS v4.0 as secondary. The weakness is CWE-93. The subject is Nodemailer, the SMTP client that most Node.js applications use to send mail, and which the npm registry recorded at 23,044,621 downloads in the week of August 23 through August 29, 2026.

    The defect itself is real and small. Nodemailer builds the SMTP MAIL FROM command by pushing arguments onto a list. If the calling application supplies its own envelope object carrying a size property, that value was concatenated into the command with no filtering. The upstream advisory shows the line in lib/smtp-connection/index.js:

    args.push(‘SIZE=’ + this._envelope.size);

    Neighboring envelope fields — the addresses, the DSN parameters — pass through sanitizing helpers first. This one did not. A size value containing CRLF characters therefore terminates the MAIL FROM line and begins a new SMTP command. The advisory’s proof of concept injects a recipient:

    size: ‘100\r\nRCPT TO:<[email protected]>’

    The result is a silent extra recipient on mail sent through that transport — a blind carbon copy the sender cannot see.

    None of that is new. The upstream advisory, GHSA-c7w3-x93f-qmm8 in the Nodemailer repository, was published on March 25, 2026, credited to a reporter named esquilichi. The maintainers rated it Low. Their reasoning is the precondition: Nodemailer’s automatic envelope construction never populates size, so an application is exposed only if it builds a custom envelope and lets untrusted input reach that field. VulnCheck’s advisory text agrees, in its own words — “Exploitation requires the application to expose envelope size to attacker-controlled input” — and then scores the flaw at 9.8 with a vector of AV:N/AC:L/PR:N/UI:N, which describes an unauthenticated attacker reaching the defect across a network with no preconditions at all. The gap between the sentence and the vector is the whole disagreement, and it is on the same page.

    The version conflict

    The scoring gap is arguable. The version data is not. Three statements about the fixed version circulate, and they do not agree:

    • The NVD record’s description reads “Nodemailer before 8.0.4 is vulnerable.”
    • The same record’s machine-readable affected range is nodemailer >= 0, < 8.0.3 — that is, 8.0.3 and later are unaffected.
    • VulnCheck’s advisory is titled “Nodemailer before 8.0.3 SMTP Command Injection via envelope.size” while its body says 8.0.4.

    The upstream GitHub advisory is the origin of the split, because it contains both halves. Its “Affected versions” field reads <8.0.3. Its “Patched versions” field reads 8.0.4. Those two statements are mutually exclusive, and they leave 8.0.3 in neither category. Downstream, the prose inherited one half and the CPE range inherited the other.

    We resolved it by reading the published code rather than the paperwork. Nodemailer 8.0.3 was published to npm on March 18, 2026; 8.0.4 was published on March 25, 2026, the same day the advisory went out. Unpacking all three tarballs from the registry and reading lib/smtp-connection/index.js:

    In 8.0.2, at line 1210, and in 8.0.3, at line 1162, the code is byte-for-byte identical:

    args.push(‘SIZE=’ + this._envelope.size);

    In 8.0.4, at line 1164, it is not:

    const sizeValue = Number(this._envelope.size) || 0;
    if (sizeValue > 0) {
        args.push(‘SIZE=’ + sizeValue);
    }

    The fix is a numeric coercion, and it lands in 8.0.4. Version 8.0.3 carries the vulnerable line. The vendor’s prose is correct; the machine-readable range that scanners consume is wrong by one patch release, in the direction that marks a vulnerable version clean.

    Why it matters

    Almost nobody reads a CVE description. Software composition analysis tools read the CPE range, compare it against a lockfile, and emit a verdict. That is the point of publishing a machine-readable range, and it is why an error there behaves differently from an error in prose: it does not produce a confused engineer, it produces a confident green check.

    Consider the two populations this record creates. An organization pinned to 8.0.2 gets a critical finding, upgrades, and is fine — the bad range still catches them. An organization pinned to 8.0.3 gets nothing. Their scanner reports the dependency as remediated, because 8.0.3 is outside the declared affected range, and the code they are running is the same code that 8.0.2 was running. They will not look again, because from their tooling’s point of view there is nothing to look at. A false negative is worse than a false positive precisely because it generates no work item, no ticket, and no second pass.

    How large that second population is depends on how many teams landed on 8.0.3 and stopped. The window was one week — March 18 to March 25 — and 8.0.3 was the current release for all of it. Any lockfile regenerated in that week pinned the version this CVE now describes as safe. We cannot size that population and will not guess at it; what we can say is that the registry moves more than 23 million copies of this package a week, and the range is wrong for exactly one version in it.

    There is a second, slower problem in the scoring. A CVSS 9.8 on a package with 23 million weekly downloads is a fire alarm in a very large building. When the alarm turns out to describe a defect that requires the application to have hand-built an envelope object and piped user input into its size field, the people who evacuated remember. Severity inflation is not a victimless drafting choice; it is how a scanner’s output stops being read. The maintainers said Low and explained why. The CNA said Critical and, in the same advisory, wrote down the precondition that makes Critical hard to defend. Both numbers are now attached to the same identifier, and a downstream consumer has no principled way to choose between them.

    This publication has now recorded four versions of the same failure mode in a week: an advisory whose stated preconditions contradict what its own researchers told reporters, a patched WordPress flaw whose fixing release is absent from the changelog, a CVSS 10.0 remote code execution described by its vendor as “additional hardening,” and now a fixed-version range that clears a version the vendor never claimed to have fixed. In each case the underlying engineering was fine and the record describing it was not. The defect gets fixed in an afternoon. The wrong number attached to it propagates for years, into scanners, dashboards, and compliance attestations that no human will ever reread.

    What to do

    Upgrade to Nodemailer 8.0.4 or later, and do not treat 8.0.3 as remediated regardless of what a scanner reports. The current release is 9.1.0, published August 31, 2026.

    Check for the pin specifically. npm ls nodemailer resolves the installed version including transitive copies; grep -r '"nodemailer"' package-lock.json finds pins a top-level check misses. The version to look for is exactly 8.0.3.

    If you cannot upgrade immediately, the precondition is your control. Search your codebase for calls to sendMail() that pass a custom envelope object, and confirm that no untrusted input reaches its size property. Applications that let Nodemailer build the envelope automatically are not exposed to this defect at all.

    If you maintain a vulnerability database, an SBOM pipeline, or an internal allowlist that ingested this CVE today, correct the range to < 8.0.4 by hand. The upstream data will stay wrong until someone amends it.

    Note separately that the 9.0.x line has carried related fixes this year — 9.0.2 on June 29 rejecting CRLF in HTTP proxy CONNECT destinations, and 9.0.5 on August 7 keeping control characters out of header values. If you are on 8.x for reasons other than inertia, that is worth revisiting.

    Sourcing note

    Checked against primary sources. CVE-2026-82854 was read from the NVD API at services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-82854, which gave the publication timestamp, the CNA identifier, both CVSS metrics and their source, CWE-93, and the affected-version data. The upstream advisory GHSA-c7w3-x93f-qmm8 was read in the Nodemailer repository for the Low rating, the affected and patched version fields, the vulnerable line, the proof of concept, and the credit. VulnCheck’s advisory page gave its title, its CVSS v4.0 vector, its range of “nodemailer >= 0, < 8.0.3,” and its precondition sentence.

    The version finding does not rest on any of those. We downloaded the 8.0.2, 8.0.3, and 8.0.4 tarballs from registry.npmjs.org, extracted them, and read lib/smtp-connection/index.js in each. That comparison is reproducible by anyone in under a minute and is the basis for the statement that 8.0.3 is unfixed. Publication dates for those versions come from the registry’s own time object. The download figure of 23,044,621 is the npm downloads API point value for the week of August 23 through August 29, 2026.

    Unresolved: whether the <8.0.3 range in the upstream advisory is a typo or a claim that a partial fix landed in 8.0.3 — though the identical code in 8.0.2 and 8.0.3 makes the latter hard to sustain. We found no public discussion of the discrepancy, and neither the maintainers nor VulnCheck has published a correction as of this writing. No exploitation of this flaw has been reported by anyone, and it is not in CISA’s Known Exploited Vulnerabilities catalog. CISA’s website returns 403 to automated requests, so KEV status was checked against the cisagov/kev-data JSON mirror on GitHub, catalog version 2026.08.27.