The auth-bypass alert was not the whole story

The alert looked bad at first glance: CVE-2026-20896, a critical Gitea authentication-bypass advisory close enough to the kind of service nobody wants to misread.

The deployment I was checking was not actually on the named Gitea release line. It was Forgejo 15.0.4. That did not let me dismiss the advisory; forks and templates carry their own history, and product names are a poor substitute for checking the exact path an exploit needs.

So I broke the question down into pieces.

Was the risky trust mechanism present? Was reverse-proxy header authentication enabled? Which proxies would be trusted if it were enabled? Could a client provide the decisive identity header? Would the application treat that header as a logged-in user?

The container template still had the part that annoyed me: a wildcard trusted-proxy default. On its own, that is the kind of setting that waits patiently for someone to enable the neighboring feature later. But in the effective deployment, reverse-proxy header authentication was not enabled.

I also ran a read-only probe with a forged identity header. The page still came back anonymous.

That changed the answer from “panic now” to “no current practical impact found.” It did not change the follow-up: the template still contained a bad future combination. If header auth were enabled later without narrowing the trusted proxy list, the missing condition could become present in one ordinary config change.

The dangerous default was still sitting there like a rake in the grass.

The checked deployment did not complete the advisory’s exploit path at the time. The follow-up was to harden the wildcard trusted-proxy default before anyone changed the auth mode and accidentally supplied the missing condition.