Twee kritieke lekken met de maximale score van 10,0 vragen vandaag om aandacht, in software die MSP’s zelf hosten of voor klanten beheren. GitLab repareert een fout waarmee een ongeauthenticeerde aanvaller code kan uitvoeren op zelf-gehoste servers en aanvallers misbruiken een kritiek lek in de WordPress-plugin Bricksforge al om websites over te nemen. Daarnaast repareert HPE serieuze fouten in AOS-Switch-netwerkswitches en laat onderzoek naar AWS zien hoe een enkele prompt aan een publieke AI-agent de toegang tot een heel cloudaccount kan openen.
- GitLab repareert kritiek lek met CVSS 10,0 waarmee ongeauthenticeerde aanvallers code kunnen uitvoeren
- Aanvallers misbruiken kritiek lek in WordPress-plugin Bricksforge om websites over te nemen
- HPE repareert kritieke fouten in AOS-Switch waarmee aanvallers zonder inloggegevens beveiliging kunnen omzeilen
- Eén prompt aan een publieke AI-agent opent de toegang tot een heel AWS-account: onderzoek naar Bedrock AgentCore
GitLab repareert kritiek lek met CVSS 10,0 waarmee ongeauthenticeerde aanvallers code kunnen uitvoeren
| Kwetsbaarheid | Integer overflow in de reguliere-expressiecompiler voor CI/CD, waardoor een ongeauthenticeerde aanvaller via een geprepareerde expressie in een CI/CD-configuratie code op de server kan uitvoeren – zelf-gehoste GitLab Community Edition en Enterprise Edition, versies 19.2 voor 19.2.8, 19.3 voor 19.3.4 en 19.4 voor 19.4.2 |
| CVE-nummer | CVE-2026-97229 |
| CVSS-score | 10,0 |
| Actief misbruikt | Nee, er is geen misbruik of publieke proof-of-concept bekend. GitLab maakt de technische details pas 90 dagen na de release openbaar |
| Patch beschikbaar | Ja, in 19.2.8, 19.3.4 en 19.4.2. Er is geen workaround. GitLab.com is al bijgewerkt en GitLab Dedicated vraagt geen actie |
Hoe kan de kwetsbaarheid misbruikt worden?
Volgens het patchbericht van GitLab zit de fout in de component die reguliere expressies uit pipelineconfiguraties verwerkt. Bij een berekening voor de geheugentoewijzing loopt een waarde over, waardoor te weinig geheugen wordt gereserveerd en een geprepareerde expressie daarbuiten kan schrijven. Voor misbruik zijn volgens GBHackers geen inloggegevens en geen handelingen van een gebruiker nodig. GitLab spreekt zelf over misbruik “onder bepaalde omstandigheden” en vertelt niet welke dat zijn. Het lek is gemeld door onderzoeker joaxcar via het bugbountyplatform HackerOne. In dezelfde release zitten 23 andere fixes, waaronder een cross-site scripting-fout in de syntaxiskleuring (CVSS 8,7), een onjuiste autorisatie waarmee downstream-pipelines kunnen worden gestart (8,5) en het vergiftigen van de cache van ruwe repositorybestanden.
Wat kan het gevolg zijn?
Een GitLab-server bevat doorgaans broncode, deploysleutels, runnertokens en CI/CD-variabelen met toegang tot productieomgevingen en cloudaccounts. Code-uitvoering op die server geeft een aanvaller dus een directe route naar de systemen daarachter. Dat maakt de fout extra gevoelig voor MSP’s die GitLab voor zichzelf of voor klanten beheren. Er is nog geen misbruik gemeld, maar GitLab-lekken worden snel opgepikt: eerder dit jaar werd een kritieke GitLab-fout al een dag na openbaarmaking misbruikt. Omdat GitLab nu nog geen details publiceert, is er voor aanvallers tijd nodig om de patch te analyseren, maar die voorsprong is klein.
Wat moeten IT-beheerders nu doen?
Breng alle zelf-gehoste GitLab-instanties in kaart en werk ze bij naar 19.4.2, 19.3.4 (of nieuwer) of 19.2.8, te beginnen met instanties die vanaf het internet bereikbaar zijn. Houd rekening met downtime op installaties met één node, omdat de update databasemigraties bevat. Kan er niet direct worden bijgewerkt, beperk dan de toegang tot de instantie, bijvoorbeeld via VPN of een lijst met toegestane adressen. Controleer ongebruikelijke verzoeken en onverwachte wijzigingen in projectinstellingen, CI/CD-variabelen, runnertokens en deploysleutels, en wissel geheimen als er een redelijk vermoeden van misbruik is.
Aanvallers misbruiken kritiek lek in WordPress-plugin Bricksforge om websites over te nemen
| Kwetsbaarheid | Onvoldoende validatie van bestandsuploads in de formulierverwerking, waardoor een ongeauthenticeerde aanvaller een PHP-bestand kan uploaden en uitvoeren – WordPress-plugin Bricksforge, versie 3.1.8.9 en ouder |
| CVE-nummer | CVE-2026-85097 |
| CVSS-score | 10,0 |
| Actief misbruikt | Ja, Patchstack zag de eerste aanvallen op 7 oktober 2026 en telde 63 verschillende bronadressen |
| Patch beschikbaar | Ja. Volgens The Hacker News bevat versie 3.1.8.10 de fix, het bijbehorende advies noemt 4.0.1. Controleer de changelog en installeer de nieuwste versie |
Hoe wordt de kwetsbaarheid misbruikt?
Bricksforge breidt de WordPress-sitebouwer Bricks uit met onder meer formulieren. Volgens The Hacker News controleert de plugin bij een upload het bestandstype, terwijl het door de gebruiker meegestuurde veld met de bestemming van het bestand ongecontroleerd blijft. Een aanvaller haalt eerst een geldige nonce op, uploadt een bestand dat tegelijk een geldige GIF en PHP-code is, en laat dat bij het verzenden van het formulier wegschrijven naar een locatie met de extensie .php. Daarna voert de server de ingesloten code uit. Patchstack ziet geautomatiseerde aanvallen, vermoedelijk met wisselende proxy’s, waarbij vooral de formulierroute van de plugin wordt benaderd en extensies als .php5, .phtml en varianten met hoofdletters worden uitgeprobeerd om filters te omzeilen. Aanvallers zijn ook bezig met cross-site scripting-lekken in WPC Product Bundles voor WooCommerce (CVSS 7,1, gefixt in 8.6.7) en Ninja Forms (CVSS 7,1, gefixt in 3.15.4), om een backdoorplugin te installeren en verborgen beheerdersaccounts aan te maken.
Wat kan het gevolg zijn?
Code-uitvoering op de webserver betekent een overname van de site: webshells, gestolen gegevens uit formulieren en de database, omleidingen naar malafide sites en een uitvalsbasis voor verdere aanvallen op andere sites op dezelfde hosting. Dat laatste is voor MSP’s en hostingpartijen die meerdere klantsites op één omgeving draaien een extra risico. Een update verwijdert bestaande besmettingen niet, en bij de parallelle campagne blijven verborgen beheerders en backdoorplugins na het patchen gewoon bestaan.
Wat moeten IT-beheerders nu doen?
Zoek in beheerde WordPress-omgevingen naar Bricksforge, WPC Product Bundles en Ninja Forms en werk ze bij. Zoek na het updaten naar sporen van eerder misbruik: verzoeken naar /wp-json/bricksforge/v1/form_submit met het veld temporaryFileUploads, onverwachte PHP-bestanden in de map /wp-content/uploads/bricksforge/tmp/, onbekende beheerdersaccounts in de database en vreemde bestanden in de map met must-use plugins. Kan de plugin niet direct worden bijgewerkt, schakel hem dan uit tot de update is doorgevoerd.
HPE repareert kritieke fouten in AOS-Switch waarmee aanvallers zonder inloggegevens beveiliging kunnen omzeilen
| Kwetsbaarheid | Meerdere kritieke fouten in de software van HPE Networking AOS-Switch (AOS-S), waaronder een omzeiling van authenticatie en een bufferoverflow, waarmee een aanvaller zonder inloggegevens beveiligingsmechanismen kan omzeilen, code kan uitvoeren of het apparaat kan overnemen – HPE Networking AOS-Switch. De bronnen noemen geen getroffen versies |
| CVE-nummer | Meerdere, zie het HPE-beveiligingsbulletin HPESBNW05156. In de gebruikte bronnen staan geen CVE-nummers |
| CVSS-score | Tot 9,8 |
| Actief misbruikt | Nee, het NCSC meldt geen bekend misbruik en schat de kans op misbruik in als “middel” |
| Patch beschikbaar | Ja, HPE heeft beveiligingsupdates uitgebracht. De gebruikte bronnen noemen de gefixte versies niet; zie het bulletin van HPE |
Wat is er aan de hand?
Volgens Dutch IT Channel waarschuwt het NCSC voor meerdere ernstige kwetsbaarheden in HPE Networking AOS-Switch, de besturingssoftware van HPE-netwerkswitches. Het bulletin van HPE beschrijft meerdere fouten in één update. Volgens het NCSC kunnen aanvallers in specifieke gevallen beveiligingsmechanismen omzeilen zonder inloggegevens te hebben. Daarmee zijn volgens het bericht het uitvoeren van kwaadaardige code, het overnemen van het apparaat, het inzien of wijzigen van gevoelige gegevens en een denial-of-service-aanval mogelijk.
Wat kan het gevolg zijn?
Een switch zit midden in het netwerk van een klant. Wie die overneemt, kan verkeer meekijken of omleiden en van daaruit verder het netwerk in bewegen, terwijl een denial-of-service-aanval in het slechtste geval het hele netwerk plat legt. Er is nog geen misbruik gemeld, maar kritieke fouten in netwerkapparatuur worden vaak snel geanalyseerd zodra een patch beschikbaar is. Voor MSP’s die switches voor meerdere klanten beheren, is dit een reden om de update niet tot een volgend onderhoudsvenster te laten liggen.
Wat moeten IT-beheerders nu doen?
Breng in kaart welke klantlocaties nog AOS-Switch-apparatuur gebruiken en installeer de updates van HPE zo snel mogelijk. Het NCSC adviseert beheerinterfaces nooit rechtstreeks aan het internet bloot te stellen, maar ze alleen bereikbaar te maken via een apart, extra beveiligd beheernetwerk met strikte IP-beperking. Controleer die inrichting ook bij switches die al zijn bijgewerkt.
Eén prompt aan een publieke AI-agent opent de toegang tot een heel AWS-account: onderzoek naar Bedrock AgentCore
| Kwetsbaarheid | Een publiek toegankelijke AI-agent met een tool voor webverzoeken kan via prompt injection de metadataservice van de onderliggende MicroVM bevragen en zo de tijdelijke IAM-gegevens van de agent opvragen. Omdat de standaardrol ruim was ingesteld, gaf dat toegang tot andere agents, gesprekken en geheimen in hetzelfde account en dezelfde regio – Amazon Bedrock AgentCore |
| CVE-nummer | Geen, Zenity Labs publiceerde geen CVE |
| Actief misbruikt | Geen misbruik gemeld, het gaat om onderzoek van Zenity Labs |
| Patch beschikbaar | Gedeeltelijk. AWS maakte IMDSv2 verplicht voor nieuwe agents en beperkte eind september de standaardrol. AWS noemt het gedrag zelf gedocumenteerd en adviseert least privilege |
Hoe kan dit misbruikt worden?
Zenity Labs, dat de bevindingen “AgentCorruption” doopte, liet zien dat een agent met een webtool via een geprepareerde prompt de interne metadataservice kon laten aanroepen. Volgens Dutch IT Channel geeft die service de tijdelijke inloggegevens van de agent terug, omdat het verzoek van binnen de MicroVM komt. The Next Web beschrijft dat de onderzoekers met die gegevens agents konden opsommen, containerimages en broncode konden downloaden, interne agents konden aanroepen, privégesprekken konden lezen en bij Secrets Manager konden komen. Voor persistentie schreven ze een nepgebeurtenis in het geheugen van een agent, die als blijvende instructie werd opgeslagen om voor elk antwoord een door de onderzoekers beheerde webpagina te laden.
AWS betwist het onderzoek en noemt het beschreven gedrag verwacht en gedocumenteerd. Wel paste het bedrijf na de meldingen van eind december en begin januari AgentCore aan: nieuwe agents gebruiken sinds februari IMDSv2 en de standaardrol is, volgens Zenity, eind september beperkt.
Wat kan het gevolg zijn?
Het onderzoek laat zien dat een AI-agent met te ruime rechten en vrije toegang tot het web een brug kan vormen tussen een publiek chatvenster en interne cloudresources. Dat geldt ook buiten AWS: Zenity onderzoekt vergelijkbare problemen bij andere cloudplatformen. Voor MSP’s die AI-agents voor klanten bouwen of beheren, is de les dat een publiek bereikbare agent dezelfde rechtenbeperking verdient als elke andere internetgerichte workload.
Wat moeten IT-beheerders nu doen?
Geef elke agent alleen de rechten die zijn taak vraagt en controleer de uitvoeringsrollen van bestaande agents, ook die van voor de wijziging van AWS. Dwing IMDSv2 af waar dat kan, houd publiek bereikbare en interne agents in aparte omgevingen en beperk of filter tools die willekeurige HTTP-verzoeken doen. Controleer het geheugen van agents op onverwachte instructies, en kijk in de logging naar aanroepen van de metadataservice vanuit agents.
