# PHP End of Life: risker med föråldrade versioner

> Förstå PHP End of Life: vad som händer efter supportens slut, varför PHP 8.1 och äldre är kritiska efter PHP2Shell och hur ni planerar bytet till 8.2+.

Källa: https://phpsos.de/sv/ratgeber/php-end-of-life-risiken/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** PHP End of Life betyder: PHP-projektet levererar inga säkerhetsuppdateringar längre för den grenen. PHP2Shell visar konsekvenserna tydligt, för för PHP 8.1 och äldre finns ingen officiell rättning, och PHP 8.2 tar slut den 31 december 2026. Den som i dag kör på en gammal gren bör planera bytet nu, inte först vid nästa nödläge.

## Vad PHP End of Life betyder

Varje PHP-gren, till exempel 8.2 eller 8.3, underhålls av PHP-projektet bara under en begränsad tid. Först kommer felrättningar och säkerhetsuppdateringar, senare bara säkerhetsuppdateringar. Därefter upphör supporten helt. De aktuella tidsperioderna publicerar php.net på sidan om versioner som stöds.

Efter supportens slut fortsätter programvaran visserligen att köra. Blir en ny sårbarhet känd finns det dock ingen patch från PHP-projektet längre. Servern förblir sårbar tills någon annan rättar till eller tills ni byter till en gren som stöds.

För ledning och it-chefer är det framför allt en planeringsfråga. En migrering går att förbereda i lugn och ro. Under tidspress efter ett kritiskt meddelande blir den dyr och riskfylld.

## Vad PHP2Shell visar om föråldrade versioner

Den 21 oktober 2026 publicerade PHP-projektet patchar för två kritiska sårbarheter, CVE-2026-109618 och CVE-2026-109619. Båda gör det möjligt att på distans köra skadlig kod utan inloggning och har bedömts med CVSS v4.0 9,2. Enligt fackpressen berörs nästan alla versioner ända tillbaka till PHP 5.4.

| Gren | Status enligt PHP-projektet | Rättning mot PHP2Shell |
|---|---|---|
| PHP 8.5 | stöds | 8.5.12 |
| PHP 8.4 | stöds | 8.4.27 |
| PHP 8.3 | stöds | 8.3.36 |
| PHP 8.2 | stöds till 31 december 2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | inga officiella uppdateringar | bara minimala backports av källkoden |
| PHP 7.3 och äldre | inga officiella uppdateringar | ingen backport från PHP-projektet |

För 8.1 och äldre återstår därmed bara vägen via backports från distributioner eller webbhotell. De visar ofta fortfarande det gamla versionsnumret fast de är patchade. Om en backport är installerad kan bara leverantören bekräfta bindande. Detaljer finns på sidan [PHP 8.1 och äldre: vad som gäller nu](https://phpsos.de/sv/php2shell/php-8-1-und-aelter/), den fullständiga översikten under [Vilka PHP-versioner berörs?](https://phpsos.de/sv/php2shell/betroffene-php-versionen/).

> **Viktigt:**
> PHP 8.2 har ännu fått rättningen mot PHP2Shell men når supportens slut den 31 december 2026. Den som nu migrerar från 8.1 bör gå direkt till en nyare gren.

## Riskerna med föråldrade PHP-versioner i överblick

Säkerhetsrisken står i förgrunden men är inte den enda. Föråldrade PHP-versioner drar med sig fler problem:

- **Inga patchar för nya sårbarheter:** Varje framtida svaghet förblir öppen eller beror på backports från tredje part.
- **Föråldrade bibliotek:** Aktuella paket förutsätter nyare PHP-grenar. Säkerhetsrättningar i bibliotek går då inte längre att installera, som guiden [composer audit](https://phpsos.de/sv/ratgeber/composer-abhaengigkeiten-pruefen/) visar.
- **Beroende av leverantören:** Webbhotell tar ibland extra betalt för gamla versioner eller lägger ned driften. Tidsgränsen bestäms då av leverantören, inte av er.
- **Problem med underlag:** Gentemot försäkringsgivare, uppdragsgivare eller vid granskningar är en version som inte stöds svår att motivera. Om det får avtalsmässiga eller rättsliga följder klarar ni ut med försäkringsgivaren eller en advokat.
- **Växande migreringsarbete:** Ju större avståndet till den aktuella versionen är, desto mer kod måste anpassas.

Särskilt ofta berörs äldre butikssystem och individuella utvecklingar som inte rörts på länge. Ett typiskt exempel är [Shopware 5](https://phpsos.de/sv/plattformen/shopware-5/), som ofta fortfarande körs på äldre PHP-grenar.

## Inventering: vilka PHP-versioner körs hos er?

Första steget är en fullständig bild. På många servrar körs flera PHP-versioner parallellt, till exempel för en gammal webbplats som ingen längre har koll på. Dessa kommandon läser bara:

```bash
# Version på kommandoraden
php -v
# Installerade versioner under Debian/Ubuntu
ls /etc/php/
# Installerade versioner i Plesk
ls /opt/plesk/php/ 2>/dev/null
# Körande PHP-processer med versionen i namnet
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
```

Anteckna för varje webbplats: domän, PHP-version, driftläge, CMS med version, ansvarig person. Den listan är samtidigt underlaget för er nödlägesplan. Vid delat webbhotell hittar ni versionerna oftast i webbhotellets kundmeny.

## Planera migreringen: så går ni tillväga

En migrering till en gren som stöds följer i regel samma steg, oberoende av system:

1. **Fastställ målet:** välj en gren som enligt php.net stöds så länge som möjligt och som enligt tillverkarens systemkrav passar ert CMS.
2. **Kontrollera kompatibilitet:** CMS, tillägg, teman och egen kod. Uppgifterna finns på respektive tillverkares officiella sida.
3. **Sätt upp staging:** en kopia av webbplatsen med den nya PHP-versionen, inklusive databasen.
4. **Testa:** alla viktiga flöden, från kontaktformuläret till beställningsprocessen, samt felloggen efter varningar.
5. **Byt och starta om:** byt version, starta om alla PHP-processer, kontrollera funktion och fellogg.

Planera realistiskt. En liten webbplats med aktuellt CMS är ofta snabbt omställd. En butik som vuxit under flera år med många tillägg och egen kod kan däremot kräva anpassning av kod och tillägg, ända till byte till en ny huvudversion av butikssystemet. Klargör tidigt vem som beslutar internt, vilken budget som finns och om externa utvecklare måste kopplas in.

Bestäm dessutom hur ni i framtiden håller koll på supportens slut. En fast tidpunkt per år då ni jämför listan över era webbplatser med uppgifterna på php.net hindrar att samma flaskhals uppstår igen om två år.

Fram till omställningen bör ni använda php.nets tillfälliga åtgärder, till exempel `session.upload_progress.enabled=0` i serverkonfigurationen. De är inget fullständigt skydd men sänker risken.

## Hur hjälper PHP SOS konkret?

- Vi kartlägger alla PHP-versioner, driftlägen och applikationer på era servrar.
- Vi bedömer risken per webbplats och fastställer tillsammans med er ordning och målversion.
- Vi sätter in tillfälliga åtgärder fram till migreringen och inhämtar bekräftelser om backports från leverantören.
- Vi migrerar via en stagingmiljö och dokumenterar test och omställning.

Förloppet beskrivs i tjänsten [PHP 8.1 och äldre: migrering till en version som stöds](https://phpsos.de/sv/leistungen/php-migration-legacy/).


## Vanliga frågor

**När upphör stödet för PHP 8.2?**  
PHP 8.2 når den 31 december 2026 slutet på PHP-projektets stöd. Rättningen mot PHP2Shell har grenen fortfarande fått med version 8.2.35, för senare sårbarheter kan därefter ingen officiell uppdatering förväntas.

**Får PHP 8.1 en patch mot PHP2Shell?**  
Från PHP-projektet finns inga officiella uppdateringar längre för 8.1 och äldre. Det finns bara minimala backports av källkoden för 7.4, 8.0 och 8.1. Om och hur ert webbhotell eller er distribution installerar dem måste ni fråga leverantören.

**Är en gammal PHP-version med webbhotellets backports säker?**  
Backports kan stänga konkreta sårbarheter men ersätter ingen gren som stöds. De beror på leverantören, kommer ofta senare och täcker inte varje sårbarhet. Som permanent lösning är de därför olämpliga.

**Hur vet jag om mitt CMS fungerar med en ny PHP-version?**  
Kontrollera systemkraven på tillverkarens officiella sida och testa i en stagingmiljö. För tillägg och teman gäller detsamma, eftersom de ofta är den egentliga flaskhalsen.

## Källor

- [php.net: versioner som stöds](https://www.php.net/supported-versions.php)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [TechTarget: PHP2Shell, 22 miljoner exponerade servrar i riskzonen](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)