Bijgewerkt op 60 min leestijd
Sébastien Nobour
Oprichter van DEVEDANOS
PHP is een programmeertaal. De ontwikkelaars ervan omschrijven het als een veelzijdige scripttaal, bijzonder geschikt voor het web: op de server stelt PHP elke pagina van een website samen op het moment dat een bezoeker erom vraagt. Volgens W3Techs, een dienst die bijhoudt welke technologieën websites gebruiken, wordt PHP in oktober 2026 gebruikt door 69,3 % van de websites waarvan de taal aan de serverkant bekend is. WordPress, Drupal, Magento, PrestaShop, Laravel en Symfony zijn in PHP geschreven.
Op 21 oktober 2026 bracht het PHP-team met spoed nieuwe versies van de taal uit. Die dichten twee kritieke kwetsbaarheden, die hun ontdekkers PHP2Shell hebben gedoopt. Met een paar verzoeken, zonder account of wachtwoord, kan een aanvaller de server waarop een website staat zijn eigen code laten uitvoeren. En dat gebeurt allemaal nog voordat de code van de website zelf wordt uitgevoerd. De kwetsbaarheden gaan terug tot PHP 5.4, uitgebracht op 1 maart 2012. Er zijn aanvallen gemeld voordat de patch werd gepubliceerd.
Gebruikt uw website of applicatie PHP, stel dan vandaag nog deze eenvoudige vraag aan uw hostingprovider of uw leverancier: welke PHP-versie gebruiken we, en wanneer stappen we over op een gepatchte versie? De stappen die u daarna zet, in volgorde, vindt u in de sectie “WordPress-site gehackt of kwetsbaarheid ontdekt: wat te doen, in deze volgorde”.
Dezelfde dag brachten ook GitLab en Node.js patches uit voor ernstige kwetsbaarheden. GitLab, een platform dat de code van software host en het testen en deployen ervan automatiseert, dichtte een kwetsbaarheid (CVE-2026-110264) met een score van 10 op 10, waarmee zonder account en onder bepaalde voorwaarden code kon worden uitgevoerd op de installaties die bedrijven zelf hosten. Alle versies vanaf 7.0 waren getroffen. GitLab.com, de versie die GitLab zelf host, was al gepatcht.
Node.js, de software die JavaScript op servers uitvoert, bracht versies uit die vier kwetsbaarheden met een hoge ernst dichten. Met een daarvan, in het decoderen van gegevens die in het Brotli-formaat zijn gecomprimeerd, kan op afstand code worden uitgevoerd. Deze versies werken ook de lijst van vertrouwde certificaten bij, nadat een tussenliggende certificeringsinstantie van eMudhra was gecompromitteerd.
Host uw bedrijf GitLab zelf, of gebruiken zijn applicaties Node.js, dan geldt voor die software dezelfde vraag: welke versie gebruiken we, en wanneer stappen we over op een gepatchte versie?
Media bundelden deze patches en andere incidenten van die week onder de naam “Black October”. Voor zover wij weten, dook die naam voor het eerst op in een bericht dat de ontwikkelaar Muzzammil in de nacht van 21 op 22 oktober op X plaatste; Axios nam hem een paar uur later over, net als 404 Media. SecurityToday, een Duitse nieuwssite over IT-beveiliging, ziet er vooral een piek in openbaarmakingen in: veel van de aanvallen die in die dagen aan het licht kwamen, waren weken of maanden eerder begonnen.
Wat volgt, geldt voor elke applicatie, in welke taal ze ook is geschreven. Dit is niet de eerste kwetsbaarheid van deze omvang, en niets wijst erop dat het de laatste zal zijn. Op drie dingen kunt u zich vooraf voorbereiden: waar een kwetsbaarheid toegang toe geeft, hoe lang het duurt voordat u het merkt, en hoe lang het duurt om het lek te dichten.
De technische details staan in de passages met de titel “Voor uw technische team”.
Op een webserver is PHP het programma dat de code van een website uitvoert: die van WordPress, van een PrestaShop-webwinkel of van een applicatie op maat. De twee kwetsbaarheden, bekend als CVE-2026-109618 en CVE-2026-109619, zitten niet in een van die programma’s, en ook niet in een plugin. Ze zitten in PHP zelf.
Het PHP-team beschrijft ze als volgt. De eerste treedt op wanneer PHP midden in een verzoek zonder geheugen komt te zitten: half voorbereide gegevens worden daarna als geldig behandeld. De tweede laat gegevens van een afgerond verzoek in het geheugen van de server achter, die een volgend verzoek kan hergebruiken. Het team geeft ze een ernstscore van 9,2 op 10 (CVSS 4.0-schaal). Volgens Calif, een bedrijf voor beveiligingsonderzoek waarvan de onderzoekers de eerste kwetsbaarheden bij het PHP-team meldden, kunnen ze worden misbruikt in de standaardconfiguraties.
Volgens de tijdlijn die Calif publiceerde, dateert de eerste melding aan het PHP-team van 11 augustus 2026. Het onderzoeksteam van Wiz, een bedrijf voor cloudbeveiliging, publiceert een andere tijdlijn: ontdekt op 19 augustus, gemeld aan het PHP-team op 24 augustus. Calif rekent OpenAI, de maker van AI-modellen, tot de ontdekkers. Het PHP-team, Calif, OpenAI en Wiz bereidden een gecoördineerde bekendmaking voor: de kwetsbaarheid aankondigen op de dag dat de patch beschikbaar is, zodat aanvallers zo weinig mogelijk tijd krijgen. Op 20 oktober lekten er details uit vóór de geplande publicatiedatum (Patchstack). Het PHP-team vervroegde de publicatie met een dag (CyberScoop). De versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 verschenen op 21 oktober rond 16.00 uur Parijse tijd. Het PHP-team is duidelijk: “Er bestaat geen volledige tijdelijke oplossing; updaten is de enige veilige keuze.”
Op de ochtend van 21 oktober, vóór de publicatie van de patch, werden de eerste aanvallen gemeld. Cloudflare, een aanbieder van diensten die websites beschermen en versnellen, zag aanvallen op zijn klanten tussen het lek en de officiële publicatie. Op 21 oktober om 5.02 uur Parijse tijd zette het filterregels aan voor al zijn klanten, ook voor wie de gratis versie gebruikt, en vroeg hen tegelijk de patch toch te installeren. Patchstack, dat de kwetsbaarheden in het WordPress-ecosysteem volgt, meldt dat hostingproviders waarmee het samenwerkt dezelfde ochtend misbruik signaleerden. Rond 16.00 uur Parijse tijd zagen de eigen sensoren van Patchstack nog alleen verkenningspogingen, zonder bewijs van een inbraak. watchTowr, dat aanvallen volgt met een netwerk van lokservers, zegt op 21 oktober misbruik te hebben waargenomen. Volgens het threat-intelligenceteam van Amazon registreerden zijn lokservers zelfs al op 17 oktober een poging tot misbruik, vier dagen vóór de publicatie. De topman van Cloudflare publiceerde hoe de aantallen opliepen (The Register): duizenden pogingen tot misbruik (geen bevestigde inbraken) op zijn netwerk in de tien uur vóór de aankondiging, tienduizenden in de 45 minuten daarna, en vervolgens miljoenen. In Japan riep de premier websitebeheerders dezelfde dag op na te gaan of ze PHP gebruiken en de patch die nacht te installeren, of anders hun websites tijdelijk offline te halen. Banken, vervoerders en overheidsinstanties in Japan en Europa legden een deel van hun diensten stil. Op 21 oktober stonden deze kwetsbaarheden volgens watchTowr niet in de catalogus van misbruikte kwetsbaarheden van de CISA, het Amerikaanse agentschap voor cyberbeveiliging.
In Frankrijk publiceerde de CERT-FR, het incidentresponscentrum van ANSSI, het Franse nationale agentschap voor de beveiliging van informatiesystemen, dezelfde dag nog een waarschuwing. Het raadt daarin aan de getroffen systemen te isoleren en daarna, zodra de patch beschikbaar is, over te stappen op een ondersteunde en bijgewerkte versie. De CERT-EU, de tegenhanger voor de Europese instellingen, adviseert onmiddellijk te patchen en, als dat niet kan, te overwegen de blootgestelde applicaties van internet los te koppelen totdat de patch is geïnstalleerd en gecontroleerd. In de Verenigde Staten vraagt de CISA om PHP-systemen die niet direct kunnen worden bijgewerkt of die nog PHP 8.1 of ouder gebruiken, offline te halen; de cyberafdeling van de FBI gaf op 21 oktober dezelfde instructie.
session.upload_progress.enabled=0 (met php_admin_flag voor PHP-FPM); Calif benadrukt dat deze instelling geen patch vervangt. De CERT-FR stelt voor verzoeken van het type multipart te blokkeren, of op zijn minst te monitoren, op het niveau van een webapplicatiefirewall, en benadrukt dat het deze omwegen niet zelf heeft getoetst. Herstart alle PHP-processen na een gewijzigde instelling (Patchstack); die wijziging wordt, net als elke andere, doorgevoerd via de pipeline of door de hostingprovider.Om dat te begrijpen, moet u weten wat PHP doet wanneer er een verzoek binnenkomt. Als een bezoeker een formulier of een bestand verstuurt, geeft de webserver het verzoek door aan PHP. PHP bereidt het eerst voor: het knipt de ontvangen gegevens op, reserveert geheugen en zet de sessie van de bezoeker klaar. Pas daarna start het de code van de website, de code die controleert wie er is ingelogd en wat die mag doen.
PHP2Shell slaat toe tijdens die voorbereiding. Volgens Calif verlopen beide aanvalspaden “voordat het beoogde PHP-bestand wordt uitgevoerd”. Wiz voegt eraan toe dat de aanval zelfs werkt als de applicatie nooit sessies gebruikt. Volgens Calif gelden er met PHP-FPM extra voorwaarden (zie het technische kader hierboven).
Het mechanisme verloopt, vereenvoudigd, in drie stappen.
Op dat moment zijn de inlogpagina en de toegangsregels van de applicatie nog niet eens uitgevoerd.
De code van de aanvaller wordt dan hoogstwaarschijnlijk uitgevoerd met de rechten van het PHP-proces, dat wil zeggen van de systeemgebruiker die PHP op de server uitvoert (php.net). Dat is niet automatisch de beheerder van de machine. Maar die gebruiker kan alles lezen wat PHP nodig heeft om de website te laten werken. En op een systeem dat zelf niet is bijgewerkt, maken andere bekende kwetsbaarheden het mogelijk om van die gebruiker door te stoten tot beheerder van de machine: dat was het geval bij PwnKit en Baron Samedit, waarover verderop meer.
Hier volgt een plausibel scenario, dat combineert wat deze kwetsbaarheden mogelijk maken met wat aanvallers al eerder tegen PHP-websites hebben gedaan. Tot nu toe is er geen aanval van dit type met PHP2Shell beschreven.
Het wachtwoord van de database lezen. Een website moet verbinding maken met zijn database, en het wachtwoord staat meestal in een configuratiebestand. Bij WordPress is dat wp-config.php, dat volgens de documentatie van WordPress “de basisconfiguratie van uw website bevat, zoals de verbindingsgegevens van de database”. De beveiligingsgids van WordPress raadt aan het leesrecht te beperken tot de eigenaar “en de webserver”. Wordt PHP uitgevoerd door dezelfde systeemgebruiker als de webserver, wat van de configuratie afhangt, dan kan de code van de aanvaller dit bestand lezen. Wachtwoorden zoeken in configuratiebestanden is een techniek die is opgenomen in MITRE ATT&CK, de standaardkennisbank over aanvalstechnieken.
Bij de gegevens komen. Met dat wachtwoord maakt de aanvaller verbinding met de database zoals de applicatie dat doet: klantaccounts, bestellingen, adressen. Mag het databaseaccount ook tabellen verwijderen of wijzigen, dan kan hij veel meer dan alleen lezen.
Een achterdeur achterlaten. De aanvaller kan een webshell plaatsen: een klein bestand op de webserver waarmee hij later via zijn browser de server weer kan aansturen (MITRE ATT&CK). Dat bestand blijft staan na de update van PHP. De kwetsbaarheid dichten verwijdert het niet.
Kaartgegevens onderscheppen. In een webwinkel kan de aanvaller in de betaalpagina code plaatsen die de kaartnummers kopieert die klanten invoeren. Dat deden de aanvallers van CosmicSting, verderop beschreven.
Het geheugen van de server lezen, zonder code uit te voeren. Volgens Wiz maken deze kwetsbaarheden het ook mogelijk een deel van het geheugen van de PHP-processen te lezen, waarin “wachtwoorden, authenticatietokens, API-sleutels en certificaten” kunnen staan.
Twee recente aanvallen laten zien wat er van zulke kwetsbaarheden wordt zodra ze openbaar zijn. In juni 2024 werden er binnen 24 uur na de publicatie van een kwetsbaarheid in PHP onder Windows (CVE-2024-4577) talloze pogingen gedaan om haar te misbruiken, volgens het onderzoeksteam van Akamai, een bedrijf voor beveiliging en contentdistributie op internet. De aanvallers installeerden er tools om de server op afstand over te nemen, software die op kosten van de server cryptovaluta mijnt, en de software van een netwerk van gehackte machines. Volgens Help Net Security, dat het bedrijf Imperva aanhaalt, werd dezelfde kwetsbaarheid gebruikt om ransomware te verspreiden, twee dagen na de publicatie van de patch.
Hetzelfde jaar trof CosmicSting (CVE-2024-34102) Magento en Adobe Commerce, twee webwinkelplatforms die in PHP zijn geschreven. Volgens Sansec, een bedrijf gespecialiseerd in de beveiliging van webwinkels, hackten zeven groepen aanvallers 4275 webwinkels. Ze stalen de geheime versleutelingssleutel van de winkel, maakten daarmee toegang aan tot de programmeerinterface ervan, en plaatsten daarna in de betaalpagina code die de gegevens van betaalkaarten kopieerde. Toen de aanvallers naar die sleutels begonnen te zoeken, had 75 % van de installaties de patch niet geïnstalleerd. En volgens Sansec, geciteerd door The Hacker News, bleven zelfs gepatchte winkels kwetsbaar zolang ze hun sleutel niet hadden vervangen: een sleutel die vóór de patch was gestolen, werkte daarna nog steeds. Met het installeren van de patch is het incident dus niet voorbij.
Eerst de contentmanagementsystemen. Volgens W3Techs wordt WordPress in oktober 2026 alleen al gebruikt door 39,6 % van alle websites. Joomla (2,4 %), Drupal (0,6 %), PrestaShop (0,5 %), Bitrix, TYPO3 en OpenCart (elk 0,3 tot 0,4 %) zijn ook in PHP geschreven.
Dan de applicaties op maat. Laravel en Symfony zijn frameworks: verzamelingen componenten waarop applicaties op maat in PHP worden ontwikkeld. Symfony meldt dat Drupal, PrestaShop en Laravel op zijn componenten zijn gebouwd. Onder de bedrijfssoftware vinden we Dolibarr, een opensource-ERP en -CRM voor zowel kleine als grote bedrijven, dat in PHP is geschreven.
Calif zegt misbruik te hebben bevestigd op WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube en WHMCS, en ook op Laravel en Symfony. En andere producten bevatten PHP zonder dat het zichtbaar is: de CERT-EU waarschuwt dat producten waarin PHP is ingebouwd getroffen kunnen zijn, ook als ze het niet rechtstreeks blootstellen. Palo Alto Networks bevestigde dat op 21 oktober: alle versies van PAN-OS, het besturingssysteem van zijn firewalls, en van zijn beheerconsole Panorama zijn getroffen, via de beheerinterface. Op die datum is er nog geen versie met een patch beschikbaar; de leverancier raadt aan de toegang tot die interface te beperken tot vertrouwde interne adressen. Het NCSC houdt een lijst bij van software die van PHP afhankelijk is: het beste vertrekpunt om na te gaan welke u gebruikt.
Hoeveel websites gebruiken een versie die het PHP-team niet meer patcht? In oktober 2026 is dat volgens onze berekeningen op basis van de cijfers van W3Techs bijna de helft van de PHP-websites waarvan de versie bekend is: ongeveer 35 % gebruikt PHP 7 of ouder, en ongeveer 14 % PHP 8.0 of 8.1 (verdeling per versie, details van PHP 8). Neem dit cijfer met de nodige voorzichtigheid: sommige Linux-distributies patchen zelf oude versies zonder het versienummer te wijzigen, dus een oude versie is niet altijd een kwetsbare versie. Volgens een schatting van onderzoekers, die CyberScoop op 21 oktober 2026 aanhaalde, zouden meer dan 1,3 miljoen servers die vanaf internet bereikbaar zijn kwetsbaar kunnen zijn. Controleer dus de PHP-versie van uw website, of vraag die op bij uw hostingprovider. Staat ze niet meer tussen de versies die het PHP-team onderhoudt, dan komt er geen nieuwe officiële release die PHP2Shell dicht. Het PHP-team heeft wel minimale patches in de vorm van broncode uitgebracht voor PHP 7.4, 8.0 en 8.1 (technisch kader hierboven), maar de meeste websites krijgen die alleen via hun Linux-distributie of hun hostingprovider. Anders stapt u over op een versie die wel wordt onderhouden.
Veertienenhalf jaar tussen het schrijven van code en de ontdekking van de kwetsbaarheid erin: dat lijkt enorm. Toch gebeurt het vaak, ook bij enkele van de ernstigste kwetsbaarheden van de afgelopen jaren.
| Kwetsbaarheid | Getroffen software | Aanwezig sinds | Openbaar gemaakt | Duur |
|---|---|---|---|---|
| Shellshock | Bash, de opdrachtinterpreter van Unix- en Linux-systemen | 1989 | september 2014 | ongeveer 25 jaar (D. A. Wheeler) |
| PwnKit | pkexec, een tool van polkit waarmee onder Linux een opdracht met andere rechten wordt gestart | mei 2009 | januari 2022 | ongeveer twaalfenhalf jaar (Qualys) |
| Baron Samedit | sudo, de opdracht waarmee u onder Linux opdrachten als beheerder uitvoert | juli 2011 | januari 2021 | ongeveer negenenhalf jaar (Qualys) |
| Heartbleed | OpenSSL, een versleutelingsbibliotheek | maart 2012 | april 2014 | ongeveer 2 jaar (heartbleed.com) |
| PHP2Shell | PHP | maart 2012 | oktober 2026 | ongeveer veertienenhalf jaar (php.net) |
Onderzoekers maten al in 2006 hoe lang kwetsbaarheden verborgen blijven. Andy Ozment en Stuart Schechter, twee onderzoekers in computerbeveiliging, volgden de kwetsbaarheden van OpenBSD, een opensource-besturingssysteem dat bekendstaat om zijn beveiliging, gedurende zevenenhalf jaar en vijftien versies. 62 % van de kwetsbaarheden die tijdens het onderzoek werden gemeld, was al aanwezig bij de start ervan, en de helft van de kwetsbaarheden in de oorspronkelijke code bleef minstens 2,6 jaar verborgen voordat ze werd ontdekt (USENIX Security 2006).
Bij PHP2Shell waren er zelfs voortekenen. Volgens Calif werd al in 2004 een eerste PHP-probleem met de geheugenlimiet gevonden, werd in 2020 een verwante bug gemeld, en signaleerde een audit in 2024 een vergelijkbaar probleem, zonder te kunnen aantonen dat het misbruikt kon worden.
Deze kwetsbaarheden hebben één ding gemeen: ze zaten in code die jaren eerder was geschreven en waarop heel veel systemen steunen.
Mandiant, het dreigingsanalyseteam van Google Cloud, meet elk jaar de tijd tussen de publicatie van een kwetsbaarheid en het eerste waargenomen misbruik. Gemiddeld was dat 63 dagen in 2018 en 2019, 44 dagen tussen 2020 en begin 2021, 32 dagen in 2021 en 2022, en in 2023 nog maar 5 dagen (Mandiant). In zijn rapport M-Trends 2026 schat Mandiant dat het eerste misbruik gemiddeld zeven dagen vóór de publicatie van de kwetsbaarheid plaatsvindt. Misbruik gebeurt vaak “zelfs voordat er een patch is gepubliceerd” (M-Trends 2026).
VulnCheck, een bedrijf dat kwetsbaarheden in de gaten houdt, keek alleen naar kwetsbaarheden waarvan misbruik is aangetoond. In de eerste helft van 2026 werd 23,43 % daarvan misbruikt op de dag van publicatie, of eerder. Contentmanagementsystemen, zoals WordPress en zijn plugins (zo heten uitbreidingen bij WordPress), vormen de meest getroffen categorie: een derde van die kwetsbaarheden (VulnCheck). Voor de meest misbruikte WordPress-kwetsbaarheden mat Patchstack, dat bescherming tegen zulke aanvallen verkoopt, in 2025 een mediane tijd van vijf uur tot het eerste misbruik (Patchstack). En volgens het jaarlijkse rapport van Verizon over datalekken, editie 2026, begint 31 % van de datalekken met een kwetsbaarheid in software, vaker dan met gestolen wachtwoorden (Verizon DBIR 2026).
PHP2Shell is daar een voorbeeld van: een eerste poging die Amazon al op 17 oktober opmerkte, een lek op 20 oktober, aanvallen die Cloudflare en watchTowr in de ochtend van 21 oktober meldden, en de patch in de middag van 21 oktober.
Deze cijfers verklaren wat volgt. Als de aanval kan beginnen voordat de patch is gepubliceerd, is de patch installeren niet genoeg. Dan moet u nog drie dingen voorbereiden: dat de kwetsbaarheid, op de dag dat ze wordt misbruikt, niet overal toegang toe geeft; dat u direct wordt gewaarschuwd; dat de patch, eenmaal gepubliceerd, nog dezelfde dag in productie gaat.
De onderzoekers van Calif vertellen dat ze de broncode van PHP hebben doorgelicht met hulp van een taalmodel. AI-agents volgden de paden door de code, en een model maakte van de eerste kwetsbaarheid een zoekmethode, waarmee een tweede werd gevonden. Volgens hen hadden ze geen speciale tools nodig en geen toegang tot een niet-openbaar model; wel telde hun kennis van de geschiedenis van PHP-kwetsbaarheden mee. Wiz waarschuwt op zijn beurt dat taalmodellen kunnen helpen een aanval aan te passen aan verschillende PHP-versies, configuraties en geheugenindelingen, en dat “dit de drempel voor aanvallen op grote schaal flink verlaagt”.
Het is niet het eerste geval. In 2024 vond Big Sleep, een AI-agent van Google, in SQLite, een database die in heel veel applicaties zit, een misbruikbare kwetsbaarheid, die werd gedicht voordat ze in een gepubliceerde versie terechtkwam (Google Project Zero). In augustus 2025, tijdens de finale van de AIxCC-wedstrijd van DARPA, het onderzoeksagentschap van het Amerikaanse ministerie van Defensie, vonden AI-systemen 54 kwetsbaarheden die voor de wedstrijd waren ingebracht, en dichtten ze er 43, in gemiddeld 45 minuten per patch. Ze vonden ook 18 echte kwetsbaarheden, die niet voor de gelegenheid waren ingebracht (DARPA).
Op 21 oktober dichtten twee projecten kwetsbaarheden die met AI-tools waren gevonden: PHP, volgens de ontdekkers van zijn kwetsbaarheden, en Node.js, voor een van zijn eigen kwetsbaarheden (CVE-2026-111497), die het team toeschrijft aan OpenAI Codex Security en twee onderzoekers. De kwetsbaarheid in GitLab werd gemeld door een onderzoeker, en GitLab noemt geen enkele AI-tool.
Op 21 oktober beschreef Microsoft een campagne die met ARTEX werd uitgevoerd door Storm-0940, een actor die volgens Microsoft aan de Chinese staat gelieerd is. Microsoft omschrijft ARTEX als een opensource-framework voor penetratietests dat de stappen van een aanval aan AI-agents overlaat. Volgens Microsoft gebruikte Storm-0940 het om aanvallen op honderden organisaties te automatiseren. Nadat de actor ConnectWise had gecompromitteerd, een leverancier van software voor IT-dienstverleners, probeerde hij in te loggen op meer dan 2.250 Microsoft 365-omgevingen van de klanten ervan. De agents namen de verkenning voor hun rekening, het wijzigen van inloggegevens van applicaties en pogingen om rechten aan te passen om hun toegang uit te breiden of te verlengen. Microsoft voegt eraan toe dat de meeste van die pogingen mislukten.
Op 19 oktober meldde Reuters dat een Chineessprekende cybercrimineel AI-agents had gebruikt om binnen te dringen in de websites van meer dan 100 bedrijven, voor ongeveer 5.000 dollar aan AI-verbruik. Het persbureau kon niet vaststellen in welke mate er gegevens zijn buitgemaakt. Reuters baseert zich op het rapport van een onderzoeker, Snorre Fagerland, van het bedrijf NorForge; van de genoemde bedrijven zeggen er twee een incident op een website te hebben afgehandeld.
Amazon beschrijft een algemene trend: analyse met hulp van AI maakt het goedkoper om van een patch of een beveiligingsadvies tot een werkende aanval te komen, en meer aanvallers kunnen toeslaan in de uren, of zelfs de minuten, na de publicatie van de details van een kwetsbaarheid. Amazon zegt niet dat de aanvallers van PHP2Shell AI hebben gebruikt, en geeft aan niet te weten hoe de aanvaller vóór de publicatie aan informatie over de kwetsbaarheid is gekomen.
Big Sleep en AIxCC laten zien dat AI-systemen kwetsbaarheden vinden in code die echt in gebruik is; volgens Wiz kan een model helpen een aanval aan te passen; en volgens Microsoft voeren AI-agents al aanvallen uit op organisaties. AI helpt dus zowel wie kwetsbaarheden dicht als wie ze misbruikt. Wij beschouwen het als een hypothese: de tijd tussen de ontdekking van een kwetsbaarheid en de eerste aanvallen zou nog korter kunnen worden.
De beveiligingsautoriteiten zijn het over één punt eens: AI verkort de tijd die overblijft voor wie patches installeert. In februari 2026 schreef de CERT-FR in zijn overzicht van de dreiging rond generatieve AI dat die technologie “kwaadwillende actoren in staat stelt sneller en dus op grotere schaal te handelen”. In mei kondigde het National Cyber Security Centre (NCSC) van het Verenigd Koninkrijk een golf van updates aan, voor kwetsbaarheden van elke ernst, omdat AI het in bekwame handen mogelijk maakt de zwakke plekken die zich in software hebben opgestapeld “op grote schaal en in een hoog tempo” te misbruiken. In juni veranderde de CISA de termijnen die het de Amerikaanse federale overheidsdiensten oplegt om patches te installeren: die hangen voortaan af van het risico (blootstelling aan internet, aangetoond misbruik, impact). De kortste termijn is drie dagen. Het agentschap rechtvaardigt deze wijziging met het gebruik van AI door aanvallers, dat de tijd waarover verdedigers beschikken “nog verder zou kunnen verkorten”. Wij leiden er een regel uit af: een kritieke patch wordt geïnstalleerd op de dag dat hij wordt gepubliceerd (zie de tijd tot misbruik hierboven), wat mogelijk is met een manier van opleveren waarbij elke wijziging al door de pipeline gaat.
AI wordt ook gebruikt om code te schrijven, en verscheidene van deze autoriteiten raden aan die code te controleren. In maart 2026 waarschuwde de directeur van het Britse NCSC dat onveilige software, geproduceerd “zonder dat een mens ze naleest”, kwetsbaarheden zou kunnen verspreiden. ANSSI en het BSI, zijn Duitse tegenhanger, wijzen in hun rapport over programmeerassistenten op het risico dat ontwikkelaars, vooral beginnende, te afhankelijk worden van deze tools en de code die ze genereren zonder controle accepteren. Ze bevelen aan dat gegenereerde code in de regel door de ontwikkelaars wordt gecontroleerd, met een kritische blik op de fouten van de tool en op de beveiligingsrisico’s. De CERT-FR wijst op een andere valkuil: een AI-assistent kan de naam verzinnen van een component die niet bestaat, en aanvallers registreren die namen om er kwaadaardige versies onder te publiceren. Voor AI-agents geldt het principe van zo min mogelijk rechten net zo goed als voor het PHP-proces (details verderop).
Concreet raden wij een team dat met AI ontwikkelt aan om elke regel die de tool schrijft na te lezen en door de tests van de pipeline te laten gaan, net als de rest van de code; om na te gaan of een component die AI voorstelt bestaat, en wie hem publiceert, voordat hij wordt toegevoegd; en om een agent alleen de rechten te geven die zijn taak nodig heeft. Voor een applicatie die met AI is gemaakt, beschrijft ons artikel “Een app maken met AI: kan dat?” wat de tool zelf kan.
Een mkb-bedrijf of een startup hoeft geen beveiligingsonderzoekers in dienst te hebben. Een kwetsbaarheid als PHP2Shell vinden is werk voor specialisten, en hun onderzoek vond plaats vóór de publicatie: tussen de eerste melding en de patch zaten acht tot tien weken, volgens de tijdlijnen van Wiz en Calif. Voor de rest bundelt de gids voor digitale hygiëne van ANSSI in de editie van 2017 42 maatregelen. Het agentschap schrijft daarin dat het merendeel van de aanvallen waarbij het tussenbeide kwam, voorkomen had kunnen worden als die maatregelen waren toegepast. Wie de kennis mist, adviseert het agentschap een specialist in te schakelen voor een diagnose en binnen het bedrijf een aanspreekpunt voor beveiliging aan te wijzen.
Dave Farley is de bedenker van de deployment-pipeline, vaak CI/CD-pipeline genoemd. Bij Continuous Delivery staat de software op elk moment klaar om naar productie te gaan, in kleine wijzigingen die automatisch worden gecontroleerd. De deployment-pipeline is de geautomatiseerde keten die elke wijziging in de code oppakt, test, vastlegt en klaarzet om naar productie te gaan. Dave Farley schreef samen met Jez Humble het boek “Continuous Delivery” (Continue oplevering), en is de auteur van “Modern Software Engineering” (Moderne software-engineering). In “Continuous Delivery Pipelines” (Pipelines voor Continuous Delivery) schrijft hij dat beveiliging het advies van specialisten kan vragen, maar dat ze “de verantwoordelijkheid is van iedereen in het team”. Specialisten adviseren; ze horen geen “poortwachters” te zijn die elke stap naar productie goedkeuren.
Wat het team dat de applicatie ontwikkelt en onderhoudt kan doen, komt neer op vier doelen, en voor geen ervan hoeft het kwetsbaarheden te zoeken:
De secties “Beperken waar een kwetsbaarheid toegang toe geeft” en “Direct gewaarschuwd worden” behandelen de eerste twee doelen. De secties over dependencies, over updates en over de manier van opleveren behandelen het derde, en de sectie “WordPress-site gehackt of kwetsbaarheid ontdekt” het vierde.
Volgens M-Trends 2026 is de mediane tijd tussen het binnendringen van een aanvaller in een systeem en de ontdekking ervan 14 dagen. In die tijd is de aanvaller actief: de eerste twee doelen beperken wat hij kan bereiken en hoe lang hij onopgemerkt blijft.
Een digitale dienst is meer dan een website. Een typische webapplicatie bestaat uit meerdere onderdelen: een toegangspunt dat de verzoeken van internet ontvangt en doorstuurt, de server die de code uitvoert, een database, back-ups, en de accounts van de mensen die het geheel beheren. Elk van die onderdelen kan zo worden ingericht dat een kwetsbaarheid in het ene geen toegang geeft tot alle andere. Dat heet gelaagde beveiliging, in het vak ook defense in depth genoemd.
Elk programma zo min mogelijk rechten geven. Het PHP-proces hoeft geen beheerder van de machine te zijn, en hoeft de code van de website niet te kunnen wijzigen. Het account waarmee het verbinding maakt met de database hoeft volgens de beveiligingsgids van WordPress alleen gegevens te kunnen lezen en schrijven; de rechten om te verwijderen, de structuur te wijzigen of rechten toe te kennen kunnen worden ingetrokken. Jez Humble en Dave Farley zeggen het in “Continuous Delivery”: de standaardinstellingen van besturingssystemen en databases zijn niet geschikt voor een applicatie in productie; er zijn firewalls nodig, overbodige diensten moeten uit, en databasegebruikers moeten precies de rechten krijgen die ze nodig hebben.
Ervoor zorgen dat de code niet vanuit de website kan worden gewijzigd. Kan het PHP-proces niet schrijven in de mappen met code, dan kan een aanvaller die het overneemt daar niet zo makkelijk een webshell neerzetten. WordPress voorziet hierin: alleen de map met geüploade content (wp-content) hoeft door de webserver te kunnen worden gewijzigd, en de code-editor in het beheerpaneel, volgens WordPress vaak “het eerste hulpmiddel dat een aanvaller gebruikt als hij erin slaagt in te loggen”, kan worden uitgeschakeld.
Netwerk segmenteren. De database hoeft niet vanaf internet bereikbaar te zijn: alleen de applicatieserver moet er verbinding mee kunnen maken. ANSSI vraagt het netwerk te segmenteren, de diensten die vanaf internet zichtbaar zijn af te schermen van de rest van het systeem, en de servers te beheren vanuit een apart netwerk (maatregelen 19, 23 en 28 van zijn gids).
Vooraf filteren, met kennis van de grenzen van het filter. Een webapplicatiefirewall, of WAF, onderzoekt de verzoeken voordat ze de server bereiken en blokkeert de verzoeken die op een bekende aanval lijken. De beveiligingsgids van WordPress raadt aan er een te installeren. Zo’n firewall heeft zijn grenzen: Cloudflare vraagt zelf om de patch te installeren, ook met zijn regels tegen PHP2Shell, en de CERT-FR benadrukt dat het de blokkade die het voorstelt niet zelf heeft getoetst. Een webapplicatiefirewall levert tijd op; hij vervangt de patch niet.
Geheimen uit de code halen. Wachtwoorden en toegangssleutels voor andere diensten (betalingen, e-mailverzending, opslag) horen niet in de codebestanden te staan. MITRE ATT&CK raadt een regel aan die het opslaan van wachtwoorden in bestanden verbiedt. Staan ze in de omgevingsvariabelen van de server of in een kluis voor geheimen, dan kan PHP ze nog steeds lezen terwijl het wordt uitgevoerd: dat beschermt ze niet tegen een overname van het PHP-proces. Wat u er naar ons idee mee wint, is dat ze niet meer in de geschiedenis van de code of in de back-ups ervan staan, en dat u ze kunt wijzigen zonder de code aan te passen. Dat telt op de dag dat ze allemaal vervangen moeten worden.
De accounts van mensen beschermen. Een aanvaller heeft niet altijd een kwetsbaarheid nodig: een hergebruikt wachtwoord is genoeg. ANSSI vraagt wachtwoorden te beschermen, standaardwachtwoorden te wijzigen en de voorkeur te geven aan sterke authenticatie (maatregelen 11 tot 13). Concreet raden wij een wachtwoordmanager aan, zodat iedereen per dienst een ander wachtwoord heeft, en tweestapsverificatie op de accounts die toegang geven tot de productie, de hosting en de code.
Handmatige wijzigingen in productie verbieden. In “Continuous Delivery Pipelines” stelt Dave Farley een doel: “alle menselijke schrijftoegang tot productiesystemen verwijderen”. Elke wijziging gaat via de deployment-pipeline. In “Continuous Delivery” voegen de twee auteurs eraan toe dat de productie afgesloten moet zijn voor buitenstaanders en voor mensen binnen het bedrijf, beheerteams inbegrepen. Zonder dat weet niemand meer wie wat heeft gedaan, en wanneer, als er iets misgaat.
Back-ups offline bewaren, en testen. Een back-up die bereikbaar is vanaf de gecompromitteerde server, kan samen met de rest worden versleuteld of gewist. ANSSI vraagt om een back-upbeleid met offline kopieën en hersteltests, met minstens één hersteloefening per jaar (maatregel 37). Een back-up die nooit is teruggezet, heeft nog niet bewezen dat hij werkt.
user (php.net). Instellingen die met php_admin_value en php_admin_flag zijn vastgelegd, kunnen niet met ini_set() worden gewijzigd. Stel PHP-FPM niet open op een adres dat van buitenaf bereikbaar is.expose_php = Off, display_errors = Off, allow_url_fopen = Off, allow_url_include = Off, open_basedir, disable_functions (system, exec, shell_exec, passthru, proc_open…), sessiecookies met secure, httponly en use_strict_mode. Maar de documentatie van PHP waarschuwt zelf dat disable_functions “kan worden omzeild” en dat open_basedir slechts “een extra vangnet is, verre van volledig”, dat de toegang tot Unix-sockets niet beperkt. Deze instellingen maken het vervolg van een aanval lastiger; ze voorkomen het niet, en PHP2Shell slaat toe voordat de applicatie wordt uitgevoerd.DROP, ALTER en GRANT kunnen worden ingetrokken, met in het achterhoofd dat sommige updates het schema wijzigen); wp-config.php met bestandsrechten 400 of 440; DISALLOW_FILE_EDIT; een webapplicatiefirewall, waarbij ModSecurity wordt genoemd als de meest gebruikte opensource-optie.Is de verdediging eenmaal op orde, dan moet u ook weten wanneer iemand erdoorheen komt. Het doel is drieledig: weten dat er iets abnormaals gebeurt, de toegang afsluiten, en dan achterhalen waar de aanval vandaan komt. In “Continuous Delivery” vragen Jez Humble en Dave Farley dat beheerteams “onmiddellijk op de hoogte worden gebracht” van een incident, en dat ze de tools hebben om de oorzaak te vinden. Ze wijzen ook op een veelgemaakte fout: fouten negeren in plaats van ze te loggen, waardoor ze niet te ontdekken zijn.
Een monitoringoplossing bewaakt specifieke signalen, en haar logs worden ergens anders bewaard dan op de bewaakte server. Beheerteams volgen de staat van de servers continu op dashboards, zoals Grafana of Kibana, die metingen en logs bundelen en een melding geven wanneer een drempel wordt overschreden. Dit zijn de signalen die deze meldingen moeten bewaken.
De webserver start een programma. Een webserver levert pagina’s; hij heeft geen enkele reden om een opdrachtinterpreter of een downloadtool te starten. Doet hij dat wel, dan wordt er vaak een webshell gebruikt (MITRE ATT&CK).
De server maakt verbinding met onbekende adressen. Cryptomining-software, een tool om een server op afstand over te nemen of een datalek: ze hebben allemaal uitgaande verbindingen nodig. Wij raden aan uitgaande verbindingen van de server standaard te blokkeren, behalve naar de diensten die de applicatie nodig heeft: dat beperkt ook het gebruik van zulke tools.
Een codebestand verandert. In productie verandert de code alleen bij een deployment. Een nieuw .php-bestand in de mappen van de website, buiten een deployment om, is een teken van inbraak. WordPress raadt aan de integriteit van bestanden te bewaken, en wijst erop dat een aanval “altijd sporen achterlaat, in de logs of in de bestanden”.
Er verschijnt een nieuw beheerdersaccount. ANSSI vraagt de inventaris van accounts met verhoogde rechten actueel te houden (maatregel 5). Een beheerdersaccount dat buiten elke procedure om is aangemaakt, is een signaal om op te volgen.
Het aantal fouten loopt op. ANSSI vraagt de fouten van webdiensten te loggen, met als voorbeelden de fouten 403, 404 en 500, en onverwachte stops (maatregel 36).
Logs buiten de server bewaren. Een aanvaller die de server in handen heeft, kan zijn sporen wissen in de logs die daar staan. ANSSI raadt daarom aan de logs centraal op een ander systeem te verzamelen, en beveiligingsgebeurtenissen minstens een jaar te bewaren.
Enkele opensourcetools, als voorbeeld:
/etc (documentatie van Falco).Een applicatie is niet volledig geschreven door de mensen die haar ontwikkelen. Ze steunt op componenten die door anderen zijn gepubliceerd, de dependencies, die door tools worden geïnstalleerd en bijgewerkt: Composer voor PHP, npm of pnpm voor JavaScript. En ze wordt uitgevoerd in een omgeving, PHP zelf, die wordt geleverd door het systeem van de server, door de hostingprovider of door de image waarmee ze wordt gedeployd.
In “Continuous Delivery” zijn Jez Humble en Dave Farley stellig: een project moet altijd “de exacte versie van de externe bibliotheken” vermelden die het gebruikt. Zonder dat, schrijven ze, kan wat in productie staat niet identiek opnieuw worden gebouwd. Naar ons idee weet u dan ook niet of u blootstaat aan een kwetsbaarheid.
Accepteert een project “elke versie vanaf deze”, dan komt een nieuw gepubliceerde versie bij de volgende update de applicatie binnen, zonder dat iemand ervoor heeft gekozen. Op dit moment is dat de standaardinstelling van npm (npm), en Composer raadt het aan voor bibliotheken die bedoeld zijn om door andere projecten te worden hergebruikt (Composer). De details van de notatie staan verderop, in het kader “Voor uw technische team”.
Niet elke nieuwe versie vraagt dezelfde aanpak. De patch voor een ernstige kwetsbaarheid installeert u zodra hij is gepubliceerd: wachten betekent de deur openlaten. Andere nieuwe versies kunnen een paar dagen wachten, omdat kwaadaardige code juist in een pas gepubliceerde versie binnensluipt. In 2018 nam een aanvaller het onderhoud van het pakket event-stream over en voegde er code aan toe die het gemunt had op de bitcoinwallets van de applicatie Copay (npm). In september 2025 werd het account van de maintainer van chalk, debug en een twintigtal andere JavaScript-pakketten gehackt via een valse e-mail om het wachtwoord opnieuw in te stellen; volgens StepSecurity, een bedrijf voor IT-beveiliging, werden die pakketten toen miljarden keren per week gedownload (StepSecurity). Een paar dagen later had de worm Shai-Hulud, die zich zelfstandig van pakket naar pakket verspreidde, er meer dan 500 gecompromitteerd; de CISA raadde toen aan dependencies vast te zetten op veilige versies, gepubliceerd vóór 16 september 2025 (CISA).
Daaruit volgen vier praktijken.
De exacte versie vastleggen in het bestand dat de dependencies declareert. De applicatie krijgt dan een nieuwe versie wanneer iemand daartoe besluit, niet wanneer die wordt gepubliceerd. Met een lockfile die samen met de code wordt vastgelegd (volgende praktijk), speelt een versiebereik alleen bij een update een rol. Het is dus op zichzelf geen kwetsbaarheid: de exacte versie is een teamafspraak, die van elke update een bewuste keuze maakt.
De lockfile bij de code bewaren. Dat bestand legt de exacte versie vast van elk geïnstalleerd component, ook van de componenten waarvan uw componenten afhankelijk zijn, en de documentatie van Composer vraagt het samen met de code van het project vast te leggen (Composer).
Installeren vanuit dat bestand, en alleen updaten na een besluit. De pipeline installeert precies de versies uit de lockfile. Over een update wordt per component besloten, en hij wordt getest.
Wachten voordat u een pas gepubliceerde versie overneemt. De pakketbeheerder pnpm biedt die wachttijd aan, sinds versie 11 standaard ingesteld, op dit moment, op één dag, “om het risico te verkleinen dat gecompromitteerde of defecte pakketten worden geïnstalleerd”. Volgens de documentatie worden kwaadaardige versies meestal binnen een uur ontdekt en verwijderd (pnpm). De patch voor een ernstige kwetsbaarheid volgt die wachttijd niet: die installeert u zodra hij is gepubliceerd, nadat u hebt gecontroleerd dat hij echt is aangekondigd door de maker van de software of door de CERT-FR.
Het omgekeerde risico bestaat ook: versies vastzetten en ze nooit meer bijwerken. Volgens onze berekeningen op basis van de cijfers van W3Techs gebruikte in oktober 2026 bijna de helft van de PHP-websites een versie die het PHP-team niet meer patcht. Een exacte versie beschermt alleen als de updates volgen: vaak, één voor één, en gecontroleerd. Jez Humble en Dave Farley maken er een algemeen principe van: “als het pijn doet, doe het dan vaker, en haal de pijn naar voren”. Een update die elke week wordt gedaan, verandert weinig tegelijk; een update die twee jaar wordt uitgesteld, wordt een klus op zich.
Er worden elke dag nieuwe kwetsbaarheden gepubliceerd in code die zelf niet is veranderd. Een controle die alleen bij een wijziging wordt gestart, mist de kwetsbaarheden die in de tussentijd zijn gepubliceerd. Composer, de tool die de componenten van een PHP-applicatie beheert, kan de geïnstalleerde componenten vergelijken met de beveiligingsadviezen op Packagist, de belangrijkste repository van PHP-componenten, en meldt ook verlaten componenten (Composer). Start een geplande taak van de pipeline die controle elke dag, dan signaleert ze een kwetsbaarheid zodra het beveiligingsadvies is gepubliceerd. In “Continuous Delivery Pipelines” vraagt Dave Farley om beveiliging in de pipeline te testen, vanaf de eerste stap, en niet als losse controle te behandelen.
Eén keer per week somt een andere controle de componenten op waarvoor een nieuwe versie bestaat. Die herinnering voorkomt de achterstand van twee jaar.
Niet elke melding vraagt dezelfde reactie. Twee gegevens bepalen de urgentie. Eerst de ernst: de meeste beveiligingsadviezen geven een CVSS-score, van 0 tot 10, die FIRST, de internationale organisatie die deze schaal publiceert, in vijf niveaus indeelt: geen (0), laag (0,1 tot 3,9), gemiddeld (4 tot 6,9), hoog (7 tot 8,9) en kritiek (9 tot 10) (CVSS 4.0). De PHP2Shell-kwetsbaarheden scoren 9,2: kritiek. Die score vergelijkt de ernst van een kwetsbaarheid met die van andere; hij meet niet het risico voor uw bedrijf.
Dan het misbruik: een kwetsbaarheid die al wordt misbruikt, gaat vóór een ernstigere die dat nog niet wordt. De CISA houdt de lijst van misbruikte kwetsbaarheden bij: het legt Amerikaanse federale overheidsinstanties termijnen op om ze te patchen, en raadt elke organisatie aan ze met voorrang aan te pakken. FIRST publiceert elke dag de EPSS, een schatting van de kans dat een kwetsbaarheid binnen dertig dagen wordt misbruikt. In Frankrijk maakt de CERT-FR onderscheid tussen zijn waarschuwingen, “bedoeld om te waarschuwen voor een direct gevaar”, en zijn adviezen, die kwetsbaarheden beschrijven en de manieren om u ertegen te beschermen. Voor PHP2Shell werd een waarschuwing uitgegeven.
In de praktijk wordt een kwetsbaarheid die kritiek is, al wordt misbruikt of onder een waarschuwing van de CERT-FR valt, gepatcht op de dag dat de patch wordt gepubliceerd. De andere volgen het normale ritme van de updates, één tegelijk.
Deze tools hebben een beperking, en PHP2Shell laat die zien. Ze onderzoeken de bibliotheken die de applicatie declareert, niet de taal die haar uitvoert. Een componentencontrole zonder meldingen zegt niets over PHP2Shell. De PHP-versie bewaakt u apart: het PHP-team publiceert de lijst van ondersteunde versies en een nieuwsfeed van zijn releases; de CERT-FR publiceert zijn waarschuwingen, en ANSSI vraagt via dat kanaal op de hoogte te blijven van nieuwe kwetsbaarheden (maatregel 34). ANSSI vraagt ook te anticiperen op het einde van het onderhoud van software (maatregel 35): PHP 8.2 krijgt na 31 december 2026 geen onderhoud meer.
Een composer.json met exacte versies (namen van componenten als voorbeeld):
{
"require": {
"vendor/component-a": "2.3.1",
"vendor/component-b": "5.0.4"
}
}
In plaats van "^2.3.1", dat elke versie vanaf 2.3.1 tot 3.0.0 (niet inbegrepen) zou accepteren (Composer). Op dit moment schrijft npm standaard ^: ^1.2.3 accepteert elke versie vanaf 1.2.3 en vóór 2.0.0 (node-semver). Bij npm zorgt save-exact=true in .npmrc ervoor dat standaard de exacte versie wordt vastgelegd (npm).
Een voorbeeld van een GitLab-pipeline, ter illustratie en aan te passen: een controle bij elke push, een dagelijkse taak en een wekelijkse taak, elk gestart door een eigen GitLab-planning (planningen, regels).
# Voorbeeld ter illustratie, aan te passen aan uw project
stages: [commit, audit]
.php:
# Image van uw project met PHP en Composer, vastgezet op zijn digest
image: registry.example/php-composer@sha256:<digest>
commit:
extends: .php
stage: commit
script:
# Controleert of composer.json en composer.lock met elkaar overeenkomen
- composer validate --strict
# Faalt als een component, voor productie of voor ontwikkeling, een beveiligingsadvies heeft
- composer audit --locked
# Installeert precies de versies uit de lockfile
- composer install --no-interaction --prefer-dist
rules:
- if: $CI_PIPELINE_SOURCE == "push"
daily-audit:
extends: .php
stage: audit
script:
# Dezelfde controle elke dag, zonder codewijziging; faalt ook bij verlaten componenten
- composer audit --locked --abandoned=fail
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "daily"
weekly-reminder:
extends: .php
stage: audit
script:
# Somt de beschikbare nieuwe versies op, zonder de pipeline te laten falen: dit is de herinnering
- composer outdated --direct
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_KIND == "weekly"
composer.lock, of package-lock.json bij npm) wordt samen met de code vastgelegd. De pipeline start composer install, dat precies de versies uit dat bestand installeert; composer update berekent de versies opnieuw en herschrijft het bestand: dat dient alleen voor een update waartoe is besloten, bijvoorbeeld composer update vendor/component-a (Composer).minimumReleaseAge bij pnpm, min-release-age bij npm (namen van de instellingen in oktober 2026). Bij Composer raden wij aan die wachttijd te bewaken met een teamafspraak, of met de tool die de updates voorstelt.composer audit geeft een exitcode die niet nul is wanneer een component onder een advies valt: de taak wordt rood, en dat is de melding. --locked leest de lockfile, ook zonder vendor-map (Composer): daarom voert het voorbeeld de controle uit vóór composer install, en stopt de taak voordat een component met een advies wordt geïnstalleerd. Het voorbeeld controleert ook de ontwikkelcomponenten: die worden uitgevoerd in de pipeline, die toegang heeft tot de code en tot de geheimen voor de deployment.php, vandaar de projectimage in het voorbeeld.@sha256:…), de hash die een image identificeert: volgens de documentatie van Docker krijgt u dan altijd dezelfde image, met de waarschuwing dat de image geen updates meer ontvangt, “die beveiligingspatches kunnen bevatten” (Docker). Vastzetten heeft dus alleen zin als de digest regelmatig wordt bijgewerkt, getest door de pipeline.integrity), en de installatie faalt als het gedownloade pakket niet overeenkomt. Bij een script of een stylesheet die van een ander domein wordt geladen, laat het attribuut integrity (Subresource Integrity) de browser een gewijzigd bestand weigeren (MDN); ANSSI raadt die controle aan voor JavaScript- en CSS-bronnen, intern en van derden, in het bijzonder die van een CDN (aanbevelingen R11 en R12). OWASP vraagt de controle van hashes en handtekeningen van gedownloade pakketten in te schakelen. Renovate of Dependabot kunnen deze updates voorstellen als merge requests; ze deployen zelf niets (Renovate, Dependabot).https://www.php.net/feed.atom) en de waarschuwingen van de CERT-FR. OSV-Scanner, van Google, leest op dit moment composer.lock en, in een containerimage, de pakketten van Alpine en van Debian of Ubuntu: zo kan het een PHP opsporen dat via het systeem van de image is geïnstalleerd.Het Britse NCSC vraagt alle organisaties “software-updates zo snel mogelijk te installeren, en idealiter automatisch”, omdat aanvallers vaak een gepatchte kwetsbaarheid bestuderen om er een exploit voor te schrijven; volgens Amazon, hierboven geciteerd, maakt AI dat werk goedkoper. Het NCSC wijst erop dat de maker zijn updates zelf test, maar vraagt ze ook op de eigen systemen te testen en ze gefaseerd uit te rollen. Voor software die u installeert en ongewijzigd gebruikt (Windows, macOS, een telefoon, een browser, kantoorsoftware), raden wij dus aan de automatische updates van die software in te schakelen. Bij een onlinedienst is het de leverancier die de patches installeert. Een WordPress-site valt in geen van beide categorieën: de eigenaar ontwikkelt de software niet en gebruikt haar ook niet ongewijzigd, hij stelt haar samen en configureert haar. Voor een site of een applicatie die u samenstelt, is ons standpunt anders.
WordPress wordt in oktober 2026 gebruikt door bijna vier op de tien websites, en de meeste kwetsbaarheden zitten niet in WordPress zelf. Volgens Patchstack werden in 2025 11.334 nieuwe kwetsbaarheden gevonden in het WordPress-ecosysteem: 91 % in plugins, 9 % in thema’s, en maar 6 in de kern van WordPress. En voor 46 % van die kwetsbaarheden had de ontwikkelaar op het moment van publicatie nog geen patch uitgebracht (Patchstack). Deze cijfers komen van een bedrijf dat bescherming tegen deze kwetsbaarheden verkoopt.
Ons standpunt is als volgt: wij raden automatische updates van PHP, plugins en thema’s af. Wij geven de voorkeur aan vastgezette versies, en één update tegelijk, getest voordat hij de productie bereikt: door de deployment-pipeline bij een applicatie op maat, op een kopie van de site bij een WordPress-site, zo mogelijk gecontroleerd door geautomatiseerde tests. Dit standpunt is niet alleen het onze. In “Continuous Delivery” vragen Jez Humble en Dave Farley de exacte versie van elke externe bibliotheek te vermelden en elke wijziging te controleren op een omgeving die op productie lijkt. OWASP vraagt in zijn ranglijst 2025 van de meest kritieke risico’s voor webapplicaties om “bewust de versie van elke dependency te kiezen, en alleen te updaten wanneer dat nodig is”, en om “te vermijden dat updates op alle systemen tegelijk worden uitgerold”. Zijn ranglijst van de risico’s die specifiek zijn voor CI/CD-pipelines vraagt tools niet zo in te stellen dat ze altijd de nieuwste versie van een pakket ophalen. De reden ligt in de aard van het ecosysteem. Een WordPress-site combineert de kern van WordPress, een PHP-versie, en plugins en thema’s van auteurs die los van elkaar werken. Niets garandeert dat de nieuwe versie van een plugin werkt met de versie van een andere, of met de PHP-versie van de server. Toch zet een automatische update de nieuwe versie in productie, zonder dat een test heeft gecontroleerd of de site nog werkt.
WordPress kiest standaard het omgekeerde standpunt. Op dit moment (oktober 2026) worden sinds WordPress 3.7 de kleine updates van de kern standaard automatisch geïnstalleerd (WordPress). Voor plugins en thema’s moeten automatische updates sinds WordPress 5.5 één voor één worden ingeschakeld, en WordPress voert ze dan twee keer per dag uit. Dezelfde pagina van WordPress begint met deze zin: “Om uw WordPress-site veilig te houden, moet u uw plugins en thema’s altijd bijwerken naar hun nieuwste versie” (WordPress). Dat geeft automatische updates een echt voordeel: tegenover een mediane tijd van vijf uur, gemeten in 2025, tussen de publicatie van een veel misbruikte kwetsbaarheid en het eerste misbruik, is een automatische update die twee keer per dag wordt uitgevoerd sneller dan een handmatige update die één keer per maand gebeurt.
Ons standpunt veronderstelt dus iemand die het onderhoud verzorgt. Wat wordt geautomatiseerd, zijn de meldingen: een melding wanneer een kwetsbaarheid de geïnstalleerde versies treft, een melding wanneer er iets abnormaals op de server gebeurt, een teken dat een kwetsbaarheid misschien wordt misbruikt. Het is aan een mens om te beslissen wanneer er wordt bijgewerkt, en dat dan meteen te doen, zonder te wachten. De update zelf wordt wel geautomatiseerd: de beheerder start hem met één klik, en hij wordt getest voordat hij de productie bereikt, door de pipeline bij een applicatie op maat, op een kopie van de site bij WordPress, binnen de uren die volgen. Zonder deze organisatie laten vastgezette versies de site langer blootgesteld dan een automatische update.
Twee andere factoren tellen even zwaar. Omdat in 2025 bijna de helft van de kwetsbaarheden in plugins op de dag van publicatie geen patch had, dekt geen enkel updatebeleid, automatisch of handmatig, ze op die dag. Minder geïnstalleerde plugins betekent minder mogelijke kwetsbaarheden: OWASP, de toonaangevende stichting voor de beveiliging van webapplicaties, vraagt overbodige dependencies te verwijderen, en ANSSI de afhankelijkheden tussen software te beperken. En een plugin die door zijn auteur is verlaten, krijgt geen patches meer: die vervangt u.
Tot slot werken updates van WordPress alleen WordPress bij. Geen enkele raakt PHP. PHP wordt geleverd door de hostingprovider of door het systeem van de server: daarom verwijst het PHP-team naar de Linux-distributie of de leverancier die PHP op lange termijn onderhoudt. PHP bijwerken voor een WordPress-site gebeurt dus bij de hostingprovider, of in de omgeving waarmee de site wordt gedeployd.
Voor een WordPress-site hoeft u dit onderhoud niet zelf te verzorgen. Cybermalveillance.gouv.fr, de Franse publieke dienst die slachtoffers van cyberaanvallen helpt, presenteert zijn goede praktijken voor de beveiliging van een website als maatregelen “om zelf toe te passen of door uw leverancier te laten toepassen”. Hostingproviders die gespecialiseerd zijn in WordPress zorgen voor de updates van de serversoftware, waaronder PHP, en voor automatische back-ups. De beveiligingsgids van WordPress beschrijft de betrouwbare hostingprovider: die “levert de meest recente stabiele versies van alle serversoftware” en “betrouwbare methoden voor back-up en herstel”, en praat graag over de beveiligingsmaatregelen die hij biedt. Vraag hem voordat u kiest of hij PHP zelf bijwerkt, of hij updates test op een kopie van de site voordat hij ze toepast, en hoe u een back-up terugzet.
Ook een applicatie op maat wordt bijgewerkt na een bewuste beslissing. Het Cyber Essentials-kader van het Britse NCSC sluit de op maat ontwikkelde onderdelen van webapplicaties uit van zijn reikwijdte, en beveelt daarvoor “zorgvuldige ontwikkeling en grondige tests” aan. Elke update, van PHP of van een component, gaat door de deployment-pipeline en zijn geautomatiseerde tests, en gaat dan nog op de dag van publicatie naar productie.
Alles verandert op de dag dat u de code moet aanraken. De eerste regel van WordPress geldt voor iedereen: “raak de kern van WordPress niet aan”, omdat elke update de bestanden ervan overschrijft; wat u wilt toevoegen of wijzigen, gaat via een plugin. Bij een thema kunt u met een childthema het thema aanpassen zonder de code ervan aan te raken, en toch de updates blijven ontvangen. Die maatwerkcode, childthema of plugin, is software die u ontwikkelt. In “Continuous Delivery” vragen Jez Humble en Dave Farley alles wat dient om de software te bouwen en te deployen onder versiebeheer te houden, en elke wijziging door de deployment-pipeline te laten gaan. Concreet staat die code in een Git-repository en gaat ze via de pipeline naar productie, nooit met de hand naar de server gekopieerd.
Niemand hoeft de kern van WordPress aan te passen. Wat een standaardinstallatie mist, zit ergens anders. Plugins worden geïnstalleerd vanuit het beheerpaneel, zonder dat hun versies ergens worden vastgelegd, en de configuratie staat in één bestand, hetzelfde voor alle omgevingen. U kunt de site die in productie staat dus niet identiek nabouwen op een testomgeving, terwijl Jez Humble en Dave Farley dat wel vragen. Dat gat vult Bedrock, van Roots. Het past de kern van WordPress niet aan: het pakt hem in. WordPress, de plugins en de thema’s worden er dependencies, die Composer in een precieze versie installeert en vergrendelt in composer.lock. De configuratie verschilt per omgeving (ontwikkeling, acceptatie, productie) via omgevingsvariabelen. De Git-repository bevat alleen nog de maatwerkcode, de configuratie en de lijst van dependencies, en volgens Roots kunnen de kern en de plugins buiten de ontwikkelomgeving niet meer worden gewijzigd. Roots presenteert deze opzet als de toepassing op WordPress van de methode “The Twelve-Factor App” (de applicatie in twaalf factoren), die beschrijft hoe u webapplicaties bouwt die makkelijk te deployen en te onderhouden zijn. Updates gebeuren dan in de code, één plugin tegelijk, en gaan daarna door de pipeline. De standaardconfiguratie van Bedrock schakelt op dit moment de automatische updates en het installeren van plugins vanuit het beheerpaneel uit (config/application.php).
Naar ons idee is Bedrock de moeite waard zodra een WordPress-site als software wordt onderhouden: maatwerkcode, meerdere omgevingen, een ontwikkelteam, een pipeline. Voor een site die u configureert, met een childthema of een plugin erbij, is het niet nodig. En Bedrock organiseert het project, meer niet: de kwaliteit van de maatwerkcode blijft de zaak van wie haar ontwikkelt.
// config/application.php van Bedrock, standaardconfiguratie
// Schakelt de automatische updates van WordPress uit
Config::define('AUTOMATIC_UPDATER_DISABLED', true);
// Schakelt de bestandseditor in het beheerpaneel uit
Config::define('DISALLOW_FILE_EDIT', true);
// Verbiedt het installeren of bijwerken van plugins vanuit het beheerpaneel
Config::define('DISALLOW_FILE_MODS', true);
# Met Bedrock: één plugin bijwerken, in de code, en daarna via de pipeline
composer update wp-plugin/plugin-name
Zonder Bedrock raadt de gids van WordPress over het versterken van de beveiliging aan de bestandseditor in het beheerpaneel uit te schakelen, waarmee standaard de PHP-code van plugins en thema’s kan worden gewijzigd; de gids benadrukt dat dit niet alles tegenhoudt, maar sommige aanvallen wel kan stoppen (WordPress):
// In wp-config.php: schakelt de bestandseditor in het beheerpaneel uit
define( 'DISALLOW_FILE_EDIT', true );
Om één plugin tegelijk bij te werken, houdt u met WP-CLI, de opdrachtregeltool van WordPress, de controle: wp plugin update accepteert --version om een precieze versie te kiezen, --patch om alleen de bugfixes te nemen, en --dry-run om te zien wat er zou worden bijgewerkt zonder iets te wijzigen (WP-CLI). De documentatie van WordPress zelf noemt aanpassingen en het vooraf testen op een acceptatieomgeving als redenen om automatische updates uit te schakelen, en vraagt, voordat u ze voor plugins inschakelt, dat u kunt terugkeren naar de vorige versie van de site.
Alles hiervoor steunt op één vermogen: een patch nog dezelfde dag in productie zetten, zonder iets kapot te maken. Dat vermogen wordt niet op de dag van de waarschuwing geïmproviseerd. Het hangt af van de manier waarop de software dagelijks wordt opgeleverd.
In onze ervaring komt een kritieke kwetsbaarheid als een onverwachte gebeurtenis in een organisatie waar elke release een zeldzame operatie is (één avond per kwartaal, handmatige tests, meerdere mensen die moeten worden ingezet). Er moet buiten de planning om een spoedcorrectie worden opgezet, de mensen die kunnen deployen moeten bij elkaar komen, de tests moeten opnieuw met de hand, er moet een onderhoudsvenster worden gereserveerd, en soms is de goedkeuring van een comité nodig. De patch wordt een project, en ondertussen blijft de applicatie blootgesteld. Bij zo’n ritme ligt het voor de hand om rechtstreeks op de server te sleutelen, met de hand. In “Continuous Delivery” wijzen Jez Humble en Dave Farley die kortere weg onomwonden af: bij een kritiek defect “omzeil onder geen beding uw proces”. Ze wijzen er ook op dat het soms beter is terug te gaan naar de vorige versie dan een correctie te deployen. Een correctie die met de hand in productie wordt gedaan, is niet getest, kan het probleem verergeren, en wordt vaak nergens vastgelegd.
Bij Continuous Delivery, toegepast binnen een adaptieve aanpak, dat wil zeggen door de software continu bij te sturen op basis van het gebruik ervan, is dezelfde patch een wijziging als alle andere. Jez Humble definieert Continuous Delivery als “het vermogen om wijzigingen van alle soorten, waaronder nieuwe functionaliteiten, configuratiewijzigingen, bugfixes en experimenten, veilig, snel en duurzaam in productie of in handen van gebruikers te brengen” (continuousdelivery.com). Dave Farley zegt erbij dat de deployment-pipeline “de ENIGE weg naar productie” is: elke wijziging gaat erdoorheen, de update van PHP net zo goed als de nieuwe functionaliteit. Ze ondergaat dezelfde geautomatiseerde tests en gaat daarna naar productie. Omdat elke wijziging die weg volgt, is de procedure al ingeslepen op de dag dat er een patch komt.
Deze discipline verandert ook de manier waarop het project wordt gestuurd. Een kritieke kwetsbaarheid wordt niet ingepland voor het eind van de week: ze gaat nog dezelfde dag voor al het andere. Een team dat de discipline van Continuous Delivery volgt, kan in de loop van de dag zijn prioriteiten aanpassen aan wat er gebeurt, omdat niets van wat in uitvoering is de release van de patch blokkeert.
DORA (DevOps Research and Assessment), het onderzoeksprogramma van Google Cloud naar hoe software wordt ontwikkeld en in productie gaat, meet wat deze praktijk verandert. DORA meet niet rechtstreeks hoe lang het duurt voordat een patch is geïnstalleerd. De indicator die er het dichtst bij komt, is de doorlooptijd van een wijziging, vanaf het moment dat ze in de code wordt vastgelegd tot het moment dat ze in productie staat. In “Modern Software Engineering” stelt Dave Farley een verwante vraag: hoe lang duurt het voordat een wijziging van één regel van idee werkende software wordt? Naar ons idee is dat ook de tijd die het installeren van de volgende beveiligingspatch zal kosten. Het onderzoek van DORA laat steeds weer zien dat “snelheid en stabiliteit geen compromissen zijn” (DORA). Volgens een samenvatting van het rapport van 2024, gepubliceerd door Octopus Deploy, een maker van deploymenttools, zetten de best presterende teams een wijziging in minder dan een dag in productie, en herstellen ze in minder dan een uur van een mislukte release (Octopus Deploy).
Goedkeuringscomités voor wijzigingen maken een trage oplevering niet goed. In “Modern Software Engineering” citeert Dave Farley het onderzoek uit het boek Accelerate: “goedkeuring door een externe instantie, zoals een manager of een comité voor de goedkeuring van wijzigingen, verhoogt de stabiliteit van productiesystemen eenvoudigweg niet […] Het is zelfs slechter dan helemaal geen goedkeuringsproces voor wijzigingen.”
De beveiligingsrichtlijnen hanteren een andere termijn. ANSSI vraagt in zijn gids van 2017 beveiligingspatches toe te passen “binnen de maand na hun publicatie door de maker”, en voorziet in een eventuele kwalificatie van de patches en een geleidelijke uitrol (maatregel 34). OWASP waarschuwt in zijn ranglijst 2025 van de tien meest kritieke risico’s voor webapplicaties voor dit ritme: de blootstelling “ontstaat vaak in omgevingen waar patchen een maandelijkse of driemaandelijkse taak is onder change control, waardoor organisaties dagen of maanden blootstaan aan kwetsbaarheden die al zijn gedicht”. De termijn van een maand dateert van 2017, van vóór de periode waarin de tijd tot misbruik terugliep tot enkele dagen, en wordt gepresenteerd als een maximum. Nu aanvallen soms beginnen voordat de patch is gepubliceerd, volstaat hij niet meer als doel. De controle van patches die ANSSI vraagt, dwingt niet tot een maand wachten: geautomatiseerde tests in de pipeline voeren die controle bij elke wijziging uit.
In een toespraak voor de Economic Club of Chicago wees Jamie Dimon, bestuursvoorzitter en CEO van JPMorgan Chase, volgens Business Insider van 16 oktober op twee risico’s: AI-agents die handelingen verrichten op de bankrekeningen van hun gebruikers, en AI-tools die kwetsbaarheden eerder blootleggen. Om namens hun gebruikers te betalen, hebben die agents hun bankcode nodig: “als ze betalingen voor u kunnen doen, moet u ze uw bankcode geven […] u gaat ervan uit dat ze correct namens u zullen handelen, en dat is misschien niet zo”. De dag ervoor, bij de presentatie van de kwartaalcijfers van de bank, had hij gewaarschuwd dat JPMorgan “niet zomaar elke externe agent het bedrijf binnenlaat”. Op dit moment verhindert JPMorgan dat externe AI-agents handelingen verrichten op de rekeningen van zijn particuliere klanten, en geeft het ze alleen leestoegang. Volgens Benzinga waarschuwde hij ook dat AI-tools honderden ernstige kwetsbaarheden blootleggen in opensourcecode, waardoor sectoren “volledig onbeschermd” achterblijven.
Voor de kwetsbaarheden die AI eerder blootlegt, verkort Continuous Delivery de tijd die het kost om de patch te installeren. Al in 2010 vroegen Jez Humble en Dave Farley in “Continuous Delivery” om snel een nieuwe versie te kunnen uitbrengen “voor het geval er kritieke defecten of beveiligingslekken worden ontdekt”. Ze vroegen ook dat de productie “volledig afgesloten” is, zodat alleen de deployment-pipeline er wijzigingen in kan aanbrengen. Met die praktijken en de praktijken die in de sectie over de manier van opleveren staan beschreven, gaat de patch voor een kwetsbaarheid die door AI is gevonden naar productie zoals elke andere wijziging. Naar ons idee verkort Continuous Delivery de tijd waarin een kwetsbaarheid waarvoor al een patch bestaat bij u misbruikt kan worden; kwetsbaarheden vinden en aanvallen stoppen hoort bij de andere praktijken die in dit artikel worden beschreven.
Het andere risico dat Jamie Dimon beschrijft, gaat over toegangsrechten: weten of een agent echt handelt voor de persoon die hem toestemming heeft gegeven, bij een bank net als bij elke applicatie. OWASP rekent “buitensporige autonomie” tot de risico’s van AI-applicaties, en het Britse NCSC vraagt op agents het principe van zo min mogelijk rechten toe te passen. Laat uw applicatie AI-agents handelen voor uw gebruikers, dan raden wij, net als OWASP, aan ze alleen de minimaal nodige rechten te geven, ze te laten handelen in de context van de betrokken gebruiker, en acties met grote impact door een mens te laten goedkeuren.
Op de dag dat een kwetsbaarheid uw software treft, bestaat de aanpak uit acht stappen. Ze steunt op vier openbare documenten: de gids “Wat te doen bij een cyberaanval?” van cybermalveillance.gouv.fr, geschreven voor bestuurders; de checklist van dezelfde dienst over het bekladden van een website; de gids voor digitale hygiëne van ANSSI; de checklist van de CERT-FR, waarnaar zijn waarschuwing over PHP verwijst. Lees deze stappen liever vóór die dag, en spreek af wie wat doet.
1. Nagaan of u blootstaat. Welke websites en applicaties gebruiken het getroffen component, in welke versie, op welke servers, bij welke hostingprovider? Bij PHP2Shell geldt de vraag ook voor producten die PHP bevatten zonder dat het zichtbaar is. Beheert een leverancier of een hostingprovider uw website, dan is dit de eerste vraag die u hem stelt. Houd een logboek bij van elke actie, bewaard buiten het getroffen systeem, zoals de CERT-FR vraagt.
2. Bijwerken, of isoleren. De volledige bescherming is de update: bij PHP2Shell PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35, of een nieuwere versie uit dezelfde reeks, of de patch van uw distributie. Omdat de ondersteuning van PHP 8.2 op 31 december 2026 stopt, kunt u beter overstappen op PHP 8.3 of nieuwer. Is de update niet meteen mogelijk, isoleer dan de applicaties die vanaf internet bereikbaar zijn totdat ze dat wel is, zoals de CERT-FR en de CERT-EU adviseren.
Let op één valkuil: bij PHP2Shell beschermt de onderhoudsmodus van een WordPress-site of een Laravel-applicatie niet tegen deze kwetsbaarheid. De kwetsbaarheid slaat toe terwijl PHP het verzoek voorbereidt, voordat de code van de site wordt uitgevoerd. De blokkade moet vóór PHP plaatsvinden: op de webserver of de reverse proxy, die een statische pagina terugstuurt, of op netwerkniveau.
Lijkt de server gecompromitteerd, dan geeft ANSSI de juiste reflex: koppel de machine los van het netwerk, maar laat haar aanstaan en start haar niet opnieuw op, om de informatie die nodig is voor het onderzoek niet kwijt te raken (maatregel 40).
3. Zoeken naar sporen van inbraak. Amazon raadt aan minstens terug te zoeken tot 17 oktober, en niet pas vanaf de dag van publicatie. Bij PHP2Shell: ongebruikelijke uploadverzoeken gevolgd door geheugenfouten of herhaalde 500-fouten, abnormaal lange of misvormde sessiecookies, onverklaarde herstarts van PHP (Patchstack). Meer in het algemeen de signalen uit de sectie over monitoring: nieuwe bestanden in de mappen van de site, programma’s die door de webserver worden gestart, onbekende uitgaande verbindingen, nieuwe beheerdersaccounts. Patchstack raadt aan een server die het doelwit was als mogelijk gecompromitteerd te behandelen.
4. Bewijs veiligstellen vóór het opschonen. Cybermalveillance.gouv.fr vraagt de logs van de firewall, de reverse proxy en de getroffen servers veilig te stellen, en een volledige kopie te maken van de aangevallen machine en haar geheugen. De gids voor bestuurders vraagt aangifte te doen “vóór elke herstelactie”. Wie een schone versie opnieuw deployt vóór die kopie, wist juist wat zou helpen begrijpen wat er is gebeurd.
5. Alle geheimen wijzigen die de server bevatte. Wij raden aan de wachtwoorden van de database te wijzigen, net als de sleutels van de applicatie (sleutels en salts van WordPress, APP_KEY van Laravel, versleutelingssleutel van Magento), de toegangssleutels voor diensten van derden (betalingen, e-mailverzending, opslag), de accounts voor het versturen van berichten, de deploymenttokens op de server, de privésleutels van de certificaten en de beheerdersaccounts, en de openstaande sessies te beëindigen. De nieuwe geheimen worden gegenereerd vanuit een schone omgeving en alleen gedeployd op de server die in de volgende stap opnieuw wordt opgebouwd, nooit op de server die nog gecompromitteerd is. De CERT-FR vraagt “mogelijk gecompromitteerde geheimen te wijzigen”, cybermalveillance.gouv.fr alle wachtwoorden te wijzigen voordat de site weer online gaat. CosmicSting liet het zien: een sleutel die vóór de patch is gestolen, blijft daarna geldig, en Sansec raadt aan de versleutelingssleutel te vervangen en de oude ongeldig te maken. Het wijzigen van de applicatiesleutel logt alle gebruikers uit; dat is de bedoeling. Let wel op gegevens die met de oude sleutel zijn versleuteld: die worden onleesbaar, tenzij de oude sleutel beschikbaar blijft om ze te ontsleutelen of ze opnieuw worden versleuteld met de nieuwe. Laravel laat u oude sleutels bewaren om te ontsleutelen (APP_PREVIOUS_KEYS), en Adobe biedt voor Magento een procedure om de sleutel te wijzigen en een opdracht die de gegevens opnieuw versleutelt.
6. Is de server gecompromitteerd, bouw dan opnieuw op vanuit een schone bron. Wij raden af de oude serverimage of de oude code terug te zetten, want die kunnen de webshell bevatten. Met een pipeline bouwt u de server en de applicatie opnieuw op vanuit de coderepository, in een schone versie, met de patch. De gegevens zet u naar ons idee terug vanuit een back-up van vóór de vroegst mogelijke datum van inbraak. Daar maken offline en geteste back-ups het verschil. Cybermalveillance.gouv.fr vraagt daarna de systemen geleidelijk weer in gebruik te nemen, nadat is vastgesteld dat de kwetsbaarheid is gedicht.
7. Melden. Konden persoonsgegevens worden ingezien, gewijzigd of vernietigd, dan moet het incident binnen 72 uur worden gemeld bij de CNIL, de Franse toezichthouder op persoonsgegevens, herinnert cybermalveillance.gouv.fr. Meld de schade ook bij uw verzekeraar. Voor begeleiding raadt ANSSI aan een gekwalificeerde dienstverlener voor de afhandeling van beveiligingsincidenten in te schakelen (maatregel 40 van zijn gids). In Frankrijk zijn politie en gendarmerie in noodgevallen bereikbaar via 17.
8. Lessen trekken. Stel de vraag die cybermalveillance.gouv.fr in de laatste stap van zijn gids stelt: wat hebben we geleerd? Hoe lang duurde het om de patch te installeren, en waarom? Dat is de tijd waarvan DORA de indicator meet die er het dichtst bij komt, hierboven beschreven: hoe korter die in het dagelijks werk is, hoe eerder de volgende patch na publicatie wordt geïnstalleerd. Wat maakte het mogelijk, of had het mogelijk gemaakt, de aanval op te merken?
Een beveiligingspatch is een wijziging als alle andere: hij gaat door dezelfde pipeline als de rest. Wij zoeken geen kwetsbaarheden; dat onderzoek is aan de onderzoekers. Wij zorgen ervoor dat de volgende kwetsbaarheid zo min mogelijk toegang geeft, dat we direct worden gewaarschuwd zodra ze wordt misbruikt, en dat de patch live gaat zodra hij is gepubliceerd.
Bij DEVEDANOS ontwikkelt, test, deployt en onderhoudt hetzelfde team uw software continu, in dezelfde pipeline. Elke productie-deployment gaat door een deployment-pipeline: beveiliging, performance, toegankelijkheid, alles wordt automatisch geverifieerd voordat het productie bereikt. We zetten één wijziging tegelijk in productie, nadat de pipeline haar heeft gecontroleerd. Bij een incident gaan we terug naar de vorige versie.
Voor de applicaties die wij ontwikkelen, zetten we het volgende op met een deployment-pipeline. Elke dependency staat op haar exacte versie. Een nieuw gepubliceerde versie nemen we pas na drie dagen over, behalve de patch voor een ernstige kwetsbaarheid, die wordt geïnstalleerd zodra hij is gepubliceerd. Elke ochtend controleert een geplande taak of een bekende kwetsbaarheid de geïnstalleerde componenten treft. We zetten ook monitoring van de servers op, met meldingen op de hierboven beschreven signalen. Een update van PHP of van een component gaat door dezelfde pipeline als de rest.
Voor de ontwikkeling van software op maat werken we voor een vast budget, aan het einde van elke maand gefactureerd voor het geleverde werk. Uw applicatie is binnen een maand bruikbaar, met een paar essentiële functionaliteiten: uw gebruikers gaan er meteen mee aan de slag, en hoe ze ermee werken, bepaalt welke functionaliteiten we daarna ontwikkelen. Onderhoud is inbegrepen, ook adaptief onderhoud: updates van dependencies, beveiligingspatches, browsercompatibiliteit. En om ervoor te zorgen dat wat vorige maand werkte, ook deze maand werkt, hanteren we een nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.
Daarnaast bieden we audits van softwareproductieketens en trainingen voor technische teams. De audit controleert of de werkwijzen die dit artikel beschrijft aanwezig zijn in uw deployment-pipeline en in uw software, en wat er nog moet worden ingevoerd.
Een beveiligingsupdate bereikt de productie op de dag van publicatie wanneer elke wijziging er al in kleine stappen aankomt. Ons artikel over Continuous Delivery en Continuous Deployment legt uit hoe dat werkt, en ons artikel over de voorspellende of adaptieve aanpak waarom deze manier van opleveren bij een adaptieve aanpak hoort.
Wilt u een applicatie overnemen waarvan de PHP-versie niet meer wordt onderhouden, dan legt onze pagina over het vervangen of vernieuwen van verouderde software uit hoe we te werk gaan.
Wilt u een applicatie laten ontwikkelen, of weer grip krijgen op een bestaande? Zullen we erover praten?
DISALLOW_FILE_EDIT).config/application.php.save-prefix, save-exact, min-release-age).
GTA 6 twee keer uitgesteld, The Line ter discussie, Akon City opgegeven, publieke IT-projecten ver boven budget: waarom een schatting van iets nieuws geen stand houdt, en hoe men vroeger kathedralen bouwde.
Continuous Delivery en Continuous Deployment verschillen maar in één stap. Waarom een kleine, frequente wijziging minder riskant is dan een grote, met bronnen.
Wat is een feature flag? Vier typen toggles, wat u probeert voordat u er een toevoegt, en zeven anti-patterns waardoor code draait die nooit is getest.