Viena HTTP galvene pietiek, lai kļūtu par Gitea administratoru. Kļūda CVE-2026-20896 (CVSS 9.8) ļauj jebkuram, kas sasniedz Gitea konteinera portu, nosūtīt galveni X-WEBAUTH-USER: gitea_admin un pieteikties kā šis lietotājs. Bez paroles, bez marķiera.
Vaina nav pašā Gitea kodā, bet oficiālajā Docker attēlā. Tas piegādā app.ini veidni, kurā jau ierakstīts REVERSE_PROXY_TRUSTED_PROXIES = *. Kad administrators ieslēdz ENABLE_REVERSE_PROXY_AUTHENTICATION = true, lai Gitea saliktu aiz autentificējoša reversā starpniekservera, zvaigznīte nozīmē, ka Gitea uzticas jebkurai izejas adresei, nevis tikai starpniekserverim.
Kā galvene pārvēršas piekļuvē
Reversā starpniekservera autentifikācija paredzēta tādām uzstādnēm, kur priekšā stāv proxy, kas pats pārbauda lietotāju un padod tā vārdu galvenē X-WEBAUTH-USER. Gitea nolasa šo galveni un pieņem, ka lietotājs jau ir pieteicies. Tas ir droši tikai tad, ja Gitea pieņem galveni no viena zināma proxy. Ar * šis nosacījums pazūd.
Ja kāds process sasniedz konteinera HTTP portu tieši, apejot starpniekserveri, tas var uzdoties par jebkuru lietotāju ar zināmu vai uzminamu pieteikšanās vārdu. Konti admin un gitea_admin ir pirmie mērķi. Gitea uzturētājs to formulēja tieši: tas, kurš aizsniedz portu ārpus proxy, var uzdoties par jebkuru kontu ar minamu vārdu.
Zvaigznīte attēlā parādījās ērtības pēc. Ar to Gitea konteiners uzreiz strādāja aiz jebkura docker-compose tīklā palaista starpniekservera, un lietotājam nekas nebija jāpielāgo. Šo noklusējumu mantoja katrs, kas kopēja gatavo attēlu un ieslēdza reversā proxy autentifikāciju, nepārrakstot app.ini. Ērtais noklusējums palika attēlā gadiem, līdz kļuva par ievainojamību.
Sysdig pētnieks Michael Clark uzbrukumu aprakstīja trijos vārdos.
“No password. No token. One header.” — Michael Clark, Sysdig
Ko uzbrucējs iegūst
Administratora konts Gitea nozīmē piekļuvi visiem repozitorijiem instancē, arī privātajiem. Tur mēdz glabāties izvietošanas atslēgas, CI marķieri, .env faili ar datubāzes parolēm un slepenie API atslēgu virknējumi. Ar administratora tiesībām uzbrucējs var pievienot SSH atslēgas, izveidot jaunus lietotājus vai mainīt webhook adreses, lai izvadītu datus. Tā kā piekļuve nāk caur likumīgu galveni, parastie pieteikšanās žurnāli neko aizdomīgu neuzrāda.
Vai tevi tas skar
Bīstama ir tieši abu iestatījumu kombinācija. Ja tu Gitea Docker attēlu palaid bez reversā starpniekservera autentifikācijas, tad ENABLE_REVERSE_PROXY_AUTHENTICATION paliek izslēgts un X-WEBAUTH-USER galvene tiek ignorēta. Šādu instanci kļūda neskar, pat ja izmanto veco attēlu.
Riskā ir tie, kas apzināti sasaistīja Gitea ar autentificējošu proxy, piemēram, Authelia vai Authentik, un paļāvās uz attēla noklusējuma app.ini. Tieši tur zvaigznīte palika neaiztikta, un tieši tur galvenei sāk uzticēties. Atver konteinera app.ini sadaļu [security] un pārliecinies, kāda tur vērtība ierakstīta.
Kas jau notiek internetā
Sysdig sensori pirmo reālo uzbrukumu pamanīja 13 dienas pēc drošības brīdinājuma publicēšanas. Tas nāca no VPN izejas mezgla skenera, kas ieguva piekļuvi automātiski, meklējot atvērtus Gitea portus. Publiski sasniedzamu Gitea instanču internetā ir aptuveni 6200, lai gan cik no tām palaistas ar ievainojamo konfigurāciju, nav zināms.
Skenēšana pēc X-WEBAUTH-USER galvenes ir lēta un automatizējama, tāpēc mērķis nav konkrēts uzņēmums, bet ikviens, kas atbild. Tieši tāpēc BleepingComputer un citi ziņoja par to kā par masveida, nevis mērķētu darbību.
Ko labo 1.26.3 un 1.26.4
Kļūda skar oficiālos Docker attēlus līdz versijai 1.26.2 ieskaitot. Versija 1.26.3 izņēma * noklusējumu, un reversā starpniekservera autentifikācija tagad ir jāieslēdz administratoram ar roku. Tā pati versija aizvēra 11 drošības kļūdas, tostarp SSRF aizsardzības apiešanu webhook un migrāciju kodā (CVE-2026-22874), TOTP koda atkārtotu izmantošanu (CVE-2026-20779) un zaru rakstīšanas tiesību eskalāciju (CVE-2026-27775).
Versija 1.26.4 pievienoja vēl vienu labojumu, kas neļauj OAuth2 pieteikšanās atzvanā automātiski atkārtoti aktivizēt atslēgtus lietotājus. Gitea komanda iesaka jaunināt tieši uz 1.26.4, arī tiem, kas jau ir uz 1.26.3.
Ko darīt tagad
Jaunini uz 1.26.4. Ja to izdarīt uzreiz nevar, atver app.ini un nomaini REVERSE_PROXY_TRUSTED_PROXIES = * uz proxy konkrēto IP adresi. Ja reversā starpniekservera autentifikācija nav vajadzīga, izslēdz ENABLE_REVERSE_PROXY_AUTHENTICATION. Pārbaudi tīmekļa servera un konteinera žurnālus pēc pieprasījumiem ar galveni X-WEBAUTH-USER, kas nenāk no tava starpniekservera adreses.
Ja instance bijusi sasniedzama internetā ar ievainojamo uzstādni, ar jaunināšanu vien nepietiek. Nomaini administratora paroles, atsauc un pārģenerē API un CI marķierus, pārskati SSH atslēgas un webhook adreses, kuras varēja pievienot vai mainīt uzbrucējs.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.