Aktuellt läge: PHP2Shell. Två kritiska PHP-sårbarheter (CVSS 9,2) tillåter skadlig kod utan inloggning. Patchar sedan den 21 oktober 2026.Vad som bör göras nu →

Långtidssupport för gamla PHP-versioner: alternativ och gränser

Den som inte kan byta direkt från PHP 8.1 eller äldre hittar långtidssupport hos distributioner, tredjepartsleverantörer och kommersiella tjänster. Vad de vägarna ger, vad ni behöver skriftligt och var gränserna går.

Aktualitet 5 min läsningWebbhotell och distributioner

Kort sagt: För PHP 8.1 och äldre finns inga officiella uppdateringar från PHP-projektet längre. Långtidssupport, även kallad Extended Support, kommer från Linux-distributioner, tredjepartsrepositorier eller kommersiella tjänster som TuxCare ELS eller Zend/HeroDevs. Den kan överbrygga tiden till uppgraderingen om leverantören skriftligt bekräftar täckningen för er version. Den ersätter dock varken uppgraderingen eller underhållet av CMS och egen kod.

Varför frågan aktualiseras just nu

Den 21 oktober 2026 kom PHP2Shell-rättningarna bara för de grenar som stöds: 8.5, 8.4, 8.3 och 8.2. För 7.4, 8.0 och 8.1 har PHP-projektet endast tillhandahållit minimala backports i källkoden, alltså rättningar i källkoden utan färdig release. Enligt fackpressen berörs nästan alla versioner ända ned till PHP 5.4.

Hur stort beståndet är visar en sammanställning från CybelAngel: omkring 2,24 miljoner PHP-värdar nåbara från internet, varav enligt CybelAngel 59 procent på versioner utan kommande officiell rättning. För många företag är frågan om långtidssupport därmed inte längre teoretisk. Och den växer: PHP 8.2 når slutet på supporten den 31 december 2026.

Vad ett äldre system behöver omedelbart beskrivs i PHP 8.1 och äldre: vad som gäller nu. Det här inlägget hjälper med den medelfristiga frågan: vilken väg bär fram till uppgraderingen, och vad måste den prestera?

PHP Extended Support: vägarna i översikt

Väg Vad den levererar Gränser
Distributionens långtidsunderhåll Backports i paketen så länge distributionsversionen stöds bara för den PHP-version som distributionen levererar
Tredjepartsrepository t.ex. sury.org, enligt uppgifter med builds från 5.6 till 8.5 inte distributionens säkerhetsarkiv, förtroendefråga
Kommersiell långtidssupport patchade paket för utgångna versioner, t.ex. TuxCare ELS, Zend/HeroDevs låt bekräfta täckningen per version och CVE, löpande kostnader
Egenbygge av källkods-backports egna builds av PHP-projektets rättningar arbetskrävande, krävs på nytt vid varje sårbarhet

Om de kommersiella erbjudandena: TuxCare beskriver på sin webbplats CVE-rättningar för utgångna versioner från PHP 5.2 till 8.x, levererade via den befintliga pakethanteringen, för Windows och vanliga Linux-distributioner. En notering på samma sida meddelar PHP2Shell-rättningar för utgångna PHP-versioner. Enligt cPanels dokumentation utlovar TuxCare för sårbarheter från CVSS 7 rättningar inom 14 dagar efter publicering; på cPanel-servrar ställs domäner för det om från ea-php till alt-php. För Zend/HeroDevs hade vi inget besked om PHP2Shell-täckning.

Råd om tredjepartsvägen ger inlägget sury.org-repositoryt.

Vad ni behöver skriftligt från leverantören

Långtidssupport är en förtroendetjänst. Ni köper löftet att framtida sårbarheter stängs. Låt därför före beslutet besvara skriftligt:

  1. Vilka PHP-versioner, operativsystem och paketnamn omfattas exakt?
  2. Är CVE-2026-109618 och CVE-2026-109619 stängda för er version, med vilken paketnivå och sedan när?
  3. Hur hanteras CVE-2026-115560 och framtida uppföljande meddelanden?
  4. Ingår de tillägg ni använder eller bara PHP-kärnan?
  5. Hur kontrollerar ni själva att en patch är installerad, till exempel via paketets changelog?
  6. Hur länge gäller täckningen för er version, och hur aviseras ett slut?
  7. Vad händer med de installerade paketen när avtalet upphör?

Svar som bara hänvisar allmänt till ”alla säkerhetsluckor” räcker inte. För revisorer, försäkringsbolag och er egen dokumentation räknas den konkreta kopplingen av version, paket och CVE.

Gränserna: vad långtidssupport inte löser

Långtidssupport håller PHP-körmiljön aktuell. Allt ovanför förblir er uppgift. Och just där ligger hos äldre system oftast det större problemet.

  • Applikationen åldras vidare: Ett CMS eller en butik som kräver PHP 8.1 är ofta själv inte längre i aktuell version.
  • Bibliotek och tillägg: Composer-paket och plugins får ofta inga uppdateringar längre för gamla PHP-versioner.
  • Ingen ersättning för omstart och kontroll: Även patchade paket verkar först efter omstart av alla PHP-processer, och de tar inte bort skadlig kod som smugglats in tidigare.
  • Teknisk skuld växer: Ju längre bryggan, desto större språng vid den senare migreringen.
  • Bevisen blir mer arbetskrävande: Revisorer, kunder och försäkringsbolag frågar alltmer efter patchnivån. En utgången PHP-version med tredjepartspatchar går att styrka, men kräver mer förklaring än en version som stöds.

När är långtidssupport ändå rätt val? Tre lägen är typiska: ett fackprogram vars tillverkare ännu inte godkänner nyare PHP-versioner; ett äldre system vars avveckling redan är beslutad och som bara ska köra några månader till; eller en stor kodbas vars omställning måste planeras noga. I alla tre fallen köper långtidssupport tid för en ordnad lösning. Det är ingen lösning för system som ingen längre vill ta hand om.

Viktigt

Stod ett äldre system oskyddat på internet mellan den 17 och den 21 oktober, klargör först om det är komprometterat. Långtidssupport för ett redan angripet system skyddar ingenting.

En utträdesplan hör till

Långtidssupport är ett bra beslut när den slutar med ett datum. Fastställ till när applikationen ska köra på en version som stöds, vem som ansvarar för migreringen och vilka delmål som gäller. Hur länge PHP-grenar officiellt underhålls förklaras i PHP:s releasecykel.

Om en uppgradering eller en backport lönar sig bäst för ert system avväger inlägget PHP-uppgradering eller backport?.

Hur hjälper PHP SOS konkret?

  • Bedöma läget: Vi kontrollerar version, paketkälla och patchnivå för era äldre system och om de visar spår av ett angrepp.
  • Granska erbjudanden: Vi stämmer av en långtidssupportleverantörs skriftliga utfästelser mot ert faktiska bestånd.
  • Säkra bryggan: Fram till uppgraderingen sätter vi in övergångsåtgärderna från php.net och begränsar nåbarheten.
  • Genomföra utträdet: Med migreringen från PHP 8.1 och äldre planerar och testar vi bytet till en version som stöds.

Vanliga frågor

Vad är PHP Extended Support?

Med det menas erbjudanden som fortsätter förse PHP-versioner med säkerhetsrättningar efter den officiella supportens slut. Det kan vara Linux-distributioner, tredjepartsrepositorier eller kommersiella tjänster som TuxCare ELS eller Zend/HeroDevs.

Täcker kommersiell långtidssupport PHP2Shell?

TuxCare uppger på sin webbplats att man har tillhandahållit PHP2Shell-rättningar för utgångna PHP-versioner. För er konkreta version, ert paket och ert operativsystem bör ni ändå låta bekräfta det skriftligt och kontrollera i changelog.

Är långtidssupport ett alternativ till uppgradering?

Bara på tid. Den håller PHP-körmiljön patchad, men inte CMS, tilläggen och den egna koden, som ofta också är föråldrade. Ett slutdatum hör därför hemma i varje beslut om långtidssupport.

Vad händer när avtalet om långtidssupport tar slut?

Enligt cPanels dokumentation om TuxCare fortsätter de installerade paketen att köra, men får inga nya säkerhetsuppdateringar. Systemet är då i samma läge som tidigare, bara senare.

Gäller ämnet även PHP 8.2?

Ja, snart. PHP 8.2 får med 8.2.35 ännu PHP2Shell-rättningen, men når slutet på supporten den 31 december 2026. Den som kör 8.2 bör planera bytet nu.

Källor

Direktkontakt

Varje timme räknas. Skriv till oss nu.

Beskriv kort system, PHP-version och observation. Vi hör av oss, klarlägger läget och arbetar på distans tills incidenten är avslutad och dokumenterad.

Direkthjälp