GitLab dicht 12 jaar oud gat dat een 10 scoort op de CVSS-securityschaal

GitLab bracht woensdag patches uit voor een kwetsbaarheid die al sinds 2014 in de code zit en die de hoogste score krijgt binnen het CVSS. Deze updates volgen net iets meer dan een week na kritieke patches voor GitLab. Gebruikers die deze ontwikkelsoftware zelf draaien, moeten snel updaten.

De nieuwste kritieke updates van GitLab dichten bugs en gaten in recente releases van deze software voor het ontwikkelen, beheren en beveiligen van eigen software. Naast de 19-serie bestrijken de patches ook een enkele versie in de oude 18-serie. Eén kwetsbaarheid (CVE-2026-110264) die een 10 scoort op de schaal van het Common Vulnerability Scoring System (CVSS) zit echter in GitLab sinds versie 7.0, die in juni 2014 uitkwam.

Op afstand te misbruiken

De kwetsbaarheid laat aanvallers op afstand eigen code uitvoeren op servers met GitLab Community Edition (CE) en Enterprise Edition (EE) die gebruikers zelf draaien. Aanvallers hoeven zich daarvoor niet bij de kwetsbare systemen te authenticeren. De oorzaak is een integer overflow die optreedt bij het compileren van een speciaal opgezette berekening (regular expression).

GitLab-gebruikers die nog versies ouder dan 18.11 draaien, moeten upgraden naar de gisteren uitgebrachte versie 18.11.13. De latere releases in de 19-serie krijgen elk een update, wat neerkomt op zes nieuwe versies (19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 en 19.5.1). In totaal verschenen woensdag dus zeven nieuwe GitLab-versies.

Ook niet-ondersteunde versies krijgen patches

Vier van die zeven nieuwe versies (19.2.9, 19.1.9, 19.0.10 en 18.11.13) vallen buiten de reguliere ondersteuning van GitLab. Vanwege de ernst van de kwetsbaarheid brengt GitLab een zogeheten backport van de nieuwste updates uit voor oudere releases. Gebruikers kunnen die downloaden en installeren om hun systemen veilig te stellen.

Het Nederlandse Cyber Security Centrum (NCSC) waarschuwt nu ook voor deze kwetsbaarheden. De kans op misbruik is volgens het cybersecurityorgaan van de Nederlandse overheid ‘gemiddeld’, maar de mogelijke schade is ‘groot’. Het advies is dan ook om de beveiligingsupdates zo snel mogelijk te installeren. " Er is nog geen actief misbruik vastgesteld, maar de risico's zijn groot", aldus het NCSC.

Reacties (31)

[Tielenaar]

Leuk, al onze systemen zijn aan elkaar geknoopt met PHP en Gitlab. Morgen een lek in apache/nginx en zo hebben we nooit meer weekend

[switchboy]

Moet hierbij steeds denken aan die rant over dat het internet draaiende wordt gehouden door "good enough for now code" en een sysadmin "die al tien weken geen daglicht meer heeft gezien en omringt door lege blikken maintain dew." Terwijl hij aan het ranten is over de pedantic developer die ineens besloten heeft dat delen door nul nu ineens een exception oplevert in plaats van infinity, terwijl het in de software als shorthand voor infinity werd gebruikt, waardoor alles weer stuk gaat. En het uren debuggen heeft gekost om dat te vinden.

[Asitis]

Het is vast een typo maar "maintain dew" is een perfecte programmeurs-spinoff energydrink

[BlaDeKke]

https://xkcd.com/2347/

[ikbenjoeri]

https://www.csoonline.com/article/4237420/f5-rushes-out-emergency-nginx-patches-for-three-critical-flaws.html

Deze zullen denk meer mensen over het hoofd hebben gezien

[Reactie gewijzigd door ikbenjoeri op 22 oktober 2026 15:21]

[Tjidde]

Als je morgen wakker word checken of er een CVE/CVSS is voor Apache en/of NGINX. Bij ja telefoon uit en omdraaien.

Maar gelukkig is deze niet zo heftig als het probleem van PHP gisteren.

[eborn]

En de AI-boeren spinnen garen: bugs vinden via AI en vervolgens gebruiken devops AI om zaken sneller te regelen.

[bzuidgeest]

Je hoeft ze niet aan het open internet te knopen.... Er is ook nog zoiets als VPN

[thof]

Dat hoeft zeker niet nee, maar je veilig wanen op een LAN/VPN is misschien ook wat te kort door de bocht. Een WAN en LAN zijn in dat opzicht gewoon een ander netwerk met als verschil het aantal gebruikers. Ook op LAN zijn er voldoende risico's: medewerkers met minder goed bedoelingen, malware die op een machine draait of op een IOT device, een compromised server die een pootje in WAN en LAN heeft en zo een attacker via LAN zich verder wil verspreiden (lateral movement).

[bzuidgeest]

Er is altijd risico. Een admin met slechte bedoelingen kan alles slopen en iemand kan altijd bij de admin credentials. Alleen bij banken en dergelijk zal je "locks" hebben waar meerdere personen hun key moeten ingeven om bijvoorbeeld weer toegang te krijgen tot iets als hashicorps vault

[fevenhuis]

Naast de gaten in de oude server software, zijn ook de gaten in de hardware en drivers die van elk lokaal netwerk een internationaal netwerk maken.

'There is no local network, it's always connected to someone else's computer.' - Credits plz.

[aikebah]

127.0.0.0/24 is toch behoorlijk local

[mrmrmr]

127/8 zelfs

[aikebah]

die wist ik niet zeker, de /24 wel

[Wilke]

En dan vergeet je de eMudhra TLS certificaten met triviale private keys (zoals '4') nog - ook van gisteren:

nieuws: Intermediate TLS-certs zijn gecompromitteerd, kan leiden tot afluisteren

Zie ook https://arstechnica.com/s...-8-compromised-tls-certs/

[Skit3000]

Ik denk dat ik op mijn servers de frequentie dat er gecheckt wordt op updates ga verhogen naar (minimaal) eens per uur. Van software als PHP of GitLab krijg je nog wel bericht op Tweakers te zien, maar er zullen minstens net zo veel kritieke fouten zitten in willekeurige Linux packages.

[watercoolertje]

Ben benieuw op welke 'willekeurige' packages je doelt, uiteraard goed/netjes om alles up to dat te houden maar lang niet alles is meteen een probleem.

Bedoel, stel Nano is outdated, en nu? Als iemand nano aan kan roepen op mijn server zit ie er toch al in...

Het belangrijkste is de buitendeur, en niet de wcdeur zegmaar

[Reactie gewijzigd door watercoolertje op 22 oktober 2026 15:44]

[ZinloosGeweldig]

De meeste succesvolle aanvallen maken toch gebruik van een keten van exploits.

Stel je nu bijvoorbeeld voor, dat er een aanvaller al unpriviliged toegang tot je server heeft, maar die Nano kwetsbaarheid er eentje is die een unpriviliged gebruiker een root shell laat bemachtigen. Oepsie! Had je die WC deur (of de deur naar de machinekamer) toch wel beter op slot willen hebben.

Overigens vind ik rücksichtslos alles auto-updaten niet het beste idee in deze tijd van supply-chain aanvallen, maar dat betekent niet dat een kwetsbaarheid in een pakket als nano ongevaarlijk is.

[Reactie gewijzigd door ZinloosGeweldig op 22 oktober 2026 16:47]

[Skit3000]

Of nog erger; stel dat iemand (een dependency) van Nano aanpast waardoor het elke eerste maandag van de maand om precies 12:00:00 tot 12:00:02 je HTTP port 80 hijackt en kijkt of er een commando wordt verzonden die het dan lokaal uitvoert? En jij hebt net een maand geleden die ene foute build gedownload maar niet de fix die er 30 minuten later achteraan kwam.

[Reactie gewijzigd door Skit3000 op 22 oktober 2026 16:41]

[jimmy_dg]

Maar dat doen aanvallers niet. Ze installeren gewoon direct een stealer op je host en je bent direct fucked. Als je even had gewacht was de dubieuze update teruggedraaid in je package manager en had je nergens last van gehad.

[jimmy_dg]

Dan ben je dus veel meer vatbaar voor supply chain attacks.

[Skit3000]

En krijg je ook de fix daarvoor sneller...

Maar je hebt gelijk. Het liefste wil je (alle) software als monolithic applicatie draaien zonder dat er externe componenten in zitten. In de praktijk zou dat dus betekenen dat je applicatie direct als OS opstart op een (virtuele) server, zodat je niet afhankelijk bent van Windows of Linux.

In de praktijk wil je dit vooral op virtuele servers draaien omdat je dan geen rekening hoeft te houden met drivers voor duizend-en-een verschillende soorten hardware waar je mee te maken kunt krijgen op bare bone machines. Het houdt ook in dat je monolith zelf code moet bevatten om bijvoorbeeld met de (virtuele) netwerkkaart en een (virtueel) opslagmedium te communiceren, en zelf (virtueeel) geheugen moet beheren.

[themadone]

Mensen die hun private gitlab openbaar aan internet hangen kunnen beter GitHub gaan gebruiken.

[henkbiertank]

Want Github is altijd lekker stabiel

https://mrshu.github.io/github-statuses/

[watercoolertje]

Je vergeet uit te leggen waarom je dat vindt/stelt...

[ZinloosGeweldig]

1. Waarom?
2. Ook als je eigen gitlab instance niet openbaar aan het internet hangt wil je niet dat die lek is toch.

[JFfan]

Op een schaal van 1 tot 10, klinkt het meer als een 11.

[paradoXical]

Op mijn werk bij een grote organisatie zowel PHP als Gitlab. Leuke week zo, helaas ben ik met vakantie deze week

[CH4OS]

Dat een gat al een bepaalde periode in een programma zit, betekend niet dat het ook al zolang bekend is dat die bug er is. Een zero day kan best na jaren pas gevonden worden, waar wel alle (eerdere) versies (ook) vatbaar voor zijn.

[SilentDecode]

Moeten we tegenwoordig weer de notatie "/sarcasm" gaan gebruiken hier? Of snap je de grap helemaal niet?