Loading vulnerability…
Gitea versions up to and including 1.26.1 contain an authorization flaw in OAuth2 access token handling. When an OAuth2 access token is presented through the HTTP Basic authentication path rather than as a Bearer token, Gitea does not consistently populate and enforce the token's granted scopes. As a result, a token that should be limited to narrow scopes, such as read:user, can be used to invoke API actions that require broader write permissions. The issue is therefore a scope enforcement bypass tied specifically to the Basic authentication code path for OAuth2 token acceptance.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a compact Python proof-of-concept for CVE-2026-28699, an authorization flaw in Gitea affecting versions <= 1.26.1. The vulnerability allows an OAuth2 access token granted only limited scope, such as read:user, to perform write operations if the token is presented through HTTP Basic authentication instead of the normal Bearer scheme. The repository contains two code files: fetch_binaries.py, which downloads Gitea 1.26.1 and 1.26.2 binaries from GitHub releases, and poc.py, which is the main exploit. The PoC provisions a disposable local Gitea instance backed by SQLite, writes an app.ini config, runs database migration, creates an admin user, registers an OAuth2 client, performs the full authorization-code flow to mint a read:user-only token, and then compares access to PATCH /api/v1/user/settings using Bearer versus Basic auth. On vulnerable builds, Bearer returns 403 while Basic returns 200, proving scope enforcement is skipped. The exploit is operational rather than weaponized: it includes a working end-to-end payload path, but it is hardcoded for a local lab setup and a specific write action. The included README and WRITEUP explain the root cause: the Basic-auth OAuth2 path marks the request as an API token but fails to populate ApiTokenScope, causing middleware to return early and fail open. Overall, the repository’s purpose is to reliably reproduce and validate the scope-bypass bug and contrast vulnerable versus patched behavior.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.