Door Erik Jan Koedijk. Gepubliceerd op 21 oktober 2026. Laatste broncontrole: 21 oktober 2026, 9 PM CEST
ANP legde mij vandaag een begrijpelijke vraag voor: hoe groot is het probleem met de kwetsbaarheden in PHP en wat zijn de gevolgen? Als voormalig crisismanager Data & ICT heb ik ervaren hoe belangrijk het is dat bestuurders en technische teams elkaar tijdens een crisis begrijpen. Wat is er geraakt, wat kan blijven draaien en wie neemt welk besluit? Vanuit die ervaring deel ik hier de vragen die ik bestuurders vandaag zou meegeven. Je hoeft de techniek niet zelf op te lossen, maar je moet wel weten wat er op het spel staat en wat je team nodig heeft om te handelen.
Je zult maar een webshop hebben. Of verantwoordelijk zijn voor een gemeente waar inwoners online hun zaken regelen. Je leest over ernstige beveiligingsproblemen en vraagt je af: gebruiken wij dit ook? Moet onze website uit? En wie zoekt dat eigenlijk uit?
Dat zijn precies de vragen die je nu moet stellen. Je hoeft als bestuurder niet te kunnen programmeren. Maar je moet wel weten wie het overzicht heeft en wie beslist als de dienstverlening tijdelijk moet stoppen. Ondertussen kan een oplichter de onrust gebruiken om je medewerkers te benaderen. Daar kom ik verderop op terug.
Een onbekende term? Je vindt uitleg in de woordenlijst onderaan dit artikel.
Laatste ontwikkelingen:
CERT-EU: technische details en eerste demonstraties circuleren
CERT-EU meldt in zijn bijgewerkte waarschuwing dat technische details en eerste demonstraties van misbruik inmiddels openbaar circuleren. Dat vergroot de urgentie om kwetsbare systemen bij te werken.
Kan de beveiligingsupdate nog niet worden geïnstalleerd? Laat dan beoordelen of de getroffen toepassing tijdelijk van internet moet worden afgeschermd. CERT-EU adviseert die afscherming te overwegen totdat de reparatie is toegepast en gecontroleerd. Voor productie en gebouwbeheer vraagt dit afstemming tussen techniek, operatie en leverancier.
Bron: Bijgewerkt beveiligingsadvies van CERT-EU.
Update 21 oktober 2026, 9 PM CEST: beveiligingsupdates voor PHP beschikbaar + extra advies
De makers van PHP hebben beveiligingsupdates uitgebracht voor de twee kritieke kwetsbaarheden. De gerepareerde versies zijn PHP 8.2.35, 8.3.36, 8.4.27 en 8.5.12. Ook leveranciers kunnen bijgewerkte pakketten aanbieden waarin de reparaties zijn verwerkt.
Een belangrijk punt nog: het uitschakelen van upload progress is geen volledige oplossing. PHP bevestigt dat deze instelling bepaalde aanvalsroutes kan blokkeren, maar andere routes blijven bestaan. Tijdelijke instellingen vervangen de beveiligingsupdate dus niet.
Vraag je beheerder of hostingpartij nu om bevestiging dat de passende update voor jouw omgeving is geïnstalleerd en daadwerkelijk actief is. Laat ook controleren of websites, formulieren en koppelingen na het bijwerken goed werken.
Gebruik je een oudere versie van PHP? Vraag welke oplossing je leverancier biedt. Voor enkele oudere versies heeft het beveiligingsteam uitzonderlijk ook reparaties in broncode beschikbaar gesteld. Dat is geen hervatting van het reguliere onderhoud.
Bij aanwijzingen voor eerder misbruik blijft onderzoek nodig. Een update herstelt de kwetsbaarheid, maar verwijdert geen eerder geplaatste achterdeur.
Ook productie en gebouwbeheer verdienen aandacht
Deze waarschuwing gaat verder dan websites. Het NCSC benadrukt dat PHP ook ingebouwd kan zijn in netwerkapparaten, beheerinterfaces en andere producten. Een bijgewerkte website betekent dus niet dat alles binnen je organisatie is aangepakt.
Dat verdient ook aandacht bij operationele technologie, kortweg OT: systemen die bijvoorbeeld machines, productieprocessen of gebouwinstallaties aansturen en bewaken. Laat onderzoeken of de bijbehorende beheeromgevingen, monitoringsoftware of toegang voor onderhoud op afstand PHP gebruiken. Dat zijn plekken om te controleren, geen lijst van systemen waarvan vaststaat dat ze kwetsbaar zijn.
Vraag je technische team en leveranciers welke producten PHP bevatten, of deze kwetsbaarheden daarop van toepassing zijn en welke beveiligingsupdate beschikbaar is. Bij ingebouwde software moet de reparatie vaak via een update van het complete product komen.
Een concreet voorbeeld komt van Palo Alto Networks. De leverancier noemt zijn firewallsoftware PAN-OS en beheerplatform Panorama geraakt door de PHP kwetsbaarheden. In de geraadpleegde waarschuwing waren reparaties voor die producten nog aangekondigd. De leverancier adviseert de toegang tot de beheerinterface te beperken tot vertrouwde interne adressen.
Dit bewijst geen aanval op een productieomgeving. Het maakt wel duidelijk waarom ook netwerkapparatuur en beheerplatformen moeten worden gecontroleerd. De gevolgen verschillen per product: Palo Alto Networks beoordeelt het risico voor zijn producten vooral op verstoring van de beschikbaarheid.
Bron: Beveiligingsadvies van Palo Alto Networks.
Laat in een productieomgeving geen overhaaste wijzigingen uitvoeren. Stem updates en tijdelijke maatregelen af met de verantwoordelijken voor techniek, operatie en veiligheid. Beperk ondertussen onnodige toegang tot beheeromgevingen en laat beoordelen hoe getroffen systemen kunnen worden afgeschermd zonder een onveilige situatie te veroorzaken.
De vraag voor bestuurders is daarmee: hebben we alleen onze websites gecontroleerd of ook de systemen waarmee ons dagelijkse werk blijft draaien?
Bronnen: NCSC informatie over PHP2Shell en NCSC basisprincipes voor beveiliging van OT.
Wat weten we op dit moment?
Het beveiligingsteam van PHP heeft twee kritieke kwetsbaarheden bevestigd en beveiligingsupdates uitgebracht. Beide krijgen een technische ernstscore van 9,2 op 10. Een aanvaller kan hiermee onder bepaalde omstandigheden zonder in te loggen eigen code uitvoeren op een kwetsbare server. Wat hij vervolgens kan lezen, veranderen of beschadigen, hangt af van de rechten van het getroffen proces. Hij is daarmee niet automatisch beheerder van de hele organisatie.
PHP noemt het risico het grootst bij een veelgebruikte combinatie van PHP en webserver Apache, genaamd mod_php. Daar is een aanval aangetoond die al kan plaatsvinden voordat de code van de website wordt uitgevoerd. Ook een eenvoudige informatiesite is daarom niet vanzelf buiten gevaar.
Bron: Officieel beveiligingsadvies van PHP.
Aanvalspogingen op beide kwetsbaarheden gemeld
Beveiligingsbedrijf watchTowr meldt inmiddels actieve aanvalspogingen op beide PHP kwetsbaarheden. Eerder meldde Cloudflare al de eerste aanvallen te zien. Hoeveel pogingen slagen en welke organisaties daadwerkelijk zijn getroffen, blijkt niet uit deze meldingen.
Voor organisaties is dit reden om niet te blijven vertrouwen op tijdelijke bescherming. Laat bevestigen dat de passende beveiligingsupdate daadwerkelijk actief is en laat beschikbare loggegevens onderzoeken op verdachte activiteit. Een geïnstalleerde update vertelt immers niet of iemand daarvoor al is binnengekomen.
Bron: Actuele informatie van watchTowr over PHP2Shell.
Deze situatie verandert snel. Kijk voor de actuele getroffen versies en beschikbare updates bij PHP.
AI hielp onderzoekers de kwetsbaarheden te vinden
Beveiligingsbedrijf Wiz meldt dat het AI heeft gebruikt bij het onderzoek naar deze kwetsbaarheden. De PHP Foundation bevestigt dat meldingen van Wiz, Calif en OpenAI de volledige impact van een van de problemen duidelijk maakten. Dat laat zien hoe AI beveiligingsonderzoek kan ondersteunen. Het bewijst niet dat criminelen de gemelde aanvallen ook met AI uitvoeren.
Bronnen: Onderzoek van Wiz en toelichting van de PHP Foundation.
De gevolgen worden ook in Nederland zichtbaar
De waarschuwingen over PHP leidden op 21 oktober tot voorzorgsmaatregelen. NOS meldde die dag dat onder meer de websites van MijnOverheid, DigiD en de Tweede Kamer offline waren gehaald.
Ook het Nationaal Cyber Security Centrum en de Autoriteit Persoonsgegevens hebben volgens NOS hun website uit de lucht gehaald. Die meldingen bewijzen geen geslaagde inbraak. Een onbereikbare website van DigiD betekent bovendien niet automatisch dat ook de hele inlogdienst onbeschikbaar is.
Uit voorzorg een website uitschakelen kan een verstandige beveiligingsmaatregel zijn. Bezoekers merken daar wel direct iets van: informatie is onbereikbaar of de gebruikelijke ingang naar een dienst valt weg.
Bij het NCSC zien we waarom een alternatief informatiekanaal belangrijk is. Het NCSC verving zijn gewone website tijdelijk door een meldingspagina die bezoekers doorverwees naar beveiligingsadviezen en hulpkanalen. Stel jezelf dezelfde vraag: waar vinden klanten, medewerkers en leveranciers betrouwbare informatie als onze gewone website tijdelijk niet beschikbaar is?
Zorg daarom dat belangrijke contactgegevens en afspraken ook buiten de website beschikbaar zijn. Vertel gebruikers waar zij terechtkunnen en waarschuw voor nepberichten die een alternatieve inlogpagina of een dringende beveiligingscontrole aanbieden. Dat is een risico om rekening mee te houden, geen bevestiging dat er rond deze uitval al zo’n campagne loopt.
Wat doet PHP eigenlijk?
PHP is een programmeertaal waarmee veel websites en online diensten zijn gebouwd. Software op de server voert de code in PHP uit. Zo verschijnt een pagina, wordt een formulier verwerkt of gaat een bestelling naar een ander systeem. Onder meer WordPress, Drupal en WooCommerce gebruiken PHP.
Van de websites waarvan W3Techs de programmeertaal op de server kent, gebruikt 69,3 procent PHP. Dat maakt duidelijk hoe breed de technologie wordt gebruikt. Het betekent niet dat zeven op de tien websites via deze twee lekken kunnen worden gehackt.
De vraag is dus niet alleen of je PHP gebruikt. Je beheerder moet ook nagaan welke versie er draait en of jullie inrichting aan de voorwaarden voor misbruik voldoet.
Een werkende website kan toch achterstallig onderhoud hebben
Een ander cijfer uit diezelfde meting verdient aandacht van bestuurders. Van de gemeten websites met PHP draait 27 procent nog op PHP 7 en 7,7 procent op PHP 5. Samen ruim een derde. Deze versies krijgen geen regulier onderhoud meer van de makers van PHP.
En dan tellen PHP 8.0 en 8.1 nog niet eens mee. Ook daarvan is het officiële onderhoud afgelopen, respectievelijk in november 2023 en december 2025.
Dat bewijst niet dat al die websites vandaag kwetsbaar zijn. Sommige leveranciers leveren zelf nog beveiligingupdates voor oudere versies. Red Hat legt uit hoe dat werkt. Vraag je leverancier wel om aan te tonen welke ondersteuning jullie krijgen en of die ook deze kwetsbaarheden afdekt.
Ontbreekt die ondersteuning, dan kan een overstap naar een nieuwere versie nodig zijn. Soms moet daarvoor ook de website of toepassing worden aangepast. Dan praat je over geld, mensen, testen en mogelijke uitval. Dat zijn besluiten waarbij een bestuurder nodig is.
“Een website die nog werkt, is daarmee nog niet goed onderhouden.”
Wat merkt een winkel of gemeente hiervan?
Een webshop met WooCommerce verwerkt bijvoorbeeld bestellingen en klantadressen. De winkel kan daarnaast een koppeling hebben met het magazijn. Moet die toepassing tijdelijk worden afgeschermd, dan valt misschien de online verkoop stil. Of de winkel blijft zichtbaar terwijl bestellingen niet meer automatisch bij het magazijn aankomen.
Ook een externe betaaldienst neemt niet alle risico’s weg. De klantgegevens kunnen nog steeds op de webshopserver staan. En een aanvaller die de webshop overneemt, kan proberen het afrekenen te manipuleren.
Sansec beschreef in februari hoe klanten van een getroffen webshop eerst een vervalst betaalformulier te zien kregen. Na het invullen van hun kaartgegevens werden ze doorgestuurd naar het echte formulier. Zo werden betaalgegevens gestolen zonder dat de betaaldienst zelf hoefde te worden gehackt. Dat is een voorbeeld van digitale skimming, geen vastgesteld gevolg van de huidige kwetsbaarheden in PHP.
Gebruik je Shopify, dan beheert Shopify de technische basis van het winkelplatform. Losse apps en koppelingen kunnen daarbuiten vallen en zelf PHP gebruiken. Vraag dus ook wie die onderhoudt.
Bij gemeenten spelen vergelijkbare afhankelijkheden. Een openbare website kan bezoekers doorsturen naar een apart aanvraagportaal. Een probleem met de website betekent niet automatisch dat ook DigiD of het achterliggende systeem is geraakt. Inwoners kunnen toch hinder ondervinden doordat zij de informatie of de ingang naar een aanvraag niet meer vinden.
Dat uit voorzorg ingrijpen gevolgen heeft, zien we bij NotuBiz. Volgens ANP heeft de leverancier zijn dienst voor raadsinformatie tijdelijk uitgeschakeld. Ruim honderd lagere overheden gebruiken die dienst. Dat betekent niet dat die overheden zijn gehackt.
Zes vragen voor je beheerder of leverancier
Laat je bijpraten door degene die jullie systemen beheert. Deze vragen helpen om verder te komen dan “we zijn ermee bezig”.
1. Op welke versie van PHP draaien wij en wordt die nog onderhouden?
Vraag bij oudere versies welke beveiligingsondersteuning beschikbaar is. Is een overstap nodig? Spreek dan af wie daarover beslist en welk budget en welke mensen daarvoor nodig zijn.
2. Waar gebruiken wij PHP allemaal?
Kijk verder dan de hoofdwebsite. Denk aan klantportalen, oude campagnesites, testomgevingen en koppelingen tussen systemen. Welke toepassingen met PHP verwerken vertrouwelijke gegevens, waar staan die gegevens en welke systemen kunnen erbij? Ook een toepassing achter een API kan PHP gebruiken.
3. Welke installaties zijn kwetsbaar en wanneer is de update gecontroleerd?
Laat de officiële informatie naast jullie eigen systemen leggen. Vraag wie de update installeert en de werking daarna controleert. Een automatische update van WordPress werkt de onderliggende PHP software niet bij. Ook Wordfence waarschuwt daarvoor. Dat onderhoud moet afzonderlijk geregeld zijn. En let op: focus niet alleen op de voorkant van de website maar vraag met name wat er achter de website allemaal ook van PHP gebruikmaakt.
Vraag ook hoe je back-ups zijn beschermd. Als een aanvaller de website overneemt, kan hij dan het maken van back-ups beïnvloeden of bestaande kopieën verwijderen? Dat hangt af van de toegang die hij krijgt tot het back-upproces en de opgeslagen bestanden. Laat bovendien testen of je kunt herstellen vanuit een schone kopie.
PHP kan ook worden gebruikt voor scripts die back-ups van andere systemen aansturen. Neem die daarom mee in je inventarisatie. Dat zo’n script PHP gebruikt, betekent nog niet dat het via deze specifieke kwetsbaarheden kan worden aangevallen. Laat je beheerder de versie, inrichting en bereikbaarheid beoordelen.
4. Wat doen we als updaten niet meteen lukt?
CERT-EU adviseert dan te overwegen om toepassingen die vanaf internet bereikbaar zijn tijdelijk af te schermen. Laat je team beoordelen wat nodig is. Spreek af wie beslist, welke dienstverlening wegvalt en hoe je klanten of inwoners verder helpt. Niet iedere website hoeft zonder beoordeling offline.
5. Zijn er aanwijzingen dat iemand al is binnengedrongen?
Een patch repareert het lek. Daarmee is een eerder geplaatste achterdeur nog niet verwijderd. Bij verdachte signalen is onderzoek nodig. Laat je technische mensen daarbij ook de gegevens bewaren die nodig zijn om te achterhalen wat er is gebeurd. Vraag welke bewaking actief was, welke loggegevens beschikbaar zijn en of die op verdachte activiteit zijn onderzocht.
6. Weten onze mensen hoe ze een onverwacht verzoek van een leverancier controleren?
Geef medewerkers een vertrouwd contactpunt en de ruimte om een dringend verzoek even stil te leggen. Juist nu kan een verhaal over noodzakelijke noodupdates geloofwaardig klinken.
Spreek af wanneer je een terugkoppeling krijgt. Wat is gecontroleerd, wat is opgelost en waar moet nog een besluit over vallen? Kijk deze week ook opnieuw naar eventuele aanvullende adviezen. Zorg dat je technische mensen de tijd en middelen krijgen om hun werk te doen.
Wanneer is het probleem echt opgelost?
Een bericht van je leverancier dat de update is geïnstalleerd, is een belangrijk begin. Vraag ook of is gecontroleerd dat de gerepareerde versie daadwerkelijk draait en dat formulieren, bestellingen en koppelingen nog werken.
Laat daarnaast beoordelen of er aanwijzingen zijn voor eerder misbruik. Geen verdachte meldingen betekent niet automatisch dat er niemand binnen is geweest. Daarvoor moeten de beschikbare gegevens voldoende zicht geven op wat er is gebeurd.
Was er tijdelijke bescherming ingesteld? Laat je beheerder bepalen wanneer die verantwoord kan worden aangepast of opgeheven. Spreek af wie dit controleert en wanneer je daarvan bericht krijgt.
Social engineering: de beller kent jouw leverancier
Juist nu moeten IT afdelingen en leveranciers alert zijn op social engineering. Criminelen kunnen de onrust over PHP aangrijpen om wachtwoorden, verificatiecodes of toegang tot systemen te bemachtigen. Tijdens mijn trainingen door Kevin Mitnick leerde ik hoe overtuigend zo’n verzoek kan worden gebracht. Daar wil ik nadrukkelijk voor waarschuwen. Tijdens mijn masterclasses laat ik zien hoe zulke gesprekken kunnen verlopen en hoe medewerkers daarop kunnen reageren.
De voorbereiding hoeft niet ingewikkeld te zijn. Via openbare informatie, ook wel OSINT genoemd, is vaak te achterhalen van welke leverancier een organisatie gebruik maakt. Denk aan klantreferenties, vacatures en technische gegevens over een website. AI helpt om die aanwijzingen snel bij elkaar te brengen.
Dan gaat de telefoon bij een medewerker of de IT afdeling:
“Hallo, met Erik Jan van [naam van jullie echte leverancier]. We bellen onze klanten vanwege de kwetsbaarheden in PHP. Ik wil even samen controleren of jullie omgeving goed is afgeschermd.”
De naam van de leverancier klopt. Het probleem is herkenbaar en de beller klinkt behulpzaam. Misschien vraagt hij eerst iets onschuldigs. Pas daarna komt het verzoek om in te loggen via een link, een aanmelding goed te keuren of toegang op afstand toe te staan.
Ook leveranciers kunnen zo worden benaderd, bijvoorbeeld door iemand die zich voordoet als een medewerker van een klant. Wie onder tijdsdruk wil helpen, kan daardoor toegang geven aan de verkeerde persoon.
Dit is een voorstelbaar scenario, geen bevestiging van een campagne rond deze kwetsbaarheden. Maar wacht niet met waarschuwen tot die bevestiging er is. Een juiste leveranciersnaam maakt een beller nog niet betrouwbaar. Controleer het verzoek via een contactpersoon en telefoonnummer die je al kent. Volg daarbij de procedure die jullie met de leverancier hebben afgesproken.
Deel geen wachtwoorden of verificatiecodes
Vertel je medewerkers daarom vandaag wat ze moeten doen. Deel geen wachtwoorden of verificatiecodes. Keur geen onverwachte aanmeldingen goed. Neem bij een dringend verzoek zelf contact op met de leverancier via een nummer dat al in jullie administratie staat. Gebruik niet het nummer of de link die de beller aanreikt. Laat ondersteuning op afstand via de afgesproken procedure lopen.
Een echte leverancier kan natuurlijk ook bellen. Die controle is er juist om dat onderscheid te maken.
“Wie bij twijfel ophangt om een verzoek te controleren, verdient een compliment, geen reprimande.”
Mensen zijn ook hier de firewall. Geef hun dan wel duidelijke instructies en rugdekking. Van iemand verwachten dat die in zijn eentje onder tijdsdruk een overtuigende oplichter herkent, is geen goede beveiliging.
Ben je met Cloudflare veilig?
Cloudflare zegt beschermingsregels te hebben uitgerold voor bekende aanvalsmethoden. Het bedrijf noemt die bescherming zelf een tijdelijke noodmaatregel. De update van PHP blijft nodig.
Vraag je beheerder of jullie toepassingen daadwerkelijk onder die bescherming vallen en of de regels aanvallen blokkeren. Regels die alleen verdachte verzoeken registreren, houden ze niet tegen. Een rechtstreeks bereikbare server of een losse toepassing kan bovendien buiten de bescherming vallen.
“Wij gebruiken Cloudflare” is dus het begin van het antwoord. Je wilt weten wat er voor jullie is ingericht en gecontroleerd.
Geef je mensen vandaag duidelijkheid
Als bestuurder hoef je de update niet zelf uit te voeren. Je kunt wel zorgen dat iemand het overzicht heeft, besluiten kan nemen en terugkoppelt wat er gebeurt.
Vraag vandaag aan je team: als onze belangrijkste online dienst tijdelijk uit moet, wie beslist dat en hoe helpen we onze klanten of inwoners verder?
En stuur die waarschuwing over onverwachte telefoontjes namens leveranciers. Met een duidelijk contactpunt help je de beheerder die snel moet handelen én de collega die even wil controleren of een dringend verzoek wel klopt.
Woordenlijst: wat betekenen deze termen?
PHP. Een programmeertaal die veel websites en online toepassingen gebruiken. De code wordt op de server uitgevoerd.
Server en hosting. Een server is een computer die bijvoorbeeld een website of toepassing laat werken. Hosting is de dienst waarmee een aanbieder die omgeving beschikbaar stelt.
OT, operationele technologie. Systemen die fysieke processen aansturen of bewaken, bijvoorbeeld machines, productielijnen en gebouwinstallaties. Bij beveiligingsmaatregelen moeten ook de veiligheid van mensen en de continuïteit van het proces worden meegewogen.
Kwetsbaarheid. Een zwakke plek in software of de inrichting ervan waarvan een aanvaller misbruik kan maken.
Patch of beveiligingsupdate. Het dichten van een beveiligingsprobleem. Een upgrade is een overstap naar een nieuwere versie en kan meer aanpassingen vragen.
WordPress en Drupal. Systemen waarmee je websites maakt en beheert. Ze gebruiken PHP. Onderhoud aan het websitesysteem en aan PHP zijn afzonderlijke taken.
WooCommerce en Shopify. WooCommerce voegt een webshop toe aan WordPress. Shopify is een winkelplatform waarvan Shopify de technische basis beheert.
Apache en mod_php. Apache is software die websites beschikbaar maakt. Met de module mod_php voert Apache zelf PHP uit. PHP noemt deze combinatie bij de huidige kwetsbaarheden het meest risicovol.
API. Een afgesproken manier waarop toepassingen elkaar opdrachten geven of gegevens uitwisselen. Bijvoorbeeld tussen een webshop en een magazijn.
Digitale skimming. Het stelen van betaalgegevens met code of vervalste betaalvelden op een website.
Social engineering. Mensen misleiden om informatie, geld of toegang te krijgen. Helpdeskfraude is daar een voorbeeld van.
Verificatiecode. Een extra code om een aanmelding of handeling te bevestigen. Een onverwachte vraag om die code is reden om het verzoek onafhankelijk te controleren.
Cloudflare. Een aanbieder die onder meer verkeer naar websites afhandelt en bescherming tegen aanvallen biedt. Wat beschermd is, hangt af van de gebruikte diensten en instellingen.
CERT-EU, ACSC en NCSC. Organisaties voor digitale veiligheid. CERT-EU ondersteunt instellingen van de EU. ACSC is de Australische cyberautoriteit. NCSC is het Nederlandse Nationaal Cyber Security Centrum.
Technische ernstscore. Een score die aangeeft hoe ernstig een kwetsbaarheid technisch wordt beoordeeld. De score alleen vertelt niet hoe groot het risico voor jouw organisatie is.
OSINT. Onderzoek met openbaar beschikbare informatie, zoals websites, vacatures en klantreferenties. Die informatie kan ook criminelen helpen om een geloofwaardig verhaal voor te bereiden.
De technische situatie kan veranderen. Raadpleeg de actuele informatie van PHP en CERT-EU. Zie je een feitelijke onjuistheid? Laat het weten via het contactformulier op koedijk.com.
