GitLab heeft beveiligingspatches uitgerold voor twee kwetsbaarheden in zijn platform. De belangrijkste wijziging draait om GitLab code-injection via GraphQL: een aanvaller zou, onder bepaalde omstandigheden, zonder authenticatie gebruikersdata en openbare projecten kunnen wijzigen of verwijderen. Daarnaast is een tweede issue opgelost, gerelateerd aan CSRF en de afhandeling van GraphQL-verzoeken.
Voor organisaties die GitLab zelf beheren is dit een update die je niet wilt uitstellen. Hieronder lees je wat er precies is aangepakt, voor welke versies het geldt en welke acties je nu kunt nemen.
Wat is er opgelost: GraphQL kwetsbaarheden in GitLab
GitLab’s advisories beschrijven twee problemen die allebei te maken hebben met GraphQL-verwerking. GraphQL is bedoeld om efficiënte API-aanroepen mogelijk te maken, maar dat betekent ook dat een fout in validatie of requestafhandeling direct gevolgen kan hebben voor de veiligheid.
De eerste kwetsbaarheid heeft de hoogste ernst: CVE-2026-19478. De tweede, CVE-2026-19650, heeft een lagere score maar blijft relevant omdat het gaat om misbruik van verzoekafhandeling en de mogelijkheid tot CSRF-gerelateerde scenario’s.
Critical GitLab code-injection (CVE-2026-19478)
De kern van het bericht is GitLab code-injection door middel van een GraphQL-directive. Volgens GitLab kan deze zwakte worden benut zonder dat een aanvaller hoeft in te loggen. Met de juiste aanpak zou een aanvaller data kunnen aanpassen of zelfs verwijderen, waaronder ook content in openbare projecten.
GitLab vermeldt dat het om een kwetsbaarheid gaat met CVSS-score 9.4. In de praktijk betekent zo’n score dat de kans op impact groot is zodra iemand het misbruik kan triggeren.
Het advies van GitLab richt zich specifiek op omgevingen waar je GitLab self-managed draait. Daar moet je snel upgraden om de risico’s te verkleinen.
Tweede issue: CSRF in GraphQL multiplex handler (CVE-2026-19650)
Naast de critical bug is ook CVE-2026-19650 gepatcht. Dit probleem draait om cross-site request forgery (CSRF) en beïnvloedt de handler voor een GraphQL multiplex query.
GitLab legt uit dat er onder bepaalde voorwaarden een scenario mogelijk was waarbij een (in dat geval) niet-geauthenticeerde gebruiker mutaties kon uitvoeren via GET-requests. De oorzaak lag in improper request validation binnen het GraphQL multiplex query handling mechanisme.
Deze kwetsbaarheid heeft een CVSS-score van 7.1. Dat is minder dan 9.4, maar nog steeds hoog genoeg om in dezelfde categorie “direct handelen” te vallen.
Voor welke GitLab-versies geldt dit?
De twee kwetsbaarheden raken GitLab versies vanaf een reeks releases. GitLab noemt daarbij impact op alle GitLab Community Edition (CE) en Enterprise Edition (EE) versies van:
- 18.2
- 19.0
- 19.1
- 19.2
GitLab heeft de problemen vervolgens opgelost in de volgende GitLab versies:
- 18.11.11 (voor CE/EE in die lijn)
- 19.0.8
- 19.1.6
- 19.2.4
Als jouw omgeving in een van de getroffen reeksen valt, dan is upgraden naar een van deze versies de aangewezen stap.
GitLab.com en Dedicated: geen actie nodig
Niet elke GitLab-gebruiker hoeft zelf aan de slag. GitLab geeft aan dat de patches automatisch zijn toegepast op:
- GitLab.com
- GitLab Dedicated
Voor gebruikers van deze diensten is er volgens GitLab geen additionele handeling vereist. De verantwoordelijkheid ligt daar bij GitLab zelf voor de updatecyclus.
Aanbevolen actie: upgrade je self-managed GitLab
GitLab adviseert om alle self-managed installaties onmiddellijk te upgraden naar een van de gepatchte versies. Dat betekent concreet dat je in je changeproces rekening houdt met:
- het bepalen van je huidige GitLab-variant (CE/EE)
- het identificeren van de exacte versie die draait
- het plannen van een upgrade naar een gepatchte release uit de lijst
- het na de upgrade controleren of alle services weer normaal functioneren
Omdat de critical GitLab code-injection kwetsbaarheid zonder authenticatie kan worden misbruikt, is “afwachten” niet verstandig. Zelfs als je niet verwacht dat iemand misbruik maakt, blijft de aanvalskans bestaan zolang de kwetsbaarheid aanwezig is.
Geen aanwijzingen voor actief misbruik, maar wel direct patchen
GitLab meldt dat er in de berichtgeving geen indicaties zijn dat de kwetsbaarheden al worden misbruikt in het wild. Ook noemt GitLab dat beide issues via zijn HackerOne bug bounty zijn gerapporteerd.
Maar het ontbreken van publieke exploit- of misbruiksignalen is geen reden om te wachten. In het verleden is gebleken dat kwetsbaarheden vaak pas later breed inzetbaar worden zodra er tooling beschikbaar komt of zodra aanvallers het patroon ontdekken.
Waarom dit type fix belangrijk is voor codeplatformen
GitLab is meer dan een codeopslag: het is een platform waar teams samenwerken, builds draaien en projecten delen. Als een kwetsbaarheid in GraphQL-validatie of requestafhandeling misbruikbaar blijkt, kan dat direct impact hebben op wat er in repositories gebeurt—en op de gegevens die je organisatie bewaart.
Daarom past deze patch ook in een bredere trend: aanvallers richten zich steeds vaker op ontwikkelplatformen en hun integraties. Heb je een GitLab-omgeving, dan is een gestructureerde patchstrategie onderdeel van basisweerbaarheid.
Als je daarnaast kijkt naar hoe andere aanvalspatronen zich in software supply chain en applicatielogica voordoen, dan is het interessant om ook te lezen hoe kwetsbaarheden in tooling of beheercomponenten escaleren. Bijvoorbeeld: LiteLLM supply chain aanval: 2.500 organisaties geraakt.
Praktische checklist na het upgraden
Na het upgraden naar een gepatchte versie is het verstandig om kort maar gericht te controleren of alles stabiel draait. Denk aan:
- check op de status van webinterface en API-endpoints
- controle van GraphQL-werking (voor zover je daar tests voor hebt)
- controle op logging rond GraphQL-verzoeken en eventuele foutcodes
- verifieer dat mutaties en queries weer normaal functioneren binnen je werkstromen
Zo voorkom je dat een patchactie wel is uitgevoerd, maar dat er later toch onverwachte bijwerkingen aan het licht komen.
Conclusie
GitLab heeft patches beschikbaar gesteld voor twee GraphQL-kwetsbaarheden, met als belangrijkste aandachtspunt GitLab code-injection via CVE-2026-19478. Deze issue heeft een zeer hoge ernstscore en kan volgens GitLab worden misbruikt zonder authenticatie om gebruikersdata en openbare projecten te wijzigen of te verwijderen.
Daarom is de boodschap helder: draai je GitLab self-managed, upgrade dan direct naar een gepatchte versie uit 18.11.11, 19.0.8, 19.1.6 of 19.2.4. Voor GitLab.com en GitLab Dedicated geldt dat de updates automatisch zijn doorgevoerd.
Bron: https://www.securityweek.com/gitlab-patches-critical-code-injection-vulnerability/
