La vulnerabilitat de Gitea «requereix permís d'escriptura». El formulari de registre te'l dona

Hi ha dos textos oficials sobre el mateix forat de Gitea. Un diu que l'atacant necessita permís d'escriptura en un repositori. L'altre, a la mateixa pàgina, diu que no necessita cap privilegi. Sembla una errada i no ho és: és la descripció exacta de com ve configurat el producte quan l'instal·les.

Parlem del CVE-2026-60004, corregit el 27 de juliol a Gitea 1.27.1 i explotat des de fa uns dies. Afecta tot el que hi hagi entre la versió 1.17 i la 1.27.0, totes dues incloses. La mateixa publicació tancava un segon forat igual de seriós, el CVE-2026-59774, una lectura arbitrària de fitxers que ni tan sols demanava estar autenticat. El primer el va reportar Shai Rod, que signa NightRang3r; el segon el van trobar per separat xbow-security i el mateix NightRang3r.

Dues frases que semblen incompatibles

L'entrada del catàleg de CISA diu, en la nostra traducció, que la vulnerabilitat «permet a un atacant amb permís d'escriptura al repositori enviar un pedaç maliciós a l'endpoint diffpatch per plantar un hook de Git executable i executar ordres de shell com el compte de servei de Gitea». Llegeix-ho de pressa en una reunió de dilluns i el que queda surant és «amb permís d'escriptura». Sona a que cal ser algú.

El vector que publica l'avís dels mantenidors és CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, amb nota 9,8. Aquesta PR:N es llegeix «privilegis requerits: cap». I el mateix avís explica per què, amb una frase que no hem vist citada en cap de les cobertures que vam llegir ahir: «amb el registre obert activat, l'atac el pot dur a terme un visitant sense autenticar després de registrar-se un compte normal i crear un repositori» (la traducció és nostra).

Està obert de sèrie, el registre? La documentació de configuració de Gitea respon sense ambigüitat. A la secció [service], DISABLE_REGISTRATION val false, REGISTER_EMAIL_CONFIRM val false i REQUIRE_SIGNIN_VIEW val false. Qualsevol que arribi a l'URL pot donar-se d'alta sense confirmar el correu, crear-se un repositori i tenir permís d'escriptura sobre aquest repositori. El requisit de la fitxa es compleix omplint un formulari. (L'alta per OpenID va lligada al mateix interruptor: el seu valor per defecte és el contrari de DISABLE_REGISTRATION, així que es tanca sola quan tanques el registre, tret que algú l'hagi forçada a mà.)

La pregunta útil quan llegeixes «requereix autenticació»

A les reunions de priorització, «requereix autenticació» i «requereix permisos» funcionen com a calmants: baixen la vulnerabilitat un esglaó a la llista i la reunió avança. El que cal preguntar és qui pot creuar aquest llindar i en quant de temps. En un servei intern on els comptes els crea una persona a mà, el llindar dona marge de debò. En un servei amb registre obert publicat a internet, és un tràmit de deu segons. La mateixa frase de la fitxa descriu dos riscos que no s'assemblen gens.

I no és una troballa nostra d'avui: és la tercera vegada aquest estiu que acabem al mateix lloc. Ho vam escriure a l'agost arran d'un PNG de WordPress que per dins era PostScript —en un gestor de continguts, «requereix autenticació» no vol dir «requereix ser tu», vol dir «requereix un dels comptes que es regalen»— i un altre cop amb el CVE de cPanel on el risc el posava el veí, quan un 5,6 sense compte va resultar més urgent que un 8,8 amb compte. Tres vegades en tres mesos ja no és una anècdota: és que la cua de pedaços s'ordena per «quant de mal fa» quan també s'hauria d'ordenar per «quant costa arribar-hi».

CISA publica juntament amb el CVE la seva valoració SSVC, que és més útil que la nota numèrica i gairebé ningú mira: explotació activa, automatitzable sí, impacte tècnic total. Aquest «automatitzable: sí» és el que mana. Vol dir que el descobriment, la creació del compte i l'execució es poden encadenar en un script que escombra internet, i que no cal que ningú tingui interès particular en la teva empresa perquè et toqui.

D'un pedaç a un hook

L'avís dels mantenidors detalla el mecanisme amb una honestedat poc habitual, i convé llegir-lo perquè aquí no intervé cap funció amagada. L'endpoint diffpatch aplica el pedaç que li envies dins d'un clon bare temporal compartit. Si envies dues vegades el mateix pedaç es produeix una col·lisió de tipus add/add, i el mecanisme de fusió a tres bandes de Git acaba escrivint a disc rutes que eren a l'índex, malgrat la bandera --cached. En un clon bare, l'arrel del repositori és $GIT_DIR: un fitxer executable anomenat hooks/post-index-change deixa de ser un fitxer i passa a ser un hook viu, que s'executa amb el compte de servei la propera vegada que Git escriu l'índex.

El mateix avís enumera tres condicions perquè s'activi: Git 2.32 o posterior, la ruta diffpatch habilitada i un sistema de fitxers temporal que sigui escrivible i executable. I l'arranjament va consistir a deixar d'usar un clon bare per a aquesta operació. Digues-li bug o digues-li supòsit de disseny que ha envellit malament: l'interessant per a la resta de nosaltres és que cap de les peces era exòtica. Els hooks de Git són execució de codi per disseny, i ho són des de fa vint anys. El que va fallar va ser que l'atacant pogués escriure dins de $GIT_DIR.

L'altre forat de la mateixa actualització

Tota l'atenció se l'ha endut ara el CVE-2026-60004, i això deixa a l'ombra l'altre que va tancar la mateixa versió. El CVE-2026-59774 puntua també 9,8, afecta de la 1.22.1 a la 1.27.0 i és una lectura arbitrària de fitxers a través de la directiva #+INCLUDE d'Org-mode, el format de notes que Gitea sap renderitzar. N'hi ha prou amb un repositori públic i un fitxer amb el marcatge adequat per llegir qualsevol cosa que pugui llegir el compte de servei. Començant per app.ini, on viuen l'INTERNAL_TOKEN, els secrets d'OAuth i de JWT i les credencials de la base de dades.

Val la pena assenyalar-ho perquè és un patró que es repeteix a les publicacions de seguretat: se cita el CVE més cridaner, s'aplica el pedaç pensant en aquell, i la resta de la llista es llegeix per sobre. La versió corregida és la mateixa per a tots dos, així que aquí no canvia res pràctic. Canvia la conversa amb qui decideix: no demanes una finestra de manteniment per una vulnerabilitat, la demanes per dues, i una d'elles no necessita que l'atacant tingui absolutament res.

Onze segons, segons qui ho va patir

Hi ha un sol cas públic, i convé dir d'on surt: el va publicar un desenvolupador que signa com Andrey a Habr, la plataforma tècnica russa, i el van recollir després Help Net Security i The Hacker News. És un relat del mateix afectat, sense verificació de tercers, i tot i així és el més concret que hi ha. La seqüència, automatitzada de cap a cap: es va registrar un compte, es va crear un repositori, es va disparar l'exploit, es va executar codi dins del contenidor de Gitea com l'usuari git, es va escriure la prova de l'accés en una branca del mateix repositori, es va descarregar un carregador genèric i es va deixar anar una càrrega que sembla un miner de criptomonedes. Aquest matís és del mateix afectat, que diu no haver pogut confirmar ni la família del miner, ni la cartera, ni el pool. La part activa va durar uns onze segons.

El que va destapar l'assumpte va arribar per correu: el proveïdor d'allotjament avisant que el servidor virtual feia molta estona per sobre del 70 % de CPU, que això incomplia les condicions del servei i que li estaven limitant els recursos. Ja havíem vist aquest patró —el primer avís entrant pel canal de facturació o pel de suport comercial i no pel de seguretat— quan vam escriure sobre els agents RMM de proveïdors d'IT. La conseqüència pràctica: si onze segons d'execució i un consum de CPU sostingut no disparen res teu, el teu llindar de detecció està per sobre del soroll més escandalós que pot fer un intrús.

Què va quedar a l'abast d'aquell compte de servei

L'avís és explícit: la configuració de l'aplicació i els seus secrets, les credencials i el contingut de la base de dades, les credencials d'OAuth i de les integracions, i els repositoris muntats. Pràcticament tot el que un servidor de codi necessita per fer la seva feina, que és exactament el problema. Un servidor de codi no és una eina de l'equip de desenvolupament al nivell del tauler de tasques: és infraestructura de producció, perquè és l'origen del que es desplega i el guardià de les claus amb què es desplega. Vam veure el mateix patró al panell de dades que també era el clauer i a les claus de producció que guarda el teu CI/CD. I per si algú es consola pensant que el codi el té clonat tot l'equip: clonar no és tenir còpia del que aquell servidor guarda.

En el cas de Habr hi va haver sort, i la sort tenia nom tècnic. El contenidor no era privilegiat, així que la càrrega no va sobreviure als reinicis; l'afectat no va trobar rastres de persistència per cron, per systemd ni per claus SSH noves. La seva neteja va ser pujar a 1.27.2, tancar el registre, treure els mètodes d'alta que sobraven, rotar tots els secrets i tokens, restringir la xarxa de Docker i tallar la sortida a internet del contenidor. Cap d'aquestes decisions de contenció es va prendre durant l'incident: la del contenidor sense privilegis es va prendre el dia que es va muntar el servei, quan el còmode hauria estat el contrari. És l'eix amb què treballem: la fallada és inevitable, l'avaria és una decisió de disseny.

Amb un límit que convé no saltar-se, perquè és on el contenidor no va ajudar: la contenció va limitar la persistència, no la confidencialitat. Tot el que hi havia dins es va poder llegir durant els segons que l'atacant hi va ser. Per això rotar els secrets és l'únic punt de la llista de neteja que no admet fer-se la setmana vinent.

Vint minuts, i avui

CISA va afegir el CVE al seu catàleg de vulnerabilitats explotades el 25 d'agost i va donar a les agències federals nord-americanes fins al 28. A tu no t'obliga ningú, però aquesta data és la millor referència pública que hi ha sobre a quina velocitat es considera que toca moure's. Si tens Gitea, això es fa avui:

1. La versió. Tot el que hi hagi entre 1.17 i 1.27.0 està afectat. La corregida és la 1.27.1; l'afectat del cas va anar directament a la 1.27.2. Des de fora, la versió sol sortir al peu de la pàgina d'inici de sessió.
2. El registre. Comprova DISABLE_REGISTRATION, REGISTER_EMAIL_CONFIRM i REQUIRE_SIGNIN_VIEW. Si ningú els va tocar en instal·lar, són als valors oberts.
3. L'exposició i les altes recents. Contesta des d'internet? Shadowserver comptava prop de 5.000 instàncies de Gitea accessibles públicament. I la llista de comptes creats des de finals de juliol et dirà més que qualsevol escàner.
4. Sota què corre. Usuari, privilegis del contenidor, quins volums té muntats i cap a on pot sortir. Això no canvia si t'entren: canvia el que s'enduen i quant de temps es queden.
5. Rotar. Si la versió era vulnerable i el servei estava exposat, actualitzar no expulsa ningú que ja s'hagués endut un token. Tokens de desplegament, credencials de base de dades, secrets d'OAuth, claus de webhook.
6. Els rastres. La cadena documentada deixa petjades concretes i barates de buscar: comptes donats d'alta que ningú reconeix, repositoris acabats de crear per aquests comptes, branques noves a dins i crides repetides a l'endpoint diffpatch al log d'accés. Amb el mateix pedaç aplicat, aquestes quatre comprovacions són la diferència entre «hem pedaçat» i «sabem que no hi va entrar ningú».
7. El responsable. Anota a l'inventari qui respon d'aquell servei i en quina finestra s'actualitza. Si la resposta honesta és «ningú», aquesta és la troballa del dia i el CVE és el detall.

Quan el teu cas és diferent

Si el teu Gitea només escolta a la xarxa interna, amb les altes tancades i els comptes creats a mà, el registre obert deixa de ser la porta i la urgència baixa força. No desapareix: qualsevol amb compte i un repositori propi continua podent executar codi en aquell servidor, i en aquesta llista hi entra qui va marxar de l'empresa la setmana passada. Però és la diferència entre pedaçar aquest matí i pedaçar en la propera finestra. Dir-ho importa, perquè el consell de «pedaça-ho tot ara» és el que fa que ningú pedaci res.

I si no fas servir Gitea, la lectura que un s'emporta no és sobre Gitea. Canvia el nom pel del gestor de tasques autoallotjat, el panell de mètriques, el servidor de documentació o l'eina de traspàs de fitxers que algú va aixecar un dimarts de fa cinc anys perquè calia per una setmana. La pregunta no és quina versió tens. És quants d'aquests serveis estan exposats, qui hi figura com a responsable de cadascun i quin CVE d'aquest estiu tenen obert perquè la seva fitxa deia «requereix autenticació».

Nota de fonts

Avís de seguretat de Gitea GHSA-rcr6-4jqh-j84m: mecanisme, versions afectades, les tres condicions d'activació, l'impacte i la puntuació 9,8 amb el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (la puntuació és del CNA; NVD encara hi figura com a «Undergoing Analysis»). Nota de publicació de Gitea 1.27.1, del 27 de juliol de 2026, per a les dates i els crèdits dels dos CVE. Catàleg de vulnerabilitats explotades conegudes de CISA: entrada CVE-2026-60004 afegida el 25 d'agost de 2026, data límit del 28, i valoració SSVC (explotació activa, automatitzable sí, impacte tècnic total). Documentació oficial de configuració de Gitea per als valors per defecte de registre i OpenID. Relat de l'incident i la xifra dels onze segons: publicació del mateix afectat a Habr, recollida per Help Net Security el 26 d'agost de 2026 i per The Hacker News, d'on surten l'avís del proveïdor pel 70 % de CPU i el matís que la càrrega «sembla» un miner sense confirmar. Recompte d'instàncies exposades atribuït a Shadowserver via BleepingComputer. Les traduccions al català de les cites són nostres. Les dades són d'aquestes fonts; les opinions sobre priorització, inventari i detecció són nostres.