Actuele situatie: PHP2Shell. Twee kritieke PHP-kwetsbaarheden (CVSS 9.2) maken schadelijke code zonder inloggen mogelijk. Patches sinds 21-10-2026.Wat u nu moet doen →

CVE-2026-109619: RCE door verouderde globale toestand

CVE-2026-109619 is de tweede PHP2Shell-kwetsbaarheid: interne toestand van een verzoek kan na het vrijgeven van geheugen blijven bestaan en door het volgende verzoek in dezelfde worker worden gebruikt.

Stand 4 min. leestijdPHP2Shell

Kort gezegd: CVE-2026-109619 is de tweede kwetsbaarheid achter PHP2Shell. Interne toestand die bij een verzoek hoort, kan na het vrijgeven van geheugen blijven bestaan; een later verzoek in dezelfde worker kan die gebruiken voordat hij wordt teruggezet. Het gevolg is code-uitvoering zonder inloggen. Remedie: update naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en herstart van alle workers.

Wat is CVE-2026-109619?

CVE-2026-109619 (GitHub-aanduiding GHSA-6wmf-4rv5-p3rp) is met CVSS v4.0 beoordeeld met 9,2. Samen met CVE-2026-109618 vormt ze PHP2Shell. Beide kwetsbaarheden zitten in PHP zelf en niet in een toepassing.

Het effect is hetzelfde als bij de zusterkwetsbaarheid: een aanvaller kan op afstand, zonder wachtwoord en zonder gebruikersaccount, code op de server uitvoeren. De oorzaak is echter een andere.

Waarom verouderde toestand in de worker gevaarlijk is

Een PHP-webserver start niet voor elk verzoek een nieuw proces. Bij PHP-FPM, Apache met mod_php, LiteSpeed of FrankenPHP verwerkt een worker achtereenvolgens veel verzoeken. Tussen twee verzoeken zet PHP zijn interne toestand terug, zodat niets van verzoek A in verzoek B terechtkomt.

Bij CVE-2026-109619 lukt dat terugzetten niet volledig. Volgens php.net kan interne toestand die bij het verzoek hoort, na het vrijgeven van geheugen blijven bestaan. Een later verzoek in dezelfde worker kan deze verouderde toestand gebruiken voordat hij wordt teruggezet. Vereenvoudigd gezegd: iets wordt hergebruikt dat eigenlijk al niet meer geldig is.

Vanuit het gezichtspunt van de bedrijfsvoering is dit opmerkelijk. Het hergebruik van workers is gewenst, omdat het webservers snel maakt: een worker hoeft niet voor elk verzoek opnieuw te starten, extensies te laden en geheugen aan te leggen. De kwetsbaarheid treft dus een eigenschap die vrijwel elke productieve PHP-installatie heeft. php.net noemt geen configuratie die het probleem volledig vermijdt; daarom loopt de weg via de update.

Details over het misbruik publiceren we niet. Voor beheerders telt: elke werkwijze waarin workers meerdere verzoeken bedienen, moet in het oog worden gehouden, en juist die werkwijzen zijn de gangbare.

De twee PHP2Shell-kwetsbaarheden vergeleken

Kenmerk CVE-2026-109618 CVE-2026-109619
GitHub-aanduiding GHSA-w8hw-w9fx-j79w GHSA-6wmf-4rv5-p3rp
Beoordeling CVSS v4.0 9,2 CVSS v4.0 9,2
Aanleiding Out-of-memory tijdens de initialisatie van de verzoekgegevens Interne toestand blijft na vrijgave bestaan
Effect Code-uitvoering zonder inloggen Code-uitvoering zonder inloggen
Verholpen in 8.5.12, 8.4.27, 8.3.36, 8.2.35 8.5.12, 8.4.27, 8.3.36, 8.2.35

Getroffen zijn PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Het hoogste risico ziet het PHP-team bij mod_php; waarom, leggen we uit onder Waarom mod_php het hoogste risico draagt.

CVE-2026-109619 dichten: update, daarna alle workers herstarten

Juist bij deze kwetsbaarheid is de herstart beslissend. Zolang oude workers in het geheugen draaien, werkt de server met de foutieve code door, ook al staan de nieuwe bestanden allang op de schijf.

Controleer versie en pakketstand. Pakketnamen verschillen per distributie en hosterinterface:

php -v
php-fpm8.3 -v                  # de FPM-binary kan een andere versie hebben dan de CLI
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL-familie
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"

Herstart daarna alle getroffen diensten:

sudo systemctl restart php8.3-fpm     # per geïnstalleerde PHP-versie
sudo systemctl restart apache2        # bij mod_php; onder RHEL heet de service httpd

Installeert uw distributie of hoster een backport, dan blijft het getoonde versienummer mogelijk gelijk. Dan tellen de changelog van het pakket en de schriftelijke bevestiging van de aanbieder. Een stap-voor-stapcontrole vindt u onder PHP-FPM en alle workers herstarten.

Tip

Noteer datum en tijd van de herstart. Voor de latere beoordeling of een aanval vóór of na de patch plaatsvond, is dit tijdstip het belangrijkste referentiepunt.

Wat er na de patch nog te doen blijft

Een patch bewijst niet dat er eerder niets is gebeurd. Volgens berichten in de media werd op 17 oktober een eerste aanvalspoging waargenomen, vier dagen vóór de patches. Bewaar serverlogs vanaf 20 oktober, zoals de vakpers adviseert, en controleer de server op opvallende zaken. Aanwijzingen daarvoor biedt de pagina Ben ik al gecompromitteerd?.

Denk daarbij aan het bereik: bij een geslaagde code-uitvoering heeft de aanvaller de rechten van het PHP-proces. Hij kan lezen wat de toepassing mag lezen, zoals configuratiebestanden met databasetoegangen of API-sleutels. Bevestigt zich een incident, dan horen deze toegangsgegevens na de reiniging te worden vernieuwd.

Hoe helpt PHP SOS concreet?

Met de PHP-patchservice voeren wij de correctie navolgbaar door:

  • Vastleggen: welke PHP-versies en werkwijzen draaien op welke server, en welke pakketbron levert ze?
  • Patchen: update uit de juiste bron of overbruggingsmaatregelen volgens php.net waar de update nog geblokkeerd is.
  • Herstart controleren: wij controleren proces voor proces dat alleen nog de gecorrigeerde versie draait.
  • Documenteren: versies, pakketstanden en herstarttijdstippen, zodat u de stand kunt aantonen.

Veelgestelde vragen

Wat onderscheidt CVE-2026-109619 van CVE-2026-109618?

CVE-2026-109618 ontstaat wanneer een out-of-memory-toestand het verzoek midden in de initialisatie onderbreekt. CVE-2026-109619 betreft toestand die na het einde van een verzoek in de worker achterblijft. Beide leiden tot code-uitvoering zonder inloggen en zijn in dezelfde PHP-versies verholpen.

Helpt het om PHP-FPM-workers vaker te herstarten?

Als vervanging van de update is dat niet geschikt. php.net noemt vaker herstarten van workers niet als overbruggingsmaatregel. Herstarten moet u de workers wel na de update, zodat de gecorrigeerde versie echt draait.

Ben ik met een CMS-update beschermd tegen CVE-2026-109619?

Nee. De kwetsbaarheid zit in PHP en niet in WordPress, Shopware, TYPO3 of een ander systeem. Alleen een PHP-update of een bevestigde backport van de aanbieder dicht haar.

Zijn er bekende sporen van een aanval via CVE-2026-109619?

Bevestigde Indicators of Compromise zijn tot nu toe niet gepubliceerd. Detectie berust op gedragsanalyse, bijvoorbeeld nieuwe PHP-bestanden, ongebruikelijke uitgaande verbindingen of onbekende cronjobs.

Bronnen

Direct contact

Elk uur telt. Schrijf ons nu.

Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.

Directe hulp