21. oktober 2026 kl. 14.00 UTC publiserte PHP-teamet rettelser for to kritiske sårbarheter, CVE-2026-109618 og CVE-2026-109619, kjent som PHP2Shell. Vi startet omtrent en time senere. Rundt kl. 17.00 UTC var alle serverne vi drifter tettet: 88 prosjekter under vår support. Her forteller vi hvordan vi gjorde det og hva som sinket oss, fordi de samme hindringene finnes på mange servere som ingen har patchet ennå.
Trenger du bare å vite om nettstedet ditt er rammet og hva du skal spørre hosten om, kan du lese vår første artikkel om PHP2Shell.
Første time: kutt angrepsveien overalt
Det tar tid å installere rettet PHP på dusinvis av servere. Det tar minutter å slå av den sårbare mekanismen. Derfor gjorde vi det først, på hver server, før vi bygde noe som helst.
Sikkerhetsvarselet fra PHP nevner session.upload_progress.enabled som en av veiene inn for CVE-2026-109619. Vi satte den til off i hovedkonfigurasjonen for hver PHP-versjon på hver server og startet PHP-prosessene på nytt. Varselet advarer om at .user.ini og ini_set() ikke holder, så vi endret filene på servernivå. På PHP 8.5 slo vi også av fatal_error_backtraces, slik varselet foreslår.
Dette stengte bare den bekreftede sesjonsveien for CVE-2026-109619. CVE-2026-109618 krevde selve oppdateringen.
Tre typer servere, tre måter å patche på
De 88 prosjektene våre kjører på ulike oppsett, og hvert av dem trengte sin egen vei.
Servere med PHP fra distribusjonens pakker. Her kommer rettelsen fra pakkevedlikeholderne. Ubuntu publiserte rettede pakker samme dag som utgivelsen. Én ting å passe på hvis du sjekker en slik server: etter oppdateringen kan php -v fortsatt vise det gamle nummeret, for eksempel 8.3.6, fordi Ubuntu retter pakken og beholder versjonen. Sjekk pakkeversjonen i stedet.
Servere som kjøres gjennom et kontrollpanel for hosting. Flere servere bruker aaPanel, som bygger sin egen PHP. På utgivelsesdagen hadde panelet ingen oppdatert PHP. Å vente på panelet betydde å la disse serverne stå åpne i ukjent tid, så vi bygde PHP selv.
Docker-containere. Noen prosjekter kjører PHP i containere bygget fra eksisterende images. Å bygge og rulle ut en hel applikasjon på nytt midt i en hendelse gir ekstra risiko. Vi patchet i stedet PHP inne i containerne som kjørte, og la inn ordentlig ombygging av images til senere.
Bygge PHP selv uten å ødelegge panelet
Et panels PHP-build skiller seg fra en standard build. Bygger du PHP med standardvalg og legger den inn, mangler det utvidelser, og panelet kjenner ikke lenger igjen sin egen PHP.
Vi skrev ett byggeskript og kjørte det per PHP-versjon på hver panelserver:
- det leser de nøyaktige configure-valgene fra PHP-en som allerede er installert, slik at den nye builden får samme utvidelser og stier;
- det bygger den rettede versjonen fra offisiell kildekode;
- det sjekker hvilke OpenSSL- og curl-biblioteker den nye binærfilen lenker mot. Panelet lenker noen PHP-versjoner mot sine egne eldre kopier av disse bibliotekene, så skriptet sørger for at den nye builden bruker de samme;
- det tar backup av de gamle binærfilene, installerer de nye og starter PHP på nytt;
- hvis PHP ikke kommer opp igjen, legger det tilbake de gamle binærfilene av seg selv.
Med skriptet kunne vi patche én PHP-versjon på én server, sjekke nettstedene og gjenta på neste uten håndarbeid hver gang.
PHP 7.4, 8.0 og 8.1: ingen offisiell utgivelse
PHP-teamet gir ikke lenger ut nye versjoner i disse grenene. For PHP2Shell publiserte de bare kildekodeendringene for 7.4, 8.0 og 8.1. Noen av prosjektene våre kjører fortsatt på disse versjonene.
For dem la vi PHP-teamets kildekoderettelser inn i siste utgivelse av hver gren og bygde den med det samme skriptet. De publiserte endringene berører også versjonsfiler og endringslogger, som ikke lar seg legge rent inn i en utgivelse, så vi tok bare med kodeendringene.
Én server kjørte PHP 7.4 fra pakkene i Ubuntu 20.04. For den Ubuntu-utgaven kommer rettelsen bare gjennom Ubuntus utvidede sikkerhetsvedlikehold (ESM), som serveren ikke bruker. Vi bygde PHP 7.4 med de samme byggeflaggene som Ubuntu bruker, og byttet bare ut PHP-FPM-binærfilen, med originalen liggende ved siden av. En senere pakkeoppdatering ville skrive over builden vår, så vi noterte det i prosjektets dokumentasjon.
Containere: patchet nå, bygget på nytt senere
For hver container bygde vi rettet PHP i en ren kopi av det offisielle imaget for samme operativsystem, og kopierte deretter bare PHP-binærfilene og utvidelsene som trengtes inn i containeren som kjørte, med backup av originalene inne i containeren.
Ett Alpine-basert image trengte de samme ekstra kildekodepatchene som det offisielle PHP-imaget for Docker bruker, ellers feilet builden med en nyere kompilator.
Haken ved denne metoden: rettelsen lever bare til noen lager containeren på nytt fra det gamle imaget. Har teamet ditt patchet containere på denne måten, må ombygging av imaget inn i planen, ellers kommer sårbarheten tilbake ved neste deploy.
Etter patchingen: loggene
Da alle serverne kjørte rettet PHP, gikk vi gjennom webserver- og PHP-loggene på alle serverne etter forespørsler som passet med måten sårbarhetene kunne utnyttes på. Vi fant ingen tegn på utnyttelse.
Det vi ville sagt til en nettstedeier etter den kvelden
- Hostens tempo er ditt tempo. Kommer PHP-en din fra et panel eller en leverandør som venter på det, står nettstedet ditt åpent til de gjør noe. Spør dem i dag hvilken versjon du kjører.
- Gammel PHP koster fortsatt. PHP 8.1 og eldre fikk denne gangen bare rettelser i kildekoden. Neste gang kommer det kanskje ingenting. Støtten for PHP 8.2 slutter 31. desember 2026.
- Containere og egne builds trenger en eier. Ingen oppdaterer dem automatisk. Noen må vite at de finnes og hvordan de bygges på nytt.
Den automatiske overvåkingen vår går døgnet rundt, og ingeniørene våre reagerer når den melder en hendelse.
Trenger du det samme for serverne dine
Vi sjekker PHP-versjonen din og oppdaterer den innen én arbeidsdag. Skriv til oss.
For løpende oppfølging kan du se på serverdrift, support for nettsteder og DevOps. Hvis mobilappen din snakker med en PHP-backend, trenger den backenden den samme oppdateringen; det dekker vi under support for mobilapper. Vil du vite om noe annet står åpent, kan du bestille en penetrasjonstest.
Kilder
- Kunngjøring og tiltak fra PHP-teamet: https://www.php.net/archive/2026.php
- Sikkerhetsvarsler: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w og https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu: https://ubuntu.com/blog/php2shell-vulnerability-fixes-available