Kort sagt: Den som vill låta installera en PHP-uppdatering behöver mer än nya paket: Avgörande är rätt paketstatus, omstart av alla PHP-processer och ett belägg för det. Precis det levererar vår PHP-patchtjänst. Ni får ett skriftligt intyg per server som ni kan lägga fram internt eller gentemot tredje part.
Varför en PHP-uppdatering ensam ofta inte räcker
Sedan den 21 oktober 2026 finns patchar för PHP2Shell-sårbarheterna CVE-2026-109618 och CVE-2026-109619. BSI (Tysklands federala myndighet för informationssäkerhet) rekommenderar omedelbar uppdatering. I praktiken ser vi tre typiska fallgropar.
För det första visar versionsnumret inte alltid det verkliga läget. Distributioner och webbhotell levererar ibland backports; då meddelar till exempel Plesk fortfarande 8.2.34 fast paketstatusen är patchad. För det andra fortsätter ofta gamla PHP-processer att köra efter installationen. Nya filer på disken skyddar inte så länge de gamla workers arbetar i minnet. För det tredje körs på en server ofta flera PHP-versioner parallellt, och en av dem glöms bort.
Låt oss installera PHP-uppdateringen: de åtgärdade versionerna
| Gren | Åtgärdad från | Föregående version | Anmärkning |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | kontrollera dessutom fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | supporten upphör den 31 december 2026 |
| PHP 8.1 och äldre | inga officiella uppdateringar | – | bara minimala backports i källkoden för 7.4, 8.0, 8.1 |
För paket från distributioner eller webbhotell gäller inte siffran efter ”PHP” utan den paketstatus som leverantören bekräftar som patchad. Hur ni kontrollerar det själva står under Kontrollera PHP-version och patchstatus rätt.
Hur hjälper PHP SOS konkret?
- Inventering: Vi kartlägger alla PHP-installationer på servern, driftläget (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) och vilken webbplats som använder vilken version.
- Installera uppdateringen: Vi installerar de åtgärdade versionerna från paketkällan i er distribution, er panel eller det officiella projektet. För containrar bygger vi nya images tillsammans med er.
- Omstart av alla processer: Vi startar om PHP-FPM, Apache, LiteSpeed eller respektive workers fullständigt och kontrollerar att ingen process är äldre än uppdateringen. Bakgrund finns på Starta om PHP-FPM och alla workers.
- Funktionskontroll: Vi anropar de viktigaste sidorna och funktionerna, till exempel startsida, inloggning, formulär och kassa, och kontrollerar felloggarna.
- Intyg: Ni får per server ett protokoll med version, paketstatus, tidpunkt för omstarten och öppna punkter.
Ett typiskt kontrollsteg efter omstarten ser ut så här:
# version för PHP-CLI och FPM-binären (sökväg beroende på system)
php -v
php-fpm8.3 -v
# starttid för FPM-processerna: måste ligga efter uppdateringen
ps -o pid,lstart,cmd -C php-fpm8.3
Specialfall: paneler, containrar och flera PHP-versioner
På servrar med Plesk eller cPanel kommer PHP-versionerna ofta från panelens paketkällor och inte från distributionen. Där kontrollerar vi varje installerad version för sig, även sådana som för tillfället inte är tilldelade någon webbplats. Oanvända, föråldrade versioner tar vi bort efter överenskommelse så att de inte oavsiktligt aktiveras igen.
I Docker- och Kubernetes-miljöer räcker en uppdatering på värden inte. PHP finns i imagen, och först en nybyggd image med patchad bas, utrullad till alla körande containrar, stänger sårbarheten. Vi kontrollerar då också om äldre images fortfarande används i register eller driftsättningar. Detaljer finns under Patcha PHP i Docker-containrar.
Vid mod_php körs PHP direkt i Apache-processen. PHP-teamet bedömer risken där som högst. Efter uppdateringen måste därför Apache självt startas om fullständigt; enbart en omladdning av konfigurationen räcker inte i alla fall.
Vad ni får från oss
- ett patchprotokoll per server: installerade paket, versioner, källa, tidpunkt
- belägget för att alla PHP-processer har startats om
- en lista över kontrollerade webbplatser och funktioner
- upplysningar om system som inte kunde patchas, med motivering
- en rekommendation för den fortsatta vägen, till exempel för PHP 8.2 på grund av det nära supportslutet
Vad vi behöver från er
- Åtkomst: SSH med administratörsrättigheter eller panelåtkomst (Plesk, cPanel eller liknande)
- Underhållsfönster: när en kort omstart får ske
- Kontaktperson: för följdfrågor och för godkännandet efter funktionskontrollen
- Säkerhetskopior: bekräftelse att en aktuell säkerhetskopia finns, eller uppdraget att skapa en först
- Upplysningar om egenutveckling: särskilda PHP-tillägg eller konfigurationer som måste beaktas
Vid delat webbhotell utan egen serveråtkomst kan vi inte patcha själva. Vi hjälper er då att ställa de rätta frågorna till webbhotellet och bedöma svaret.
Vad vi inte lovar
Patchtjänsten stänger den kända sårbarheten. Den besvarar inte om servern redan var komprometterad före uppdateringen och tar inte bort skadlig programvara som förts in. Om ni vill veta det är PHP2Shell-akuthjälpen med spårsökning det lämpliga uppdraget.
För PHP 8.1 och äldre finns inga officiella uppdateringar längre. Här genomför vi övergångsåtgärder och rekommenderar migrering till en version med support. Något kompatibilitetslöfte för ert CMS ger vi inte ur minnet utan kontrollerar det mot tillverkarens systemkrav.
Vanliga frågor
Varför visar min server fortfarande den gamla PHP-versionen efter uppdateringen?
Det kan bero på två saker. Antingen har distributionen levererat en backport, och då förblir versionsnumret detsamma fast paketstatusen är patchad. Eller så körs gamla PHP-processer fortfarande i minnet och måste startas om.
Vilka PHP-versioner stänger PHP2Shell?
Sårbarheten är åtgärdad i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35, publicerade den 21 oktober 2026. För distributionspaket gäller den paketstatus som leverantören bekräftar som patchad.
Kan uppdateringen lamslå min webbplats?
En uppdatering inom samma huvudversion, till exempel från 8.3.35 till 8.3.36, är i regel oproblematisk. En kort omstart av PHP-processerna är dock nödvändig. Vi stämmer av tidsfönstret med er och kontrollerar sidorna efteråt.
Är allt klart med patchen?
För själva sårbarheten ja, så snart alla processer är omstartade. Om någon redan hade tagit sig in före patchen visar inte patchen. Det kräver en egen kontroll.