CVE-2026-113357 in e2e
Summary
by MITRE • 10/20/2026
@e2e-dev/github before 0.4.1 contains an improper authorization vulnerability that allows pull request commenters to hijack CI test reports by posting comments with the predictable marker. Because findComment and upsertComment in post.ts never check the comment author, attackers can receive results in their own comment and edit failures to passes, or suppress genuine reports entirely.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified within @e2e-dev/github versions prior to 0.4.1 represents a critical failure in access control mechanisms specifically affecting the integration of continuous integration test reporting with GitHub pull requests. This flaw stems from an improper authorization logic where the software fails to validate whether the user posting or modifying comments on a pull request possesses the necessary privileges to interact with automated CI status reports. In secure systems, actions that modify system state or display sensitive operational data must be strictly bound to authorized entities, typically limited to trusted service accounts or users with specific repository permissions. Here, the absence of such checks allows any user who can comment on a pull request to interfere with the integrity of the test reporting pipeline.
The technical root cause lies in the implementation details of the post.ts module, specifically within the findComment and upsertComment functions. These functions are responsible for locating existing CI status comments or creating new ones based on test outcomes. However, they do not verify the identity or authorization level of the comment author before allowing modifications to these specific automated messages. This oversight creates a predictable attack vector where an attacker can post a comment containing a predefined marker string that triggers the system's update mechanism. Because the system assumes any comment with this marker is legitimate and authorized, it proceeds to process the request without validating if the requester should have control over CI report data.
The operational impact of this vulnerability is severe, as it enables pull request commenters to hijack CI test reports through social engineering or direct manipulation. An attacker can post a comment designed to trigger the upsertComment function, effectively allowing them to alter the displayed status of tests. This capability allows malicious actors to change failure statuses to passes, thereby masking broken builds and misleading developers into merging insecure code. Conversely, attackers can also suppress genuine reports entirely by manipulating or deleting these comments, creating confusion in the development workflow and potentially hiding evidence of security regressions or functional defects introduced during the commit process.
This vulnerability aligns with CWE-269, Improper Privilege Control, as it involves a failure to enforce proper authorization for specific actions within an application context. Furthermore, from a threat modeling perspective using the MITRE ATT&CK framework, this behavior is consistent with techniques related to Defense Evasion and Impact categories, specifically those involving manipulation of system logs or status indicators to hide malicious activity or deceive stakeholders. The predictability of the marker used in comments further exacerbates the risk by reducing the complexity required for an attacker to exploit the flaw successfully.
To mitigate this vulnerability, it is imperative to upgrade @e2e-dev/github to version 0.4.1 or later where these authorization checks have been implemented. In addition to upgrading, developers should enforce strict input validation and context-aware access control on all functions that interact with CI status comments. Implementing a whitelist of authorized service accounts for automated comment updates is recommended over relying solely on user-provided markers. Additionally, integrating GitHub's native permission models ensures that only users or services with write access to the repository can modify critical pipeline statuses, thereby restoring trust in the integrity of continuous integration reports and preventing unauthorized manipulation of test outcomes.