Kort sagt: CVE-2026-109619 är den andra sårbarheten bakom PHP2Shell. Internt tillstånd som hör till en förfrågan kan finnas kvar efter att minnet frigjorts; en senare förfrågan i samma worker kan använda det innan det återställs. Följden är kodkörning utan inloggning. Åtgärd: uppdatera till PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 och starta om alla workers.
Vad är CVE-2026-109619?
CVE-2026-109619 (GitHub-beteckning GHSA-6wmf-4rv5-p3rp) är bedömd med CVSS v4.0 9,2. Tillsammans med CVE-2026-109618 bildar den PHP2Shell. Båda sårbarheterna finns i PHP självt och inte i en applikation.
Verkan är densamma som hos systersårbarheten: En angripare kan på distans, utan lösenord och utan användarkonto, köra kod på servern. Orsaken är dock en annan.
Varför föråldrat tillstånd i workern är farligt
En PHP-webbserver startar inte en ny process för varje förfrågan. Vid PHP-FPM, Apache med mod_php, LiteSpeed eller FrankenPHP bearbetar en worker många förfrågningar efter varandra. Mellan två förfrågningar återställer PHP sitt interna tillstånd så att inget från förfrågan A hamnar i förfrågan B.
Vid CVE-2026-109619 fungerar inte den här återställningen fullständigt. Enligt php.net kan internt tillstånd som hör till förfrågan finnas kvar efter att minnet frigjorts. En senare förfrågan i samma worker kan använda det föråldrade tillståndet innan det återställs. Förenklat: Något återanvänds som egentligen inte längre är giltigt.
Ur driftens synvinkel är det anmärkningsvärt. Återanvändningen av workers är avsiktlig, eftersom den gör webbservrar snabba: En worker behöver inte startas om för varje förfrågan, ladda tillägg och skapa minne. Sårbarheten träffar alltså en egenskap som praktiskt taget varje produktiv PHP-installation har. php.net anger ingen konfiguration som helt undviker problemet; därför går vägen via uppdateringen.
Detaljer om utnyttjandet publicerar vi inte. För driftansvariga gäller: Varje driftläge där workers betjänar flera förfrågningar ska hållas under uppsikt, och just dessa driftlägen är de vanliga.
De två PHP2Shell-sårbarheterna i jämförelse
| Egenskap | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub-beteckning | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Bedömning | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Utlösare | Out-of-memory under initieringen av förfrågningsdata | Internt tillstånd finns kvar efter frigörande |
| Verkan | Kodkörning utan inloggning | Kodkörning utan inloggning |
| Åtgärdad i | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Berörda är PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Den högsta risken ser PHP-teamet vid mod_php; varför förklarar vi under Varför mod_php bär den högsta risken.
Stänga CVE-2026-109619: uppdatera och därefter starta om alla workers
Just vid den här sårbarheten är omstarten avgörande. Så länge gamla workers körs i minnet arbetar servern vidare med den felaktiga koden, även om de nya filerna för länge sedan ligger på disken.
Kontrollera version och paketstatus. Paketnamn skiljer sig mellan distribution och webbhotellets gränssnitt:
php -v
php-fpm8.3 -v # FPM-binären kan ha en annan version än CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL-familjen
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Starta därefter om alla berörda tjänster:
sudo systemctl restart php8.3-fpm # per installerad PHP-version
sudo systemctl restart apache2 # vid mod_php; under RHEL heter tjänsten httpd
Levererar er distribution eller ert webbhotell en backport kan det visade versionsnumret förbli detsamma. Då räknas paketets changelog och leverantörens skriftliga bekräftelse. En kontroll steg för steg finns under Starta om PHP-FPM och alla workers.
Anteckna datum och klockslag för omstarten. För den senare bedömningen om ett angrepp skedde före eller efter patchen är den tidpunkten den viktigaste referenspunkten.
Vad som återstår efter patchen
En patch bevisar inte att inget har hänt tidigare. Enligt mediarapporter observerades ett första angreppsförsök den 17 oktober, fyra dagar före patcharna. Spara serverloggar från och med den 20 oktober, som facktidningarna rekommenderar, och kontrollera servern efter avvikelser. Anvisningar ger sidan Är jag redan komprometterad?.
Tänk därvid på räckvidden: Vid en lyckad kodkörning har angriparen PHP-processens rättigheter. Han kan läsa det som applikationen får läsa, till exempel konfigurationsfiler med databasåtkomst eller API-nycklar. Bekräftas en incident ska dessa inloggningsuppgifter förnyas efter rensningen.
Hur hjälper PHP SOS konkret?
Med PHP-patchtjänsten genomför vi rättningen spårbart:
- Kartlägga: Vilka PHP-versioner och driftlägen körs på vilken server, och vilken paketkälla levererar dem?
- Patcha: Uppdatering från rätt källa eller övergångsåtgärder enligt php.net där uppdateringen ännu är blockerad.
- Kontrollera omstarten: Vi kontrollerar process för process att bara den rättade versionen längre körs.
- Dokumentera: Versioner, paketstatus och omstartstidpunkter så att ni kan belägga läget.
Vanliga frågor
Vad skiljer CVE-2026-109619 från CVE-2026-109618?
CVE-2026-109618 uppstår när ett out-of-memory-tillstånd avbryter förfrågan mitt i initieringen. CVE-2026-109619 gäller tillstånd som blir kvar i workern efter att en förfrågan slutat. Båda leder till kodkörning utan inloggning och är åtgärdade i samma PHP-versioner.
Hjälper det att starta om PHP-FPM-workers oftare?
Som ersättning för uppdateringen är det inte lämpligt. php.net anger inte oftare omstarter av workers som övergångsåtgärd. Workers måste dock startas om efter uppdateringen så att den rättade versionen överhuvudtaget körs.
Är jag skyddad mot CVE-2026-109619 med en CMS-uppdatering?
Nej. Sårbarheten finns i PHP och inte i WordPress, Shopware, TYPO3 eller något annat system. Bara en PHP-uppdatering eller en bekräftad backport från leverantören stänger den.
Finns det kända spår av ett angrepp via CVE-2026-109619?
Bekräftade Indicators of Compromise har hittills inte publicerats. Upptäckten bygger på beteendeanalys, till exempel nya PHP-filer, ovanliga utgående förbindelser eller okända cronjobb.