Kort sagt: PHP2Shell-tidslinjen omfattar hittills fyra belagda datum: ett första observerat angreppsförsök den 17 oktober, förhandsbesked från php.net den 20 oktober, patcharna den 21 oktober kl. 16.00 tysk tid och ytterligare ett meddelande om CVE-2026-115560 den 23 oktober 2026. För driftansvariga innebär det: patcha, starta om alla PHP-processer och säkra loggar senast från och med den 20 oktober.
Varför en PHP2Shell-tidslinje är viktig för driftansvariga
Vid en sårbarhet av den här allvarlighetsgraden räcker det inte att veta om er server är patchad i dag. Lika viktigt är hur länge den var sårbar innan. Det tidsfönstret avgör vilka loggar ni ska säkra, vilka filer ni ska granska och om ni med goda skäl kan utesluta ett intrång.
PHP2Shell berör PHP självt, inte ett enskilt CMS. Två kritiska sårbarheter, CVE-2026-109618 och CVE-2026-109619, gör det möjligt att på distans köra skadlig kod utan inloggning. Båda har bedömts med CVSS v4.0 9,2. En lättförståelig introduktion finns under Vad är PHP2Shell?.
Kronologin nedan innehåller bara datum som är belagda per den 25 oktober 2026. Där en uppgift bygger på mediarapporter anges det.
| Datum | Händelse | Underlag |
|---|---|---|
| 17 oktober 2026 | Första observerade angreppsförsök (Amazon) | Mediarapporter |
| 20 oktober 2026 | Förhandsbesked från php.net | php.net |
| 21 oktober 2026, 14.00 UTC | Patcharna publiceras (kl. 16.00 tysk tid) | php.net |
| 23 oktober 2026 | Meddelande om CVE-2026-115560 | php.net |
| 25 oktober 2026 | Läget i den här översikten | – |
17 oktober: det första observerade angreppsförsöket
Enligt mediarapporter observerades ett första angreppsförsök den 17 oktober 2026, rapporterat av Amazon. Det var fyra dagar före patcharna. Det fanns alltså en period då angrepp redan försöktes men ingen uppdatering ännu fanns.
Om och hur många angrepp som lyckades under den fasen är inte belagt. Det viktiga är vad det betyder för er egen granskning: En server som är patchad i dag kan ha komprometterats tidigare. En patch tar inte bort inkräktad skadlig programvara och bevisar inte att inget hände dessförinnan.
20 och 21 oktober: förhandsbesked och patchar
Den 20 oktober 2026 aviserade PHP-projektet säkerhetsuppdateringarna på php.net. Den 21 oktober 2026 kl. 14.00 UTC, alltså kl. 16.00 tysk tid, följde de åtgärdade versionerna.
| Gren | Sista sårbara version | Åtgärdad i |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
För PHP 8.1 och äldre finns inga officiella uppdateringar längre, bara minimala backports av källkoden för 7.4, 8.0 och 8.1. Enligt fackpressen berörs nästan alla versioner ända tillbaka till PHP 5.4. Berörda driftlägen är PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP och LiteSpeed. Högst risk ser PHP-teamet vid mod_php, där en exploit har visats innan någon applikationskod ens körs.
Distributioner och webbhotell levererar ibland backports. Då visar till exempel Plesk fortfarande 8.2.34 fast servern är patchad. Avgörande är paketets status och leverantörens bekräftelse, inte det visade versionsnumret. Hur ni kontrollerar det ordentligt beskrivs under Kontrollera PHP-version och patchstatus rätt.
23 oktober: meddelande om CVE-2026-115560
Den 23 oktober 2026 publicerade PHP-projektet ytterligare ett meddelande, den här gången om CVE-2026-115560. Enligt det går sårbarheten bara att utnyttja vid en ovanlig konfiguration: I konfigurationen står serialize_handler php_binary eller php_serialize, applikationen ställer före session_start() om den till php via ini_set(), och session upload progress är aktiverat.
Åtgärden är enkel och bör sättas oavsett om ni känner igen den här konstellationen hos er:
; i php.ini, i FPM-poolen eller i serverkonfigurationen
; inte via ini_set() eller .user.ini
session.upload_progress.enabled = 0
Starta därefter om alla PHP-workers. Den fullständiga säkerhetsrådgivningen väntas följa med nästa reguljära bugfix-release. Tills dess är inställningen den rekommenderade tillfälliga lösningen.
Läget den 25 oktober: situation och öppna frågor
BSI (Tysklands federala myndighet för informationssäkerhet) har utlyst varningsnivå 3 / orange. Myndigheten rekommenderar omedelbar uppdatering och, om det inte går direkt, att tillfälligt ta webbservrar offline. BSI räknade med snabbt utnyttjande i stor skala; bekräftade lyckade angrepp i bredden var enligt BSI till en början inte kända. BSI:s bedömning sammanfattas på sidan Vad BSI rekommenderar om PHP2Shell.
Cloudflare rapporterade observerade angreppsförsök och har rullat ut skyddsregler, men varnar för att regler som enbart bygger på förfrågningsdata inte räcker. Palo Alto Networks (Unit 42) räknade mer än 22,6 miljoner exponerade, potentiellt sårbara instanser. Bekräftade Indicators of Compromise har inte publicerats; upptäckten bygger på beteendeanalys.
Några leverantörer har som försiktighetsåtgärd tagit webbplatser offline. Det betyder inte automatiskt att dessa sidor har hackats. Öppet är vid tidpunkten för den här översikten framför allt hur många servrar som faktiskt komprometterades under tiden före patchen.
Vad tidslinjen betyder för era loggar och kontroller
Av datumen följer tre tidsperioder: före den 17 oktober, mellan den 17 oktober och er egen patch- och omstartstidpunkt samt tiden därefter. Den mellersta perioden är den kritiska. Ju längre den varade hos er, desto grundligare bör granskningen vara.
Fackpressen rekommenderar att spara serverloggar från och med den 20 oktober 2026. Säkra även befintliga äldre loggar innan den automatiska rotationen raderar dem.
Ett enkelt sätt att säkra loggar oförändrade och dokumentera läget:
# Säkra loggar samlat (anpassa sökvägarna till ert system)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Kontrollsumma som underlag i efterhand
sha256sum /root/logs-sicherung-*.tar.gz
# Hur länge sparar systemet loggar?
grep -R "rotate" /etc/logrotate.d/
Anteckna dessutom exakt när uppdateringen installerades och när PHP-processerna startades om. Nya filer skyddar inte så länge gamla processer körs i minnet. Hur ni utvärderar säkrade loggar beskrivs i guiden Analysera webbserverloggar efter ett angrepp.
Hur hjälper PHP SOS konkret?
- Vi fastställer tillsammans med er serverns faktiska sårbarhetsfönster: paketstatus, patchtidpunkt, omstart av alla workers.
- Vi säkrar loggar och systemtillstånd spårbart innan något ändras.
- Vi söker efter beteendeavvikelser som nya PHP-filer, okända processer och ovanliga utgående förbindelser.
- Vi dokumenterar resultatet så att ledning, dataskyddsombud och försäkringsgivare kan arbeta med det.
Förloppet i detalj beskrivs i vår PHP2Shell-akuthjälp.
Vanliga frågor
När publicerades PHP2Shell-patcharna?
PHP-projektet publicerade de åtgärdade versionerna den 21 oktober 2026 kl. 14.00 UTC, alltså kl. 16.00 tysk tid. Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35.
Från vilket datum bör jag spara serverloggar?
Fackpressen rekommenderar att spara loggar från och med den 20 oktober 2026. Eftersom ett första angreppsförsök enligt mediarapporter redan observerades den 17 oktober är det värt att säkra även äldre befintliga loggar innan loggrotationen raderar dem.
Är CVE-2026-115560 lika farlig som de två första sårbarheterna?
Enligt meddelandet från den 23 oktober 2026 går sårbarheten bara att utnyttja vid en ovanlig sessionskonfiguration. Som åtgärd gäller session.upload_progress.enabled=0 tills nästa reguljära bugfix-release kommer.
Finns det bekräftade Indicators of Compromise för PHP2Shell?
Nej, per den 25 oktober 2026 har inga bekräftade Indicators of Compromise publicerats. Upptäckten bygger på beteendeanalys, till exempel ovanliga processer, nya filer och avvikande förbindelser.