Kort sagt: För PHP-8.1-sårbarheten PHP2Shell finns ingen officiell uppdatering. PHP-projektet levererar för 7.4, 8.0 och 8.1 bara minimala backports i källkoden, inga färdiga releaser. Den som driver dessa versioner behöver en bekräftad backport från sin leverantör eller övergångsåtgärder och bör planera omstigningen till en version med support nu.
Finns det en uppdatering mot PHP-8.1-sårbarheten?
Inte från PHP-projektet. Den 21 oktober 2026 kom officiella rättningar bara för de grenar som stöds: 8.5.12, 8.4.27, 8.3.36 och 8.2.35. PHP 8.1 och äldre versioner får inga officiella uppdateringar längre.
De är ändå berörda. Enligt facktidningarna sträcker sig de sårbara versionerna nästan genomgående ända tillbaka till PHP 5.4. Den som driver någon av dessa versioner offentligt nåbart har alltså en kritisk sårbarhet med CVSS v4.0 9,2 utan färdig patch.
För många företag är det en överraskning, eftersom sådana system ofta har körts stabilt och oansenligt i flera år. Att en version inte längre får uppdateringar märker man inte i vardagen förrän en sårbarhet som PHP2Shell dyker upp. Backportarna i källkoden för 7.4, 8.0 och 8.1 är ett undantag och ingen återupptagen ordinarie vård.
Vad backports i källkoden innebär
För 7.4, 8.0 och 8.1 finns minimala backports i källkoden. Det är rättningar i källkoden som har förts över till dessa äldre grenar. De är ingen officiell release med versionsnummer, testat paket och changelog.
Praktiskt betyder det: Någon måste ta över backporten, bygga PHP av den på nytt, testa och rulla ut. Det kan ske på tre sätt:
- Er distribution för in rättningen i sina paket, till exempel inom ramen för långtidsunderhåll.
- Ert webbhotell bygger egna PHP-paket och installerar backporten.
- Ni själva eller en tjänsteleverantör bygger PHP från källkoden. Det är krävande och måste upprepas vid varje ytterligare sårbarhet.
Om ert system har fått en backport kontrollerar ni i paketets changelog:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-familjen
Paketnamn skiljer sig mellan distributioner och paketkällor. Saknas en post, fråga leverantören. Hur kontrollen fungerar i detalj står under Kontrollera PHP-version och patchstatus rätt.
Skydda den gamla servern fram till migreringen
Så länge ingen bekräftad backport körs gäller övergångsåtgärderna från php.net: ej överskrivbart memory_limit=-1 med minnesgräns via cgroup, post_max_size på 8M eller 32M med upload_max_filesize under det och session.upload_progress.enabled=0 i serverkonfigurationen, därefter omstart av alla workers. De är inget fullständigt skydd. Detaljer under Akutåtgärder om ni ännu inte kan patcha.
Därtill kommer åtgärder som minskar nåbarheten: adminområden bara via VPN eller godkända IP-adresser, stänga av webbplatser som inte behövs, begränsa åtkomsten till servern snävt. BSI (Tysklands federala myndighet för informationssäkerhet) rekommenderar att tillfälligt ta servrar utan uppdatering från nätet. För en gammal, svårmigrerad applikation kan en avskärmad lösning vara det ärligare svaret än drift på det öppna internet.
Om en server med PHP 8.1 eller äldre har legat oskyddad på nätet sedan den 17 oktober: ta det på allvar. BSI räknade med snabbt utnyttjande i stor skala. Säkra loggarna från och med den 20 oktober och låt servern kontrolleras efter spår innan ni migrerar.
Planera migreringen: till vilken version?
Målet är en version som PHP-projektet stöder och som er applikation tål. PHP 8.2 stänger sårbarheten från 8.2.35 men når slutet på supporten den 31 december 2026. Den som migrerar nu bör därför helst gå till 8.3 eller nyare, om applikationen tillåter det. Det aktuella läget anger php.net på sidan för versioner som stöds.
Vilken PHP-version ert CMS eller butik stöder kontrollerar ni enligt tillverkarens systemkrav, till exempel på wordpress.org, shopware.com eller typo3.org. Ofta måste applikationen självt uppdateras innan PHP kan bytas. Ett typiskt fall är äldre butiker, som vi beskriver på sidan Shopware 5. Bakgrund om följderna av föråldrade versioner finns under PHP End of Life: risker med föråldrade versioner.
| Steg | Innehåll |
|---|---|
| Bestånd | PHP-version, applikation, tillägg, egna anpassningar |
| Krav | PHP-versioner som stöds enligt tillverkaren |
| Testmiljö | kopia med ny PHP-version, analysera felloggen |
| Omställning | planerat underhållsfönster, återväg förberedd |
| Efterarbete | kontrollera övergångsvärden, sätta upp övervakning |
Hur hjälper PHP SOS konkret?
Med migreringen från PHP 8.1 och äldre leder vi er från den gamla versionen till en version med support:
- Skydda genast: kontrollera backportstatus, sätta övergångsåtgärder, minska nåbarheten.
- Kontrollera spår: säkra loggar från och med den 20 oktober och analysera dem efter avvikelser.
- Förbereda migreringen: klarlägga kompatibilitet enligt tillverkaren, bygga upp testmiljö, åtgärda fel.
- Ställa om och belägga: installera den nya PHP-versionen, starta om alla processer, dokumentera läget.
Vanliga frågor
Berörs PHP 8.1 av PHP2Shell?
Enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4, PHP 8.1 inräknat. PHP-projektet publicerar inga officiella uppdateringar längre för 8.1, bara minimala backports i källkoden.
Vad är en backport i källkoden?
En rättning i källkoden som har förts över till en äldre versionsgren. Den är ingen färdig release: Någon måste ta över den, bygga PHP på nytt, testa och rulla ut. Det kan er distributionsleverantör, ert webbhotell eller en tjänsteleverantör ta hand om.
Räcker det att byta till PHP 8.2?
På kort sikt stänger PHP 8.2.35 sårbarheten. PHP 8.2 når dock slutet på supporten den 31 december 2026. Den som ändå migrerar bör därför kontrollera om applikationen enligt tillverkaren även stöder 8.3 eller nyare.
Min butik fungerar bara med PHP 7.4. Vad nu?
Då behövs två saker parallellt: skydda servern med övergångsåtgärder och avskärmning, och få applikationen till en version som tål en PHP-version med support. Vilken det är står i tillverkarens systemkrav.