Kort sagt: Efter PHP2Shell är fler rapporter om PHP sannolika, eftersom ett tredje meddelande redan kom två dagar efter patchen, ett fullständigt advisory ännu återstår och distributioner levererar sina paket i etapper. Den som nu inrättar ett fast förlopp för bevakning, bedömning, uppdatering och omstart reagerar på nästa nya PHP-säkerhetslucka på timmar i stället för dagar.
Patchen var inte slutet på historien
Den 21 oktober 2026 stängde PHP-projektet de två kritiska sårbarheterna CVE-2026-109618 och CVE-2026-109619 med versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Många ansvariga har därefter satt en bock. Två dagar senare, den 23 oktober, följde dock ett ytterligare meddelande från php.net om CVE-2026-115560.
Det tredje meddelandet gäller bara en ovanlig sessionskonfiguration. Men det visar ett mönster som man känner igen från stora säkerhetsfall: när en komponent plötsligt hamnar i rampljuset tittar många fackmän samtidigt närmare. Om det leder till fler sårbarheter vet i dag ingen. Sannolikt är dock att nyhetsläget inte rinner ut i sanden.
För er som driftansvariga betyder det: planera för uppföljande rapporter i stället för att bli överraskade av varje. Händelseförloppet hittills sammanfattar vår PHP2Shell-kronologi.
Varför fler rapporter är sannolika
Följande bedömning bygger på offentligt kända fakta. Den är ingen förutsägelse av konkreta sårbarheter.
- Ett advisory återstår. php.net behandlar CVE-2026-115560 i den reguljära releasecykeln och har aviserat att det fullständiga advisoryt publiceras med nästa release. Fram till dess gäller
session.upload_progress.enabled=0som åtgärd. - Detaljerna var tidigt offentliga. Enligt flera rapporter blev detaljer kända innan embargot löpte ut. Enligt rapporter har watchTowr enligt egna uppgifter återskapat CVE-2026-109618. Sådant arbete leder ofta till följdfrågor vid angränsande kodställen.
- Distributioner levererar i etapper. Ubuntu försåg den 21 oktober de aktuella releaserna med USN-8948-1 och levererade i efterhand med USN-8948-2 rättningar för 14.04 till 20.04 via Ubuntu Pro. Red Hat skrev i sitt bulletin att vissa uppdateringar finns tillgängliga och fler är under arbete.
- Utvecklingsversionen är berörd. Enligt php.net innehåller även PHP 8.6.0 RC4 rättningarna. Den som testar förhandsversioner måste uppdatera även de miljöerna.
- Äldre versioner förblir öppna. För PHP 8.1 och äldre finns bara minimala backports i källkoden. Varje leverantör som levererar sådana versioner rapporterar sitt läge självständigt och vid egna tidpunkter.
Hur en ny PHP-säkerhetslucka når er
Rapporter kommer på olika vägar och med olika tillförlitlighet. Ordningen är nästan alltid densamma: först PHP-projektet, sedan distributioner och webbhotell, därefter myndigheter och medier.
| Källa | Vad ni får veta där | Hur tillförlitlig |
|---|---|---|
| php.net | berörda grenar, åtgärdade versioner, tillfälliga åtgärder | primärkälla |
| Ubuntu, Debian, Red Hat | paketnivåer per release, leveranstidpunkt | primärkälla för ert system |
| Webbhotell och panelleverantörer | läget för de egna PHP-byggena | bindande bara om skriftligt |
| BSI, CERT-Bund | lägesbedömning, varningsnivå, rekommendationer | myndighetens bedömning |
| Facktidningar och säkerhetsföretag | angreppsobservationer, siffror, bakgrund | hjälpsamt, markera som rapport |
Viktig är skillnaden mellan ”det finns en patch” och ”mitt system har patchen”. Det första står på php.net. Det andra måste ni styrka själva för varje server.
Prenumerera på rapporterna från php.net och er distribution via RSS eller e-postlista och vidarebefordra dem till en gemensam brevlåda eller kanal som fler än en person läser. Semester och sjukdom är de vanligaste skälen till försenade uppdateringar.
Vad ni bör förbereda inför nästa rapport
Erfarenheten från PHP2Shell visar var tid går förlorad: vid sökandet efter servrar, vid klargörandet av ansvar och vid den bortglömda omstarten. Allt det går att göra i förväg.
- Inventering: En lista över alla servrar och webbplatser med PHP-gren, driftläge (PHP-FPM, mod_php, LiteSpeed) och paketkälla. Utan listan börjar varje rapport med letande. Hur det lyckas beskriver inlägget Inventering av alla webbplatser och servrar.
- Ansvar: För varje system är det fastställt vem som patchar, vem som startar om och vem som godkänner. Hos webbhotell och byråer hör det hemma i avtalet.
- Bedömningsraster: Tre frågor räcker för den första bedömningen. Är vår gren berörd? Använder vi den berörda funktionen eller driftläget? Finns det en patch eller bara tillfälliga åtgärder?
- Testväg: En stagingmiljö där en PHP-uppdatering kan kontrolleras på kort tid.
- Bevis: Ett fast format där paketnivå, changelog-träff och omstartstid dokumenteras.
Hur ett sådant förlopp fungerar som rutin i stället för brandkårsutryckning står under Patchhantering som process. Bakgrund till hur PHP-projektet hanterar sårbarheter ger sidan Hur PHP-projektet hanterar säkerhetsluckor.
Den egna konfigurationen som tidigt varningssystem
En del av de uppföljande rapporterna berör bara vissa inställningar. CVE-2026-115560 är ett exempel: php.net anger som förutsättning att en applikation ställer om sessionsserialiseraren vid körning medan upload-progress är aktivt. Applikationer som aldrig gör det är enligt php.net inte berörda.
Den som känner sin verksamma konfiguration kan bedöma sådana rapporter snabbare. Notera därför för varje gren vilka värden som är satta på serversidan och vilka applikationer som får skriva över dem. En enkel avstämning av de aktiva inställningarna hjälper redan:
# Verksamma värden på kommandoraden (webbkonfigurationen kan avvika)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Satta värden i FPM-poolerna (sökväg skiljer sig mellan distributioner)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Kommandoraden visar inte nödvändigtvis vad som gäller i webbkontexten. Klarhet ger pool- eller VirtualHost-konfigurationen och, kortvarigt och skyddat, en phpinfo-sida.
En ytterligare fördel: den som vet vilka tillfälliga värden som fortfarande är satta från PHP2Shell-veckan kan medvetet granska dem efter nästa reguljära release. Vissa inställningar, till exempel avstängt upload-progress, kan förbli rimliga varaktigt. Andra, som mycket snäva uppladdningsgränser, bör ni efter samråd med fackavdelningarna anpassa tillbaka till det verkliga behovet.
Hur hjälper PHP SOS konkret?
- Vi följer rapporterna från php.net, distributioner och BSI och bedömer nya anvisningar för era konkreta system.
- Vi tar tillsammans med er fram inventeringen av alla PHP-installationer och fastställer ansvar per server.
- Inom ramen för ett säkerhetsunderhållsavtal installerar vi uppdateringar, startar om alla processer och dokumenterar läget.
- Vid rapporter utan patch sätter vi tillfälliga åtgärder som inte går att skriva över och kontrollerar dem i efterhand.
Vanliga frågor
Finns det redan en ny PHP-säkerhetslucka efter PHP2Shell?
Den 23 oktober 2026 publicerade php.net ett meddelande om CVE-2026-115560. Kodkörning är enligt det bara möjlig vid en ovanlig sessionskonfiguration. Ett fullständigt advisory ska följa med nästa reguljära release.
Måste jag agera direkt efter varje ny rapport?
Inte varje rapport kräver samma brådska. Avgörande är allvarlighetsgrad, hur er konfiguration berörs och om en patch finns tillgänglig. Ett fastlagt förlopp hjälper att bedöma det på minuter i stället för dagar.
Var får jag först veta om nya PHP-sårbarheter?
Primärkällor är meddelandena på php.net och säkerhetsanvisningarna från er distribution, till exempel Ubuntu Security Notices, Debian Security Tracker eller Red Hat. BSI (den tyska federala myndigheten för informationssäkerhet) informerar genom varningsmeddelanden. Mediarapporter är hjälpsamma men ofta senare och mindre exakta.
Varför rapporterar distributioner ibland dagar senare än php.net?
Distributioner måste föra in rättningen i sina egna paket, bygga och testa. För äldre releaser kan det ta längre tid eller ske bara via tilläggserbjudanden. Därför lönar det sig att följa båda källorna var för sig.