# PHP End of Life: risici ved forældede versioner

> Forstå PHP End of Life: hvad der sker efter supportens udløb, hvorfor PHP 8.1 og ældre er kritisk efter PHP2Shell, og hvordan I planlægger skiftet til 8.2+.

Kilde: https://phpsos.de/da/ratgeber/php-end-of-life-risiken/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** PHP End of Life betyder: PHP-projektet leverer ikke længere sikkerhedsopdateringer til denne gren. PHP2Shell viser følgerne tydeligt, for til PHP 8.1 og ældre findes der ingen officiel rettelse, og PHP 8.2 udløber den 31.12.2026. Den, der i dag kører på en gammel gren, bør planlægge skiftet nu, ikke først ved den næste nødsituation.

## Hvad PHP End of Life betyder

Hver PHP-gren, f.eks. 8.2 eller 8.3, vedligeholdes af PHP-projektet kun i en begrænset periode. Først er der fejlrettelser og sikkerhedsopdateringer, senere kun sikkerhedsopdateringer. Derefter ophører understøttelsen helt. De aktuelle perioder offentliggør php.net på siden om understøttede versioner.

Efter supportens udløb kører softwaren vel videre. Bliver en ny sårbarhed kendt, findes der dog ikke længere en patch fra PHP-projektet. Serveren forbliver sårbar, indtil en anden udbedrer, eller indtil I skifter til en understøttet gren.

For ledelse og IT-chef er det først og fremmest et planlægningsspørgsmål. En migrering kan forberedes i ro og mag. Under tidspres efter en kritisk meddelelse bliver den dyr og risikabel.

## Hvad PHP2Shell viser om forældede versioner

Den 21.10.2026 offentliggjorde PHP-projektet patches til to kritiske sårbarheder, CVE-2026-109618 og CVE-2026-109619. Begge muliggør kørsel af skadelig kode på afstand uden login og er vurderet til CVSS v4.0 9,2. Ifølge fagpressen er næsten alle versioner helt tilbage til PHP 5.4 berørt.

| Gren | Status ifølge PHP-projektet | PHP2Shell-rettelse |
|---|---|---|
| PHP 8.5 | understøttet | 8.5.12 |
| PHP 8.4 | understøttet | 8.4.27 |
| PHP 8.3 | understøttet | 8.3.36 |
| PHP 8.2 | understøttet til 31.12.2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | ingen officielle opdateringer | kun minimale kildekode-backports |
| PHP 7.3 og ældre | ingen officielle opdateringer | ingen backport fra PHP-projektet |

For 8.1 og ældre er der dermed kun vejen via backports fra distributioner eller hostingudbydere. Disse viser ofte fortsat det gamle versionsnummer, selv om de er patchet. Om en backport er indspillet, kan kun udbyderen bekræfte bindende. Enkeltheder står på siden [PHP 8.1 og ældre: hvad der gælder nu](https://phpsos.de/da/php2shell/php-8-1-und-aelter/), det fulde overblik under [Hvilke PHP-versioner er berørt?](https://phpsos.de/da/php2shell/betroffene-php-versionen/).

> **Vigtigt:**
> PHP 8.2 har endnu fået PHP2Shell-rettelsen, men når den 31.12.2026 supportens udløb. Den, der nu migrerer fra 8.1, bør sigte direkte mod en nyere gren.

## Risiciene ved forældede PHP-versioner i overblik

Sikkerhedsrisikoen står i forgrunden, men er ikke den eneste. Forældede PHP-versioner trækker yderligere problemer efter sig:

- **Ingen patches til nye sårbarheder:** Enhver fremtidig svaghed forbliver åben eller afhænger af tredjeparters backports.
- **Forældede biblioteker:** Aktuelle pakker forudsætter nyere PHP-grene. Sikkerhedsrettelser i biblioteker kan så ikke længere indspilles, som vejledningen [composer audit](https://phpsos.de/da/ratgeber/composer-abhaengigkeiten-pruefen/) viser.
- **Afhængighed af udbyderen:** Hostingudbydere beregner til tider tillæg for gamle versioner eller indstiller driften. Fristen bestemmer så udbyderen, ikke I.
- **Problemer med dokumentation:** Over for forsikringsselskaber, kunder eller ved audits er en ikke-understøttet version svær at begrunde. Om der heraf opstår kontraktlige eller juridiske følger, afklarer I med forsikringsselskab eller advokat.
- **Voksende migreringsarbejde:** Jo større afstand til den aktuelle version, desto mere kode skal tilpasses.

Særligt ofte berørt er ældre shopsystemer og individuelle udviklinger, der længe ikke er rørt. Et typisk eksempel er [Shopware 5](https://phpsos.de/da/plattformen/shopware-5/), som ofte stadig kører på ældre PHP-grene.

## Bestandsopgørelse: hvilke PHP-versioner kører hos jer?

Det første skridt er et fuldstændigt billede. På mange servere kører flere PHP-versioner parallelt, f.eks. til et gammelt website, som ingen længere har på radaren. Disse kommandoer læser kun:

```bash
# Kommandolinjens version
php -v
# Installerede versioner under Debian/Ubuntu
ls /etc/php/
# Installerede versioner i Plesk
ls /opt/plesk/php/ 2>/dev/null
# Kørende PHP-processer med version i navnet
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Notér for hvert website: domæne, PHP-version, driftsform, CMS med version, ansvarlig person. Denne liste er samtidig grundlaget for jeres nødplan. Ved shared hosting finder I versionerne som regel i hosterens kundemenu.

## Planlæg migreringen: sådan går I frem

En migrering til en understøttet gren følger som regel de samme trin, uafhængigt af systemet:

1. **Fastlæg målet:** vælg en gren, der ifølge php.net understøttes så længe som muligt, og som ifølge producentens systemkrav passer til jeres CMS.
2. **Kontrollér kompatibilitet:** CMS, udvidelser, temaer og egen kode. Oplysningerne står på den pågældende producents officielle side.
3. **Opsæt staging:** en kopi af websitet med den nye PHP-version, inklusive database.
4. **Test:** alle vigtige forløb, fra kontaktformularen til bestillingsprocessen, dertil fejlloggen for advarsler.
5. **Omstil og genstart:** skift version, genstart alle PHP-processer, kontrollér funktion og fejllog.

Planlæg realistisk. Et lille website med et aktuelt CMS er ofte hurtigt omstillet. En shop, der er vokset gennem årene med mange udvidelser og egen kode, kan derimod kræve en tilpasning af kode og udvidelser, helt op til skiftet til en ny hovedversion af shopsystemet. Afklar tidligt, hvem der internt beslutter, hvilket budget der står til rådighed, og om eksterne udviklere skal inddrages.

Fastlæg desuden, hvordan I fremover holder øje med supportens udløb. En fast dato om året, hvor I sammenholder listen over jeres websites med oplysningerne på php.net, forhindrer, at den samme flaskehals opstår igen om to år.

Indtil omstillingen bør I bruge overgangsforanstaltningerne fra php.net, f.eks. `session.upload_progress.enabled=0` i serverkonfigurationen. De er ikke en fuldstændig beskyttelse, men sænker risikoen.

## Hvordan hjælper PHP SOS konkret?

- Vi kortlægger alle PHP-versioner, driftsformer og applikationer på jeres servere.
- Vi vurderer risikoen pr. website og fastlægger sammen med jer rækkefølge og målversion.
- Vi gennemfører overgangsforanstaltninger frem til migreringen og indhenter bekræftelser om backports hos udbyderen.
- Vi migrerer via et staging-miljø og dokumenterer test og omstilling.

Forløbet beskriver ydelsen [PHP 8.1 og ældre: migrering til en understøttet version](https://phpsos.de/da/leistungen/php-migration-legacy/).


## Ofte stillede spørgsmål

**Hvornår ophører understøttelsen af PHP 8.2?**  
PHP 8.2 når den 31.12.2026 slutningen af PHP-projektets understøttelse. PHP2Shell-rettelsen har grenen endnu fået med version 8.2.35; for senere sårbarheder kan der derefter ikke forventes en officiel opdatering.

**Får PHP 8.1 en patch mod PHP2Shell?**  
Fra PHP-projektet findes der for 8.1 og ældre ikke længere officielle opdateringer. Der findes kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Om og hvordan jeres hoster eller distribution indspiller dem, skal I forhøre jer om hos udbyderen.

**Er en gammel PHP-version med hosterens backports sikker?**  
Backports kan lukke konkrete sårbarheder, men erstatter ikke en understøttet gren. De afhænger af udbyderen, kommer ofte senere og dækker ikke enhver sårbarhed. Som varig løsning er de derfor uegnede.

**Hvordan ved jeg, om mit CMS kører med en ny PHP-version?**  
Kontrollér systemkravene på producentens officielle side, og test i et staging-miljø. For udvidelser og temaer gælder det samme, for de er ofte den egentlige flaskehals.

## Kilder

- [php.net: Understøttede versioner](https://www.php.net/supported-versions.php)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)