Veelgestelde vragen
Welke PHP-versies zijn getroffen?
Elke versie vóór 8.5.12, 8.4.27, 8.3.36 en 8.2.35 in de ondersteunde branches. PHP 8.1 en ouder zijn end of life en krijgen geen release van het PHP-project; beschouw ze als kwetsbaar, tenzij uw leverancier een gebackporte oplossing bevestigt.
Mijn site toont geen PHP-versie. Ben ik veilig?
Niet per se. De versie verbergen (expose_php = Off) is een goede gewoonte, maar patcht niets. Controleer op de server met php -v of vraag het uw provider.
De checker toont een oude versie, maar mijn host zegt dat die gepatcht is. Wie heeft gelijk?
Mogelijk allebei. Linuxdistributies zoals Debian, Ubuntu en RHEL backporten beveiligingsoplossingen vaak zonder het versienummer te wijzigen. Vraag uw host welke pakketbuild is geïnstalleerd en of de changelog CVE-2026-109618 en CVE-2026-109619 vermeldt.
Zijn WordPress, Laravel of mijn CMS getroffen?
De fouten zitten in PHP zelf, dus elke applicatie die op een kwetsbare PHP draait, is blootgesteld. De onderzoekers demonstreerden aanvallen zonder authenticatie op WordPress, Drupal en Joomla, maar dat waren slechts voorbeelden — zelfs een eenvoudige “Hello World”-pagina volstaat. WordPress of plugins bijwerken lost het niet op; PHP moet worden bijgewerkt.
Kunnen gegevens uitlekken, ook als er geen code is uitgevoerd?
Ja. CVE-2026-109619 kan het geheugen van het PHP-proces blootleggen — wachtwoorden, sessietokens, API-sleutels en certificaten van andere verzoeken — zonder dat de aanvaller code uitvoert. Zulke lekken laten geen bestanden achter en zijn moeilijk te detecteren; wijzig daarom de geheimen van elke site die een kwetsbare versie op internet heeft gedraaid.
Lost het uitschakelen van session.upload_progress het op?
Nee. php.net noemt session.upload_progress.enabled=0 als gedeeltelijke mitigatie voor enkele bevestigde paden van CVE-2026-109619. Het dekt niet alle varianten en doet niets tegen CVE-2026-109618.
Is een web application firewall voldoende?
Een WAF of verzoeklimieten kunnen de blootstelling verkleinen terwijl u bijwerkt, maar de problemen zitten in de manier waarop PHP verzoeken en geheugen afhandelt. Bijwerken blijft noodzakelijk.
Moet ik na het bijwerken iets herstarten?
Ja. PHP-FPM, Apache, LiteSpeed en langlopende workers blijven de oude code uitvoeren totdat ze worden herstart. Containers moeten opnieuw worden aangemaakt vanuit het nieuwe image.
Wat doet deze checker eigenlijk?
Hij stuurt één HEAD-verzoek (of een GET als HEAD niet is toegestaan) naar het adres dat u invoert, volgt maximaal drie doorverwijzingen en leest response headers zoals X-Powered-By en Server. Hij verstuurt nooit exploit-payloads, grote verzoeken of uploads, en scant geen andere paden.
Mag ik elke website controleren?
Controleer alleen sites die u bezit of mag beoordelen. Het verzoek is gelijk aan een normaal bezoek, maar verantwoord gebruik is uw eigen verantwoordelijkheid. We beperken het aantal controles per netwerk en per site.
Is PHP 8.5.12 volledig gepatcht?
Op 22 oktober 2026 deden berichten de ronde over een crash in 8.5.12, maar die zijn niet bevestigd als kwetsbaarheid op afstand. We volgen php.net; verschijnt er een nieuwe release, dan wordt deze site bijgewerkt en verandert de datum “laatst gecontroleerd”.
Waar kan ik de officiële details lezen?
Op php.net en in de GitHub-adviezen van het PHP-project GHSA-w8hw-w9fx-j79w en GHSA-6wmf-4rv5-p3rp. Het onderzoeksteam (Wiz Research, OpenAI Codex Security en Calif) publiceerde zijn bevindingen op php2shell.com.
Wie heeft de kwetsbaarheden gevonden?
Onderzoekers van Wiz Research, OpenAI Codex Security en Calif, via gecoördineerde openbaarmaking met het PHP-beveiligingsteam, dat de oplossingen heeft voorbereid. Zie het bericht van The PHP Foundation over de release.