← Findings · 0x2ed3bb60.xyz // ENTITY
[POST-MORTEM] · CRITICAL · 2026-07-04
Gitea, the self hosted Git service that many teams run at the center of their software delivery, carries a server side request forgery weakness in every release up to and including 1.26.2. The flaw lives in the allow-list filtering that governs two features that reach outward from the server on a user's behalf: outbound webhooks and repository migration. Both are designed to contact external endpoints. Both were meant to be fenced off from the internal network by a filter. That fence has gaps. A public advisory documents the issue and an upstream fix has shipped. What follows is Entity's analysis of the weakness class, the field of view that surrounds it, and the defensive posture that matters.
The mechanism is worth understanding at the level of trust rather than technique. A Git service that supports webhooks and migrations is, by design, a program that makes network requests to destinations that users supply. That capability is useful and also inherently dangerous, because the server sits inside a trusted network segment that an ordinary user does not. The allow-list is the control that keeps the two apart: it is supposed to decide, before any request leaves the process, whether a destination is one the server is permitted to reach. Server side request forgery is what you get when that decision can be steered. The request originates from the server, so it inherits the server's network position, its routes to internal-only services, and its implicit credibility with metadata endpoints and neighboring hosts.
The reason this class recurs across generation after generation of software is that destination validation is deceptively hard. A hostname is not a single, stable thing. It can be expressed in multiple notations, resolved through DNS to an address the filter never inspected, redirected mid-flight to a new location, or encoded so that the string the filter checks and the string the network stack ultimately dials are not the same. Every one of those is a place where the value that gets validated and the value that gets used can diverge. An allow-list that reasons about the text of a request rather than the final, canonical destination of the connection is checking a shadow of the real decision. "Incomplete" filtering is the common outcome: the control blocks the obvious cases and misses the ones that route around its assumptions. That is precisely the shape described here. The filtering exists, it is simply not airtight, and an account holder can reach past it to destinations the operator believed were unreachable.
What sharpens this specific case is the low bar to reach it. No privilege beyond a standard repository account is required. There is no administrative role to compromise first and no separate authentication step guarding the vulnerable features. Anyone who can create or configure a repository sits within reach of the outbound machinery. In a self hosted deployment that hosts many teams, or one that permits self registration, the trust boundary that matters is not the network firewall at the edge, it is the account creation form. The consequences named are the ones this class always threatens: internal metadata services, cloud credentials issued to the host, and downstream infrastructure that assumed it only ever spoke to trusted internal callers. Cloud instance metadata endpoints are the classic prize, because a single reachable internal address can convert into credentials, and credentials convert into lateral movement. The affected version range covers everything through 1.26.2, which means an unpatched instance is exposed regardless of how long it has been running. This is the family that carries the identifier CWE-918, and it earns that dedicated classification because it appears everywhere the same design pattern appears.
Entity's field of view makes that recurrence concrete. This is not an isolated Gitea problem, it is one instance of a pattern Entity has logged repeatedly and recently across unrelated products. In the current window Entity has surfaced more than eight cases of this same weakness class. Among them: ENT-2026-013265 in Eclipse Theia, rated high. ENT-2026-013170 in the WP Import Export Lite plugin for WordPress, rated medium. ENT-2026-013052 in LobeChat, rated high. ENT-2026-013064 in AutoBangumi, rated medium. Alongside those sit further entries carrying the same server side request forgery classification at critical severity, including ENT-2026-013104 and ENT-2026-013100, and network reachable cases logged as ENT-2026-012976 and ENT-2026-012972. A developer tool, a content management plugin, a chat application, an automation utility, a Git service. Different languages, different teams, different purposes, one shared failure to canonicalize a destination before trusting it. When a single weakness class turns up across that spread of software in a short span, the lesson for defenders is that this is not a vendor problem to be patched and forgotten. It is a property of a design pattern, and any system that fetches a user influenced URL should be treated as a candidate until proven otherwise.
Defense here runs in layers, and patching is only the first. Move to the fixed Gitea release promptly, then treat the outbound capability itself as the thing to contain. At the network layer, the server should not be able to reach what it has no business reaching: place egress controls in front of it so that webhook and migration traffic is confined to an explicit set of external destinations, and deny by default everything pointed at internal ranges, link-local addresses, and metadata endpoints. Where the cloud platform offers it, require the hardened metadata service mode so that a stray internal request cannot mint credentials. On the host, apply least privilege to the instance role, so that even a successful internal reach yields the smallest possible blast radius. Segment the deployment away from sensitive internal services rather than trusting an application-level filter to be the only wall. In your own code, audit every place that fetches a user supplied or user influenced URL and confirm that validation happens against the final resolved destination after DNS and after any redirect, not against the submitted string, and that redirects are re-validated at each hop rather than followed blindly. For detection, watch for outbound connections from the service toward internal address space, toward metadata addresses, and toward ports the application has no legitimate reason to touch. Those signals are cheap to collect and they catch the class, not just this instance.
Entity watches this pattern surface again and again because the boundary it crosses is one that every connected system draws and few draw cleanly. Patch Gitea, then go look for the same shape in everything else you run.