Kort sagt: Til PHP 8.1-sårbarheden PHP2Shell findes der ingen officiel opdatering. PHP-projektet leverer til 7.4, 8.0 og 8.1 kun minimale kildekode-backports, ikke færdige releases. Den, der driver disse versioner, har brug for en bekræftet backport fra sin udbyder eller midlertidige foranstaltninger og bør planlægge skiftet til en understøttet version nu.
Findes der en opdatering mod PHP 8.1-sårbarheden?
Ikke fra PHP-projektet. Den 21. oktober 2026 udkom officielle rettelser kun til de understøttede grene: 8.5.12, 8.4.27, 8.3.36 og 8.2.35. PHP 8.1 og ældre versioner får ikke længere officielle opdateringer.
Berørt er de alligevel. Ifølge fagpressen rækker de sårbare versioner næsten uafbrudt tilbage til PHP 5.4. Den, der driver en af disse versioner offentligt tilgængeligt, har altså en kritisk sårbarhed med CVSS v4.0 9,2 uden en færdig rettelse.
For mange virksomheder er det en overraskelse, for sådanne systemer kører ofte stabilt og upåfaldende i årevis. At en version ikke længere får opdateringer, mærker man ikke i hverdagen, før en sårbarhed som PHP2Shell dukker op. Kildekode-backportene til 7.4, 8.0 og 8.1 er en undtagelse og ingen genoptagelse af den almindelige vedligeholdelse.
Hvad kildekode-backportene betyder
Til 7.4, 8.0 og 8.1 findes der minimale kildekode-backports. Det er rettelser i kildekoden, som er overført til disse ældre grene. De er ikke en officiel release med versionsnummer, testet pakke og changelog.
Praktisk betyder det: Nogen skal overtage backporten, bygge PHP af den påny, teste og udrulle. Det kan ske på tre måder:
- Jeres distribution overtager rettelsen i sine pakker, f.eks. som led i en langtidsvedligeholdelse.
- Jeres hostingudbyder bygger egne PHP-pakker og indspiller backporten.
- I selv eller en tjenesteudbyder bygger PHP af kildekoden. Det er krævende og skal gentages ved hver yderligere sårbarhed.
Om jeres system har fået en backport, kontrollerer I i pakkens 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-familien
Pakkenavne afviger fra distribution til distribution og pakkekilde. Mangler en indførsel, så spørg udbyderen. Hvordan kontrollen fungerer i detaljer, står under Kontrollér PHP-version og rettelsesstatus korrekt.
Sikr den gamle server indtil migreringen
Så længe ingen bekræftet backport kører, gælder php.nets midlertidige foranstaltninger: ikke-overskrivbar memory_limit=-1 med hukommelsesgrænse via cgroup, post_max_size på 8M eller 32M med upload_max_filesize derunder og session.upload_progress.enabled=0 i serverkonfigurationen, derefter genstart af alle workers. De er ingen fuld beskyttelse. Detaljer under Akutforanstaltninger, hvis I endnu ikke kan rette.
Hertil kommer foranstaltninger, der mindsker tilgængeligheden: administrationsområder kun via VPN eller frigivne IP-adresser, slukke ikke-nødvendige websites, begrænse adgangene til serveren snævert. BSI anbefaler midlertidigt at tage servere uden opdatering af nettet. For en gammel, svært migrerbar applikation kan en isoleret løsning være det mere ærlige svar end drift på det åbne internet.
Hvis en server med PHP 8.1 eller ældre siden 17. oktober har kørt ubeskyttet på nettet, så tag det alvorligt: BSI regnede med hurtig udnyttelse i stor skala. Sikr logs fra og med 20. oktober, og lad serveren kontrollere for spor, før I migrerer.
Planlæg migreringen: til hvilken version?
Målet er en version, som PHP-projektet understøtter, og som jeres applikation kan tåle. PHP 8.2 lukker sårbarheden fra 8.2.35, men når den 31.12.2026 slutningen af understøttelsen. Den, der migrerer nu, bør derfor så vidt muligt gå til 8.3 eller nyere, hvis applikationen tillader det. Den aktuelle status nævner php.net på siden om de understøttede versioner.
Hvilken PHP-version jeres CMS eller webshop understøtter, kontrollerer I efter producentens systemkrav, f.eks. på wordpress.org, shopware.com eller typo3.org. Ofte skal applikationen selv først opdateres, før PHP kan skiftes. Et typisk tilfælde er ældre webshops, som vi beskriver på siden Shopware 5. Baggrund om følgerne af forældede versioner finder I under PHP end-of-life: risici ved forældede versioner.
| Trin | Indhold |
|---|---|
| Status | PHP-version, applikation, udvidelser, egne tilpasninger |
| Krav | understøttede PHP-versioner ifølge producenten |
| Testmiljø | kopi med ny PHP-version, analysér fejlloggen |
| Omstilling | planlagt vedligeholdelsesvindue, vej tilbage forberedt |
| Efterarbejde | kontrollér overgangsværdier, opsæt overvågning |
Hvordan hjælper PHP SOS konkret?
Med migreringen af PHP 8.1 og ældre fører vi jer fra den gamle version til en understøttet:
- Sikre straks: kontrollere backportstatus, sætte midlertidige foranstaltninger, mindske tilgængeligheden.
- Kontrollere spor: sikre logs fra og med 20. oktober og analysere dem for uregelmæssigheder.
- Forberede migreringen: afklare kompatibilitet ifølge producenten, opbygge testmiljø, udbedre fejl.
- Omstille og dokumentere: indspille ny PHP-version, genstarte alle processer, dokumentere status.
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, PHP 8.1 medregnet. PHP-projektet offentliggør ikke længere officielle opdateringer til 8.1, kun minimale kildekode-backports.
Hvad er en kildekode-backport?
En rettelse i kildekoden, som er overført til en ældre versionsgren. Den er ikke en færdig release: Nogen skal overtage den, bygge PHP påny, teste og udrulle. Det kan jeres distributionsudbyder, jeres hostingudbyder eller en tjenesteudbyder tage sig af.
Er det nok at skifte til PHP 8.2?
På kort sigt lukker PHP 8.2.35 sårbarheden. PHP 8.2 når dog den 31.12.2026 slutningen af understøttelsen. Den, der alligevel migrerer, bør derfor undersøge, om applikationen ifølge producenten også understøtter 8.3 eller nyere.
Min webshop kører kun med PHP 7.4. Hvad nu?
Så er to ting nødvendige parallelt: sikre serveren med midlertidige foranstaltninger og isolation og bringe applikationen op på en version, der kan tåle en understøttet PHP-version. Hvilken det er, står i producentens systemkrav.