Kort sagt: Av PHP-sårbarheten PHP2Shell berörs grenarna 8.2 till 8.5 fram till releaserna den 21 oktober 2026, enligt facktidningarna nästan alla versioner ända tillbaka till PHP 5.4. Den är åtgärdad i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre, bara minimala backports i källkoden för 7.4, 8.0 och 8.1.
Vilka versioner har PHP-sårbarheten berört?
PHP2Shell omfattar de två sårbarheterna CVE-2026-109618 och CVE-2026-109619, vardera bedömd med CVSS v4.0 9,2. Båda tillåter körning av skadlig kod på distans utan inloggning. Den 21 oktober 2026 klockan 14:00 UTC (16 tysk tid) publicerade PHP-projektet rättningar för alla grenar som stöds.
| PHP-gren | Sista version före rättningen | Åtgärdad från | Support |
|---|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 | officiellt stöd |
| 8.4 | 8.4.26 | 8.4.27 | officiellt stöd |
| 8.3 | 8.3.35 | 8.3.36 | officiellt stöd |
| 8.2 | 8.2.34 | 8.2.35 | upphör den 31 december 2026 |
| 8.1, 8.0, 7.4 | alla versioner | ingen officiell release | bara minimala backports i källkoden |
| 7.3 till 5.4 | enligt facktidningarna nästan alla berörda | ingen uppdatering | utan support sedan flera år |
Uppgifterna om 8.2 till 8.5 kommer från meddelandena från php.net. Uppgiften om versionerna ända till PHP 5.4 kommer från facktidningarna; någon fullständig officiell lista för gamla versioner finns inte.
För icke-tekniker i några meningar: Står det på er server en version ur kolumnen ”Åtgärdad från” eller högre och har därefter alla PHP-processer startats om, är PHP2Shell stängt. Står där ett äldre nummer är antingen en backport med i bilden, som er leverantör måste bekräfta, eller så är sårbarheten öppen. Fråga i tveksamma fall er IT eller ert webbhotell just om dessa tre punkter: version, backport, omstart.
Berörda driftlägen
Versionsnumret är bara halva svaret. Berörda är alla gängse sätt att köra PHP på en webbserver: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. PHP-teamet bedömer risken som högst vid mod_php, eftersom en exploit där har visats innan någon applikationskod ens körs. Detaljer om det finns under Varför mod_php bär den högsta risken.
Inget skydd följer av applikationen: Vare sig det är WordPress, Shopware, TYPO3, Laravel eller en egenutveckling stänger en uppdatering av applikationen inte sårbarheten i PHP.
Backports: när versionsnumret bedrar
Många Linux-distributioner och webbhotell levererar PHP i egna paket. I stället för att hoppa till en ny uppströmsversion för de in rättningen som backport i sin befintliga version. Det får en praktisk följd: Det visade numret förblir gammalt. Ett exempel från det aktuella läget är Plesk, som kan fortsätta visa 8.2.34 fast felet är åtgärdat.
För er betyder det: Tabellen ovan gäller de officiella releaserna från php.net. För paket från er distribution eller från webbhotellet avgör paketstatusen och leverantörens bekräftelse. Hur ni kontrollerar båda visar Kontrollera PHP-version och patchstatus rätt. För snabbtestet på kommandoraden:
php -v
apt policy php8.3-fpm # Debian/Ubuntu, paketnamnet skiljer sig mellan version och källa
dnf info php-fpm # RHEL-familjen
Ett åtgärdat versionsnummer på hårddisken betyder ännu inte att det körs. Först efter omstart av alla PHP-processer arbetar servern med den rättade koden.
Vad gäller för PHP 8.1 och äldre?
För PHP 8.1, 8.0 och 7.4 finns bara minimala backports i källkoden, alltså rättningar i källkoden som någon själv måste ta över och kompilera. Officiella releaser kommer inte. Vissa distributioner med långtidsunderhåll bygger in sådana rättningar i sina paket; om det gäller ert system går bara att klarlägga genom paketets changelog eller hos leverantören.
På lång sikt finns ingen väg förbi en version med support. Vilken PHP-version ert CMS eller butik tål kontrollerar ni enligt tillverkarens systemkrav, till exempel på wordpress.org, shopware.com eller typo3.org. Mer om det under PHP 8.1 och äldre: Vad som gäller nu.
Och CVE-2026-115560?
Den 23 oktober publicerade php.net en anvisning om en tredje sårbarhet. Den slår bara till vid en ovanlig sessionskonfiguration. En åtgärdad version finns enligt läget den 25 oktober ännu inte; fram till nästa ordinarie buggfixsläpp är åtgärden session.upload_progress.enabled=0. En versionslista väntas först med den fullständiga advisoryn.
Hur hjälper PHP SOS konkret?
- Inventarium: Vi kartlägger alla PHP-versioner på era servrar, även andra installationer för enskilda webbplatser som gärna förbises.
- Avstämning: För varje installation klarlägger vi om en officiell release, en distributionsbackport eller ingen rättning föreligger.
- Uppdatering med intyg: Via PHP-patchtjänsten installerar vi rättningen och startar om alla processer.
- Migreringsplan: För versioner utan officiella uppdateringar planerar vi omstigningen med migreringen från PHP 8.1 och äldre och skyddar servern fram till dess.
Vanliga frågor
Är PHP 8.3.35 fortfarande säkert?
Nej, om inte er leverantör har levererat en backport. 8.3.35 är den sista versionen före rättningen; PHP2Shell är åtgärdat i grenen 8.3 från och med 8.3.36. För distributionspaket kan numret förbli detsamma fast felet är åtgärdat. Då gäller paketets changelog eller leverantörens bekräftelse.
Berörs PHP 7.4 av PHP2Shell?
Enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4. För 7.4, 8.0 och 8.1 finns bara minimala backports i källkoden och inga officiella releaser. Ett byte till en version med support är den hållbara vägen.
Varför visar Plesk 8.2.34 fast det har patchats?
Distributioner och webbhotell för ibland in rättningar som backport i sina befintliga paket. Versionsnumret förblir då detsamma, men felet är ändå åtgärdat. Kontrollera paketstatusen eller låt leverantören bekräfta patchen.
Vilken PHP-version bör jag välja nu?
En version med support som er applikation godkänns för enligt tillverkarens systemkrav. PHP 8.2 når slutet på supporten den 31 december 2026; den som ändå byter nu bör räkna med det.