@e2e-dev/github EUVD-2026-104928

Exploitation requires (1) a project using @e2e-dev/github before 0.4.1 to post CI reports on pull requests, and (2) the attacker having the ability to post a comment on the target pull request (any GitHub user on a public repository, or a collaborator on a private one). The attacker must place the tool's report marker as the first line of a comment; the description states this marker is predictable, so no secret value need be guessed. The vulnerable path is the missing author check in findComment/upsertComment in post.ts, which matches any marker-bearing comment regardless of who wrote it. Limiting factors: the CI workflow must actually run to create or update the report (passive user interaction, UI:P); impact is confined to the integrity of CI report comments (cannot read secrets or run code); and version 0.4.1 fully remediates by verifying the comment author against the token's account (GET /user), falling back to bot-only matching for installation tokens.

This is a medium-severity authorization flaw (CVSS 4.0 base 5.1) whose real-world risk is moderate and narrowly scoped rather than urgent. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) shows network reach and low complexity but requires low privileges (PR:L - i.e. an authenticated GitHub account able to comment on the PR) and passive user interaction (the CI workflow must run to post/edit the report). Impact is integrity-only and limited (VI:L): an attacker can falsify or suppress CI test reports, but there is no confidentiality or availability impact and no scope change (SC/SI/SA:N), so this cannot by itself execute code or exfiltrate data. No EPSS score, no SSVC decision data, and no KEV entry are present in the input, and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis.' The root cause is independently corroborated by the vendor source diff (findComment/upsertComment matched any marker-bearing comment regardless of author). The practical danger is a trust/supply-chain concern - a malicious contributor could mask failing tests to get a bad PR merged - but it is confined to repositories using @e2e-dev/github before 0.4.1 and requires comment access to the target PR, so this is a 'patch in normal cadence' issue, not a drop-everything emergency.

An attacker who can comment on a target pull request posts a comment whose first line is the tool's predictable report marker. Because the reporter never checks the comment's author, the CI runner treats the attacker's comment as its own report comment, letting the attacker edit reported failures into passes or suppress the genuine report so a failing or malicious PR appears green. No public exploit code is referenced in the available data.