Severity Daily

IT and AI security incidents, checked against the primary source

Tag: GitHub

  • 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.

  • 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.