Sinds de vooraankondiging van 20 oktober staat PHP2Shell op de controlelijst van veel IT-verantwoordelijken. Op 21 oktober 2026 publiceerde het PHP-project beveiligingsupdates voor twee kritieke kwetsbaarheden. Voor DAXS betekende dit: meldingen technisch beoordelen, mogelijk getroffen diensten opsporen en maatregelen prioriteren op basis van de daadwerkelijke bereikbaarheid. Doorslaggevend is wat werkelijk op elk systeem draait, naast de afronding van een updatetaak.
Wat er is gepubliceerd
De kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 kunnen uitvoering van code zonder voorafgaande authenticatie mogelijk maken. De vooraankondiging vermeldt voor beide CVSS v4.0 9,2. Die kritieke classificatie vraagt om een snelle beoordeling; ze bewijst niet welke concrete klantinstallatie met succes is aangevallen.
Het PHP-project noemt de herstelde versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Pakketten die door distributies worden onderhouden, kunnen beveiligingscorrecties als backport ontvangen. Een lager weergegeven basisversienummer bewijst daarom op zichzelf noch ontbrekende bescherming noch een geslaagde correctie. Het precieze pakket, de leveranciersmelding en de werkelijk gebruikte runtime zijn bepalend.
De meldingen hebben betrekking op verschillende webserverkoppelingen. PHP benadrukt het risico bij Apache met mod_php; daaruit volgt geen algemene vrijwaring voor PHP-FPM of andere uitvoeringsvormen. Componenten, uitbreidingen en instellingen worden per omgeving beoordeeld. Een productnaam in een inventaris is onvoldoende.
Onze eerste vraag: waar draait PHP daadwerkelijk?
We hebben de beschikbare meldingen naast de bestaande systeemkennis gelegd. De inventarisatie omvat publieke websites, beheerinterfaces, aanvullende applicaties en diensten die PHP meeleveren. Voor de prioriteit tellen externe bereikbaarheid, de functie van de dienst en de verantwoordelijkheid voor updates. Onduidelijke vermeldingen krijgen een concrete controletaak.
We onderscheiden het geïnstalleerde pakket van de actieve webdienst. Meerdere PHP-versies kunnen naast elkaar bestaan. Ook een succesvol bijgewerkt opdrachtregelprogramma bewijst niet welke runtime een bepaald webserverproces gebruikt. Na een wijziging moeten de betrokken diensten en hun effectieve instellingen daarom aantoonbaar worden gecontroleerd. Een publiek toegankelijke diagnosepagina is hiervoor geen blijvende oplossing.
De inventarisatie moet ook minder opvallende systemen omvatten. Webbeheer kan een nevenfunctie van een apparaat zijn en toch een extra aanvalsoppervlak vormen. Of daar PHP wordt gebruikt en een correctie nodig is, blijft een technische onderzoeksvraag. Alleen de aanwezigheid van een webinterface bewijst geen kwetsbaarheid.
Bijwerken, de werking controleren en open punten vastleggen
Het praktische proces begint met inventariseren en beoordelen. Beschikbare beveiligingsupdates worden vervolgens volgens prioriteit uitgevoerd. Controle omvat pakketversie, benodigde herstarts, effectieve configuratie en noodzakelijke applicatiefuncties. Verantwoordelijken moeten kunnen zien welke dienst is gecontroleerd en waar een leveranciersantwoord, geschikt pakket of technische acceptatie nog ontbreekt.
Kan een gespecialiseerde dienst niet direct worden bijgewerkt, dan beoordelen we eerst welke rechtstreekse publieke toegang werkelijk nodig is. Overbodige internettoegang kan tijdelijk worden verwijderd. Legitiem intern gebruik kan eventueel via passende afgeschermde toegangswegen doorgaan. Dit is een bewust beperkte maatregel waarvan werking en neveneffecten moeten worden gecontroleerd; de onderliggende software wordt er niet automatisch foutvrij door.
Een taak is niet klaar zodra een update wordt gestart. Er is een aantoonbare afronding nodig of een benoemd open punt met een verantwoordelijke. Bij toegangsbeperking wordt ook de resterende bereikbaarheid gecontroleerd. Na installatie van een correctie volgt controle van de werkelijk gebruikte dienst. Beide horen in actuele beheerdocumentatie.
Ook het distributiekanaal van de software hoort bij het controleresultaat. Bij een installatie die het besturingssysteem onderhoudt, wordt het distributieadvies vergeleken met het geïnstalleerde pakket. Bij een meegeleverde runtime tellen de gegevens van de betreffende productleverancier. Dit voorkomt een verkeerde interpretatie van alleen een versienummer. Zijn de bewijzen onvoldoende, dan blijft het punt open met een volgende controlestap. Een groene status zonder verifieerbare basis zou misleidend zijn.
Wat WAF’s, proxy’s, firewalls en gescheiden netwerken bijdragen
WAF’s, reverse proxy’s, firewalls en VLAN’s behoren al tot de middelen om toegang en gegevensstromen te beperken. Een firewall regelt toegestane verbindingen, een proxy bundelt vastgelegde webtoegang en gescheiden netwerken helpen toegestane communicatie af te bakenen. Dat zijn waardevolle functies, maar ze verhelpen niet elke kwetsbaarheid in een PHP-proces.
PHP2Shell mag met name niet worden voorgesteld als volledig verholpen door een WAF vóór of binnen de applicatie. Het PHP-project noemt bijwerken de volledige oplossing; tijdelijke beperkingen dekken alleen bepaalde aanvalspaden. We beoordelen deze lagen daarom samen met de patchstatus en controleren of een andere route de bedoelde toegangsbeperking kan omzeilen.
Geïsoleerde tests en AI ondersteunen het vakinhoudelijke oordeel
Voor de technische beoordeling gebruikten we ook eigen geïsoleerde testomgevingen. Claude en OpenAI Codex ondersteunden onderzoek en voorbereiding daarvan. Vakinhoudelijk oordeel en betrouwbare technische bronnen waren doorslaggevend. Een plausibel AI-antwoord vervangt geen bewijs van de geïnstalleerde versie of controle van een effectieve instelling.
Ook na het bijwerken blijft observatie nodig. Ongebruikelijke fouten, onverwachte processen of afwijkende verbindingen worden beoordeeld ten opzichte van normaal systeemgedrag. Een geïnstalleerde patch bewijst achteraf niet dat er daarvoor niets is gebeurd. Omgekeerd vormt één ongebruikelijke logvermelding geen betrouwbaar bewijs van een geslaagde aanval.
Publieke berichten in hun context plaatsen
De melding van de Universiteit van Wenen over beperkingen van centrale IT-diensten laat zien hoe ingrijpend voorzorgsmaatregelen kunnen zijn. Het bijgewerkte bericht meldt dat de meeste diensten weer beschikbaar zijn. Zulke openbare informatie helpt de situatie te duiden, maar zegt niets over een andere organisatie of een specifieke omgeving die DAXS ondersteunt.
Ook leveranciersadviezen moeten passen bij de betreffende dienst. Een leverancier kan onderscheid maken tussen zijn producten en een gehost portaal dat hij beheert. Een uitspraak over één product geldt niet automatisch voor willekeurige applicaties van derden. Bij OPNsense, FreePBX, Sophos of een afzonderlijke gateway zijn dus de exacte versie, meegeleverde componenten, leveranciersinformatie en daadwerkelijke toegangssituatie van belang.
Voorbereiding maakt de reactie controleerbaar
Een bruikbare inventaris, duidelijke verantwoordelijkheden en voorbereide updatepaden maken reageren op kritieke meldingen eenvoudiger. We publiceren geen onbewezen patchpercentage of algemene vrijwaring voor alle systemen. Aantoonbare individuele controles en het verder afhandelen van open gevallen zijn doorslaggevend. Vrijdag bekijken we hoe AI helpt om gemakkelijk vergeten apparaten in zo’n controlelijst op te nemen.
