CVE Feed

Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)

Branch Protection Bypass via PR Retargeting Preserves Stale `official` Approval Flag

Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access

Repository Visibility Manipulation via Git Push Options

ParseAcceptLanguage quadratic-time DoS via Locale middleware on unauthenticated requests

Gitea LFS Deploy-Key Privilege Escalation

Private Repository Metadata Remains Accessible After Access Revocation

Team-repository linking endpoint bypasses the RepoAdminChangeTeamAccess organization setting

Missing Authorization and Authorization Bypass Through User-Controlled Key and Incorrect Permission Assignment for Critical Resource and Exposure of Sensitive Information to an Unauthorized Actor in code.gitea.io/gitea

Public-only API token restriction is not enforced on team API routes

Public-Only Personal access tokens scope bypass in Organization and Permission Endpoints

Release attachment extension allowlist bypass via web release edit form (variant of CVE-2025-68939)

Private org member list leaked via /members API endpoint — incomplete fix for PR #38145

OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation)

Local File Inclusion via file:// URI in Migration Restore

REST API exposes organization membership of private organizations to public

Fork-PR Actions task can read a third private repository via the collaborative-owner branch (missing fork-PR guard)

Two SSRF findings in Gitea 1.26.2

Cross-Repo Information Disclosure via Org-Level Actions Run/Job APIs

Repository Migration Follows Git HTTP Redirects After URL Allow/Block Validation, Enabling Internal Git Repository Exfiltration

Cross-repository issue/comment attachment re-linking can expose private attachment content

Denial of Service (CPU & Memory Exhaustion) via O(N^2) String Concatenation in Debian Package Upload

Gitea Remember-Me Token Theft Not Invalidating Attacker Session

Gitea SSH Key Parser Denial of Service

Privilege Escalation via Access Token Scope Escalation in API

Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118

OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)

Email Management API Bypasses ManageCredentials Feature Restrictions

Null Pointer Dereference in AddTime API Causes Authenticated Denial of Service

OIDC userinfo Endpoint Returns Identity Claims Without Enforcing API Token Scopes

CVE-2026-55402 is an out of bounds read vulnerability in Secure Access servers prior to version 14.57. Attackers with an ‘in the middle’ position can send specially crafted data to a server causing a persistent denial of service.

Internal API HTTP client hardcodes InsecureSkipVerify:true with no config override (CWE-295)

RSS/Atom feed handlers bypass API-token scope & public-only confinement (incomplete fix of #37698)

Denial of Service via Unbounded io.ReadAll in NPM Package Tag Endpoint

Public-only tokens bypass private-resource restrictions on `/api/v1/user` self routes

The GET /api/v1/user/actions/runners/registration-token endpoint (and its owner- and repository-level equivalents) creates a new runner registration token if none exists, yet the API scope middleware classifies it as read-only because it is a GET request. A holder of a leaked read:user-scoped token can therefore mint a registration token and register a malicious Actions runner that executes workflow jobs with access to repository secrets and source code.

Blind SSRF in OAuth2 avatar synchronization via unvalidated OIDC picture claim

Form::Processor::Field::HtmlArea versions from 0.06 through 1.162360 for Perl allow attacker selected method dispatch and resource exhaustion via an HTML::Tidy diagnostic that validate passes to add_error as a Locale::Maketext template. validate runs HTML::Tidy over the submitted markup and passes each resulting message to add_error as its first argument, which add_error hands to the language handle as the Locale::Maketext message key. The default handle's lexicon sets `_AUTO`, so a message that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. Tidy diagnostics quote the offending attribute name or value, so a bracket group in the submitted markup reaches the template position, where the first token of the group names a method called on the language handle and the remaining tokens are its arguments. A group such as `[0]` makes the compile croak, and neither the field nor the handle catches it, so the exception leaves validate. `[sprintf,%2000000000d,7]` reaches CORE::sprintf with an attacker chosen field width. One submission of crafted markup to an HtmlArea field throws an unhandled exception out of form validation or allocates an arbitrary amount of memory, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The other field types pass fixed templates with the submitted value in an argument slot, where it stays inert, and are unaffected.

Data::MuForm::Localizer versions through 0.05 for Perl execute Perl from a message catalog header, reached at an arbitrary path because load_lexicon interpolates the language attribute into the catalog filename. load_lexicon builds the catalog path by appending `Messages/$lang.po` to the directory holding Localizer.pm, where $lang is the language attribute, with no check that it names a bare locale tag. A value holding `../` segments walks out of the message directory, so any readable path with a `.po` suffix is loaded. While parsing the catalog, extract_header_msgstr takes the `Plural-Forms:` header, prefixes `$` to the bare words nplurals, plural and n, and passes the rest verbatim into a string that is evaluated: the nplurals form evaluates the header expression immediately, and the plural_code form compiles it into a subroutine whose body runs when a plural message is localized. A header of `nplurals=2; plural=(system('...'),0);` therefore runs that command as the catalog loads. The evaluation inherits strict, so an expression that assigns to an undeclared variable fails to compile, while one built from calls alone does not. An application that sets the language attribute from request data, an Accept-Language header or a locale parameter, and an attacker who can place a file with a `.po` suffix and chosen contents at a readable path, together give code execution as the application user. The message expansion path is not affected: expand_named substitutes only the placeholder names the caller supplies, and _mangle_value returns the value unchanged.

HTML::FormHandler versions before 0.410000 for Perl allow attacker selected method dispatch and resource exhaustion because _apply_actions and add_error use error message text built from request data as a Locale::Maketext bracket notation template. add_error hands its first argument to the language handle as the Locale::Maketext message key, and the default handle's lexicon sets `_AUTO`, so a string that is not a lexicon entry is compiled as a bracket notation template instead of being looked up. In a bracket group the first token names a method called on the language handle and the remaining tokens are its arguments. Three kinds of text the library did not author reach that position. _apply_actions installs a `$SIG{__WARN__}` handler that stores the warning text in `$error_message`, and a captured warning survives a successful action, so a field carrying a numeric transform turns `Argument "[sprintf,%50000000d,0]" isn't numeric` into the template; a warning quotes the submitted value verbatim, so the group is well formed and dispatches. `$error_message ||= $tobj->validate($new_value)` takes a type constraint's own failure message, which renders the rejected value through a partial dumper in bracket and comma form (Devel::PartialDump when Moose can load it, Type::Tiny's own dumper always), so a field with `apply => [ Str ]` given a parameter sent more than once, which arrives as an array, gets `Reference ["a","b"] did not pass type constraint "Str"` as its template, from a request that carries no bracket character of its own. A coercion or transform exception reaches it the same way. Beyond those, a validator whose message contains the field value puts that value in the template directly, and add_error replaces the message list with the contents of an arrayref first argument (`@message = @{$message[0]} if ref $message[0] eq 'ARRAY'`), so a value arriving as an array fills the argument slots from the same request as well. A malformed group such as `[0]` makes the compile croak, and HTML::FormHandler::I18N::maketext and add_error each re-raise that as a die, so process() throws. A well formed group naming sprintf reaches CORE::sprintf with an attacker chosen field width. Any caller that applies a type constraint or a transform to an untrusted field, or whose validator passes an untrusted field value to add_error, can be made to throw an unhandled exception out of process(), or to allocate an arbitrary amount of memory in one request, and an application whose language handle subclass defines side effecting public methods makes those callable with attacker chosen arguments. The dumped type constraint message is bounded to the exception, because both dumpers quote non-numeric elements so the method slot is never an attacker chosen name. The built-in messages pass fixed templates with the value in an argument slot, where it stays inert, and the built-in field types attach explicit message callbacks, so neither is affected.