Kort gezegd: Of een PHP-upgrade of een backport de juiste keuze is, hangt ervan af hoe lang uw systeem nog moet draaien en hoe goed de backport is aangetoond. Een backport van de eigen distributie op een ondersteund besturingssysteem is een volwaardige weg. Backports uit broncode, externe bronnen en commerciële langetermijnondersteuning voor PHP 8.1 en ouder zijn bruggen met een vervaldatum. Op den duur helpt alleen de overstap naar een PHP-versie die het PHP-project nog officieel ondersteunt.
Waarom de vraag na PHP2Shell dringt
Op 21 oktober 2026 heeft het PHP-project PHP2Shell verholpen in de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 8.1 en ouder bestaan geen officiële releases meer, alleen minimale broncodebackports voor 7.4, 8.0 en 8.1. Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen.
Daarmee staan veel beheerders van oude systemen voor dezelfde vraag: volstaat het het lek op de een of andere manier te dichten, of moet nu de upgrade komen die al jaren is uitgesteld? Wat een upgrade in de praktijk betekent, beschrijft ons aanbod voor de migratie van PHP 8.1 en ouder. Wat zonder officiële update geldt, staat onder PHP 8.1 en ouder: wat nu geldt. Dit artikel helpt bij de afweging daartussen.
Welke soorten backports er zijn
„Backport“ is een verzamelbegrip. Bedoeld wordt steeds dat een correctie uit een nieuwere versie in een oudere wordt overgenomen. Wie dat doet en hoe goed het is getoetst, verschilt echter sterk.
- Backport van de distributie: Debian, Ubuntu, Red Hat en andere nemen beveiligingscorrecties over in de PHP-pakketten van hun ondersteunde releases. Het versienummer blijft daarbij vaak gelijk; volgens berichten toont bijvoorbeeld Ubuntu 24.04 na de update nog steeds 8.3.6. De fix wordt aangetoond via de pakket-changelog en de beveiligingsmeldingen van de distributie.
- Externe bron: De repository sury.org van Ondřej Surý heeft volgens berichten builds geleverd voor alle takken van 5.6 tot 8.5. Het is niet het beveiligingsarchief van Debian. Details staan onder De sury.org-repository.
- Broncodebackport van het PHP-project: Voor 7.4, 8.0 en 8.1 zijn er minimale patches in de broncode, maar geen kant-en-klare releases. Wie ze gebruikt, moet PHP zelf bouwen, testen en voortaan zelf onderhouden.
- Commerciële langetermijnondersteuning: Aanbieders zoals TuxCare ELS of Zend/HeroDevs bieden onderhoud voor oude versies. Of en wanneer ze PHP2Shell dekken, moet schriftelijk worden bevestigd; dat was in de bekende bronnen niet aangetoond. Meer daarover onder Langetermijnondersteuning voor oude PHP-versies.
PHP-upgrade of backport: de vergelijking
| Criterium | Upgrade naar ondersteunde versie | Backport (afhankelijk van de soort) |
|---|---|---|
| Bescherming tegen PHP2Shell | Ja, met 8.2.35, 8.3.36, 8.4.27 of 8.5.12 | Ja, als volledig en aangetoond |
| Toekomstige beveiligingsupdates | Officieel tot het einde van de ondersteuning van de versie | Alleen zolang de betreffende aanbieder onderhoudt |
| Bewijs | Versienummer plus herstart | Pakket-changelog met CVE-nummers, bevestiging van de aanbieder |
| Inspanning nu | Middel tot hoog, compatibiliteitstests nodig | Laag bij distributie, hoog bij zelfbouw |
| Inspanning later | Laag tot de volgende versiesprong | Groeit met elk nieuw lek |
| Risico voor de toepassing | Incompatibiliteiten met oude code en extensies | Laag, gedrag blijft grotendeels gelijk |
| Geschiktheid als duurzame oplossing | Ja | Alleen de distributiebackport binnen een ondersteund besturingssysteem |
De regel „Inspanning later“ is de belangrijkste. PHP2Shell zal niet het laatste lek zijn geweest. Elke maand op een versie zonder officiële ondersteuning betekent dat de volgende melding weer dezelfde vraag oproept.
Welke doelversie bij de upgrade?
Volgens php.net geldt voor elke PHP-tak: twee jaar actieve ondersteuning, daarna twee jaar alleen beveiligingscorrecties. Daaruit volgen deze einddata voor de beveiligingsondersteuning:
| Versie | Beveiligingsondersteuning tot |
|---|---|
| PHP 8.2 | 31 december 2026 |
| PHP 8.3 | 31 december 2027 |
| PHP 8.4 | 31 december 2028 |
| PHP 8.5 | 31 december 2029 |
Een upgrade naar 8.2 is daarom nog maar een korte tussenstop. Wie toch migreert, moet een versie met een langere horizon nastreven, voor zover CMS, shop en extensies die ondersteunen. Dat controleert u in de systeemvereisten van de fabrikant, niet uit het hoofd. Hoe de releasecyclus werkt, legt PHP-versies en releasecyclus uit.
Welke weg ook: na het installeren moeten alle PHP-processen worden herstart. Een backport die alleen op de schijf staat, beschermt niet zolang oude workers in het geheugen draaien.
Een pragmatische volgorde voor oude systemen
- Direct: overbruggende maatregelen volgens php.net nemen of het systeem tijdelijk van het netwerk halen als er geen aangetoonde fix beschikbaar is.
- In de komende dagen: een aangetoonde backport installeren, bij voorkeur uit de eigen distributie of met schriftelijke bevestiging van de aanbieder.
- Parallel: de compatibiliteit van de toepassing met een ondersteunde versie controleren en een tijdschema vaststellen.
- In de komende maanden: upgrade naar de doelversie, voorbereid in een testkopie, met terugvalplan.
De backport als brug zien, niet als doel, is de beslissende gedachte.
Wanneer u hiervoor geen dienstverlener nodig hebt
Draait uw server op een ondersteunde Debian, Ubuntu of RHEL en levert de distributie de backport, dan volstaat een reguliere update met herstart en een blik in de changelog. Dat redt een ervaren beheerder alleen. Hulp loont bij zelfbouw, externe bronnen, zeer oude versies of een toepassing waarvan niemand de compatibiliteit nog overziet.
Hoe helpt PHP SOS concreet?
- Wij controleren welke PHP-versies en pakketbronnen op uw servers draaien en of er een aangetoonde fix is.
- Wij installeren backports, herstarten en documenteren het bewijs via de changelog.
- Wij testen uw toepassing in een kopie tegen de doelversie en benoemen incompatibiliteiten.
- Wij plannen en begeleiden de upgrade in het kader van de migratie van PHP 8.1 en ouder.
Conclusie
De backport van de distributie is een volwaardige weg, alle andere backports zijn bruggen. Wie op PHP 8.1 of ouder vastzit, moet de backport gebruiken om tijd voor de upgrade te winnen, niet om die verder uit te stellen.
Veelgestelde vragen
Is een backport even veilig als een upgrade?
Voor het concreet verholpen lek kan een backport gelijkwaardig zijn, mits hij volledig en aangetoond is. Hij verhelpt echter alleen wat is teruggeporteerd. Een upgrade naar een ondersteunde versie levert daarnaast alle toekomstige officiële beveiligingsupdates op.
Waaraan zie ik dat mijn backport PHP2Shell dekt?
Aan de pakket-changelog: daarin moeten de CVE-nummers CVE-2026-109618 en CVE-2026-109619 genoemd zijn. Onder Debian en Ubuntu toont dat apt-get changelog, in de RHEL-familie rpm -q --changelog. Het versienummer alleen is geen bewijs.
Hoe lang krijgt PHP 8.2 nog beveiligingsupdates?
Volgens php.net eindigt de beveiligingsondersteuning voor PHP 8.2 op 31 december 2026. Wie nu naar 8.2 bijwerkt, moet de volgende stap dus meteen meeplannen.
Loont commerciële langetermijnondersteuning voor oude PHP-versies?
Ze kan een brug zijn als een upgrade op korte termijn onmogelijk is. Laat schriftelijk bevestigen of en vanaf wanneer PHP2Shell is gedekt. In de tot nu toe bekende bronnen was dat niet aangetoond.