Kort sagt: Den, der stadig driver PHP 8.1 eller ældre, får ikke længere officielle sikkerhedsopdateringer fra PHP-projektet, heller ikke til PHP2Shell. En PHP 8.1-opgradering til en understøttet version er derfor ikke en ekstra, men den egentlige løsning. Vi gennemgår jeres applikationer, tester i en kopi, migrerer kontrolleret og sikrer tiden indtil da.
Hvorfor PHP 8.1 og ældre nu er en akut risiko
PHP2Shell-sårbarhederne CVE-2026-109618 og CVE-2026-109619 tillader kodeudførelse uden login. De er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. For PHP 8.1 og ældre findes der ikke længere officielle opdateringer, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt.
Nogle distributioner og hostingudbydere indspiller egne backports. Om jeres system hører med, skal udbyderen bekræfte for jeres konkrete pakkestatus. Uden denne bekræftelse bør I gå ud fra, at serveren er åben. Hvad det betyder i enkeltheder, beskriver PHP 8.1 og ældre: hvad der gælder nu.
PHP 8.1 opgradering: hvilken målversion?
Målet bør være en version, som PHP-projektet stadig understøtter, og som jeres applikation er frigivet til. Den aktuelle status for understøttelsen offentliggør php.net på siden om de understøttede versioner. PHP 8.2 ender den 31.12.2026; et skifte til 8.2 ville altså kun være et mellemtrin med et snarligt opfølgende projekt.
Hvilken PHP-version jeres CMS eller shopsystem understøtter, kontrollerer vi ud fra producentens systemkrav, f.eks. på wordpress.org, shopware.com eller typo3.org, og ikke ud fra hukommelsen. Ofte skal CMS'et selv først opdateres. Gamle webshops er et typisk tilfælde, se Shopware 5: gamle webshops på gammel PHP-version.
Hvordan hjælper PHP SOS konkret?
- Opgørelse og sikring: Vi registrerer alle applikationer, deres PHP-version, CMS-status, udvidelser og egen kode. Parallelt sætter vi de midlertidige foranstaltninger efter php.net, så risikoen falder indtil migreringen; detaljer under WAF og virtuel patching.
- Kontrollere kompatibilitet: Vi sammenholder producenternes systemkrav, kontrollerer afhængigheder med Composer og leder i egen kode efter forældede funktioner. Hvordan det ser ud ved afhængigheder, beskriver Kontrollér Composer-afhængigheder for sårbarheder.
- Test i en kopi: Applikationen kører først i et testmiljø med den nye PHP-version. Fejl retter vi dér eller dokumenterer dem til jeres bureau.
- Omstilling med vej tilbage: Den live omstilling sker i et afstemt vedligeholdelsesvindue med aktuel backup og fastlagt vej tilbage.
- Efterkontrol: Vi kontrollerer fejllogs og centrale funktioner efter omstillingen og fjerner den gamle PHP-version, når den ikke længere er nødvendig.
Et ufarligt blik på, hvilke websites der bruger hvilken PHP-version, er på mange systemer muligt via de kørende FPM-pools:
# vis kørende PHP-FPM-master og pools
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# installerede PHP-versioner (Debian/Ubuntu)
ls /etc/php/
En opgradering til en ny PHP-version fjerner ikke skadelig software, der blev indsmuglet før. Har serveren siden 17.10.2026 været uden beskyttelse på nettet, hører en kontrol for spor med.
Typiske faldgruber ved opgraderingen
De fleste problemer ved skift af PHP-version er forudsigelige, hvis man ved, hvor man skal lede:
- Forældede udvidelser: Plugins eller moduler, der ikke længere vedligeholdes, kører ofte ikke på nyere PHP-versioner. Til dem kræves der erstatning eller en tilpasning.
- Egen kode: Funktioner, som PHP nu har markeret som forældede eller fjernet, fører til advarsler eller nedbrud. Strengere typekontrol afslører gamle programmeringsfejl.
- Afhængigheder: Biblioteker, der er indbundet via Composer, kræver til dels selv nye versioner og trækker yderligere ændringer efter sig.
- PHP-udvidelser på serveren: Ikke enhver udvidelse, som var installeret under den gamle version, findes automatisk til den nye.
- Cronjobs og kommandolinjen: Websitet kører allerede på den nye version, men planlagte opgaver kalder stadig den gamle PHP-version.
Den, der kontrollerer disse punkter på forhånd, forkorter omstillingen og undgår overraskelser i live-driften.
Hvad I får, og hvad vi har brug for
I får et overblik over alle applikationer med start- og målversion, en migreringsplan med rækkefølge og risici, en testprotokol, dokumentationen af omstillingen og en liste over punkter, som jeres bureau eller udvikler endnu skal udføre.
Vi har brug for fra jer:
- server- eller panel-adgang og adgang til CMS-backends
- adgang til kildekode og repository ved egenudviklinger
- kontakt til bureau eller udvikler, som kender applikationen
- et testmiljø eller tilladelse til at oprette et
- vedligeholdelsesvinduer og en kontaktperson til godkendelsen
Hvad vi ikke lover
Vi lover ikke, at enhver gammel applikation kører uden ændringer på en ny PHP-version. Ved systemer uden videreudvikling kan en større ombygning eller et skifte være nødvendigt; det siger vi åbent, så snart det tegner sig. Kompatibilitetsudsagn bygger vi på producenternes oplysninger. Og midlertidige foranstaltninger er ingen erstatning for migreringen, men overbryder kun tiden. Langsigtede risici ved forældede versioner beskriver PHP end-of-life: risici ved forældede versioner.
Ofte stillede spørgsmål
Er PHP 8.1 berørt af PHP2Shell?
Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt. For PHP 8.1 og ældre findes der ingen officielle opdateringer fra PHP-projektet, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Nogle distributioner indspiller egne backports, det skal den pågældende udbyder bekræfte.
Til hvilken PHP-version bør jeg opgradere?
Til en version, som PHP-projektet stadig aktivt understøtter, og som jeres applikation er frigivet til ifølge producentens systemkrav. PHP 8.2 når slutningen af understøttelsen den 31.12.2026 og er derfor kun i begrænset omfang fornuftigt som mål.
Kan jeg ikke bare skifte PHP-version i hostingpanelet?
Teknisk kan det ofte lade sig gøre med ét klik. Om applikationen kører bagefter, afhænger af CMS-version, udvidelser og egen kode. Uden test risikerer I udfald eller fejlbehæftede funktioner, f.eks. i en webshops kasse.
Hvad nu, hvis mit CMS ikke understøtter den nye PHP-version?
Så skal CMS'et først opdateres, under omstændigheder til en ny hovedversion. Ved systemer uden videreudvikling kan et skifte være nødvendigt. Indtil da sikrer vi serveren med midlertidige foranstaltninger.