# PHP 8.1 och äldre: uppgradering till en version med support

> Uppgradera PHP 8.1 utan blindflygning: Vi granskar applikationer, testar i en kopia, migrerar till en PHP-version med support och skyddar övergången.

Källa: https://phpsos.de/sv/leistungen/php-migration-legacy/  
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:** Den som fortfarande kör PHP 8.1 eller äldre får inga officiella säkerhetsuppdateringar längre från PHP-projektet, inte heller för PHP2Shell. En uppgradering av PHP 8.1 till en version med support är därför ingen kringsyssla utan den egentliga lösningen. Vi kontrollerar era applikationer, testar i en kopia, migrerar kontrollerat och skyddar tiden dit.

## Varför PHP 8.1 och äldre nu är en akut risk

PHP2Shell-sårbarheterna CVE-2026-109618 och CVE-2026-109619 tillåter kodkörning utan inloggning. De är åtgärdade i PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre, bara minimala backports i källkoden för 7.4, 8.0 och 8.1. Enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4.

Vissa distributioner och webbhotell levererar egna backports. Om ert system hör dit måste leverantören bekräfta för just er paketstatus. Utan den bekräftelsen bör ni utgå från att servern är öppen. Vad det innebär i detalj beskrivs i [PHP 8.1 och äldre: Vad som gäller nu](https://phpsos.de/sv/php2shell/php-8-1-und-aelter/).

## Uppgradera PHP 8.1: vilken målversion?

Målet bör vara en version som PHP-projektet fortfarande stöder och som er applikation godkänner. Den aktuella supportstatusen publicerar php.net på sidan för versioner som stöds. PHP 8.2 upphör den 31 december 2026; ett byte till 8.2 vore alltså bara ett mellansteg med ett nytt projekt inom kort.

Vilken PHP-version ert CMS eller butikssystem stöder kontrollerar vi mot tillverkarens systemkrav, till exempel på wordpress.org, shopware.com eller typo3.org, och inte ur minnet. Ofta måste CMS:et självt uppdateras först. Gamla butiker är ett typiskt fall, se [Shopware 5: gamla butiker på gammal PHP-version](https://phpsos.de/sv/plattformen/shopware-5/).

## Hur hjälper PHP SOS konkret?

1. **Inventering och skydd:** Vi kartlägger alla applikationer, deras PHP-version, CMS-status, tillägg och egen kod. Parallellt sätter vi in övergångsåtgärderna enligt php.net så att risken sjunker fram till migreringen; detaljer under [WAF och virtuell patchning](https://phpsos.de/sv/leistungen/waf-virtuelles-patching/).
2. **Kontrollera kompatibilitet:** Vi stämmer av tillverkarnas systemkrav, kontrollerar beroenden med Composer och söker i den egna koden efter föråldrade funktioner. Hur det ser ut för beroenden beskrivs i [Kontrollera Composer-beroenden efter sårbarheter](https://phpsos.de/sv/ratgeber/composer-abhaengigkeiten-pruefen/).
3. **Test i en kopia:** Applikationen körs först i en testmiljö med den nya PHP-versionen. Fel åtgärdar vi där eller dokumenterar dem för er byrå.
4. **Omställning med återväg:** Den skarpa omställningen sker i ett avstämt underhållsfönster med aktuell säkerhetskopia och en fastlagd återväg.
5. **Efterkontroll:** Vi kontrollerar felloggar och centrala funktioner efter omställningen och tar bort den gamla PHP-versionen när den inte längre behövs.

Ett ofarligt sätt att se vilka webbplatser som använder vilken PHP-version går på många system via de körande FPM-poolerna:

```bash
# visa körande PHP-FPM-master och pooler
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# installerade PHP-versioner (Debian/Ubuntu)
ls /etc/php/
```

> **Viktigt:**
> En uppgradering till en ny PHP-version tar inte bort skadlig programvara som fördes in tidigare. Om servern har legat oskyddad på nätet sedan den 17 oktober 2026 hör en kontroll av spår till.

## Typiska fallgropar vid uppgraderingen

De flesta problem vid byte av PHP-version är förutsägbara om man vet var man ska leta:

- **Föråldrade tillägg:** Plugins eller moduler som inte längre underhålls fungerar ofta inte på nyare PHP-versioner. För dem behövs en ersättning eller en anpassning.
- **Egen kod:** Funktioner som PHP numera har markerat som föråldrade eller tagit bort leder till varningar eller avbrott. Strängare typkontroller avslöjar gamla programmeringsfel.
- **Beroenden:** Bibliotek som är inkopplade via Composer kräver ibland själva nya versioner och drar med sig ytterligare ändringar.
- **PHP-tillägg på servern:** Inte varje tillägg som var installerat under den gamla versionen finns automatiskt för den nya.
- **Cronjobb och kommandorad:** Webbplatsen körs redan på den nya versionen, men schemalagda uppgifter anropar fortfarande den gamla PHP-versionen.

Den som kontrollerar dessa punkter i förväg förkortar omställningen och undviker överraskningar i skarp drift.

## Vad ni får och vad vi behöver

Ni får en översikt över alla applikationer med utgångs- och målversion, en migreringsplan med ordning och risker, ett testprotokoll, dokumentationen av omställningen och en lista över punkter som er byrå eller utvecklare fortfarande måste klara av.

Vi behöver från er:

- **Server- eller panelåtkomst** och åtkomst till CMS-backends
- **Åtkomst till källkod och repository** vid egenutveckling
- **Kontakt med byrå eller utvecklare** som känner applikationen
- **en testmiljö** eller godkännande att skapa en
- **Underhållsfönster** och en kontaktperson för godkännandet

## Vad vi inte lovar

Vi lovar inte att varje gammal applikation fungerar utan ändringar på en ny PHP-version. För system utan fortsatt utveckling kan en större ombyggnad eller ett byte bli nödvändigt; det säger vi öppet så snart det börjar framstå. Kompatibilitetsuttalanden stöder vi på tillverkarnas uppgifter. Och övergångsåtgärder är ingen ersättning för migreringen utan överbryggar bara tiden. Långsiktiga risker med föråldrade versioner beskrivs i [PHP End of Life: risker med föråldrade versioner](https://phpsos.de/sv/ratgeber/php-end-of-life-risiken/).


## Vanliga frågor

**Berörs PHP 8.1 av PHP2Shell?**  
Enligt facktidningarna berörs nästan alla versioner ända tillbaka till PHP 5.4. För PHP 8.1 och äldre finns inga officiella uppdateringar från PHP-projektet, bara minimala backports i källkoden för 7.4, 8.0 och 8.1. Vissa distributioner levererar egna backports, och det måste respektive leverantör bekräfta.

**Till vilken PHP-version bör jag uppgradera?**  
Till en version som PHP-projektet fortfarande aktivt stöder och som er applikation godkänns för enligt tillverkarens systemkrav. PHP 8.2 når slutet på supporten den 31 december 2026 och är därför bara delvis meningsfullt som mål.

**Kan jag inte bara byta PHP-version i hostingpanelen?**  
Tekniskt går det ofta med ett klick. Om applikationen fortfarande fungerar efteråt beror på CMS-version, tillägg och egen kod. Utan test riskerar ni avbrott eller felaktiga funktioner, till exempel i en butiks kassa.

**Vad gäller om mitt CMS inte stöder den nya PHP-versionen?**  
Då måste CMS:et uppdateras först, under vissa omständigheter till en ny huvudversion. För system utan fortsatt utveckling kan ett byte bli nödvändigt. Tills dess skyddar vi servern med övergångsåtgärder.

## 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, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)