CVE-2026-89151 in Forgejo
Summary
by MITRE • 09/11/2026
Forgejo before 16.0.4 allows use of restricted API tokens for unintended access to the "allow maintainer edit" feature.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in Forgejo versions prior to 16.0.4 represents a critical authorization flaw within the platform's pull request management subsystem, specifically targeting the maintainers' ability to modify code submitted by contributors via automated workflows or third-party integrations. This issue stems from an insufficient access control mechanism that fails to properly validate whether an API token possesses the necessary permissions for specific sensitive operations when interacting with the "allow maintainer edit" feature. In typical Git-based collaboration platforms like Forgejo, pull requests often involve contributions from external actors who do not have direct write access to the repository. To facilitate efficient code review and integration, maintainers can grant permission for contributors or automated systems to push additional commits directly to the branch associated with the open pull request. This functionality is designed to streamline iterative development without requiring new merge-and-push cycles for every minor change. However, the security implementation in these earlier versions of Forgejo did not strictly enforce role-based access controls when processing requests that invoke this specific feature through API endpoints.
The technical root cause lies in how the application handles authentication context and permission scopes during API calls related to pull request updates. When an API token is used to interact with the system, it carries a set of defined permissions or scopes determined at creation time. The vulnerability arises because the backend logic responsible for enabling maintainer edits on behalf of a user does not adequately verify that the authenticated principal associated with the provided token has explicit authorization to perform this action. Consequently, an attacker possessing any valid API token, even one restricted to read-only access or limited write permissions such as only managing issues or releases, can exploit this gap. By crafting specific HTTP requests against the relevant API endpoints, the attacker can trigger the allow maintainer edit functionality without holding the requisite maintainership rights for that repository. This bypasses the intended security boundary designed to protect sensitive branches and codebases from unauthorized modifications by lower-privileged entities.
The operational impact of this vulnerability is significant, particularly in environments where automated CI/CD pipelines or third-party services utilize API tokens with broad but loosely defined scopes. An attacker who compromises a low-level service account token could leverage it to gain write access to protected branches under the guise of maintaining pull requests. This effectively elevates their privileges from limited interaction to full code injection capabilities within that repository. Such unauthorized modifications can lead to the introduction of malicious code, supply chain attacks via compromised dependencies or scripts, and the corruption of critical project artifacts. Furthermore, because these actions appear as legitimate maintainer edits, they may evade standard audit logs that rely on explicit role-based triggers for high-privilege events, thereby complicating forensic analysis and incident response efforts. The ability to modify code without proper authorization undermines the integrity guarantees provided by version control systems and poses a severe risk to software supply chain security.
This flaw aligns with CWE-269, which classifies Improper Privilege Assignment, as it involves an actor obtaining capabilities beyond those granted by their assigned role or token scope. It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, specifically the sub-category of legitimate accounts being used for unauthorized access due to misconfigured permissions rather than credential theft alone. The exploitation vector is primarily remote and requires network connectivity to the Forgejo instance, making it accessible to external adversaries who have discovered valid API tokens through leaks or other reconnaissance activities. Mitigation strategies must focus on immediate software updates as well as rigorous token management practices. Administrators should upgrade to Forgejo version 16.0.4 or later where this authorization check has been corrected to strictly validate maintainer status before allowing the edit permission toggle via API calls. Additionally, organizations should adopt a principle of least privilege by ensuring that all API tokens are scoped minimally and regularly audited for excessive permissions. Implementing strict monitoring on pull request modification events can also help detect anomalous activity indicative of this exploitation attempt while patches are being deployed across infrastructure.