PHP-sikkerhetsoppdatering 2026: PHP2Shell CVSS 9.2 – slik retter du det

Selve offentliggjøringen var uvanlig. 20. oktober publiserte PHPs sikkerhetsteam et varsel på forhånd, satte lanseringen til 21. oktober kl. 14:00 UTC og forbeholdt seg retten til å gi ut versjonene tidligere. CVE-identifikatorene lekket en dag før offentliggjøringen, sammen med overdrevne påstander om alvorlighet og berørte versjoner. Distributørene hadde allerede mottatt rettelsene til sine distribusjoner, og nasjonale CERT-er begynte å publisere råd før koden overhodet var offentlig. Med andre ord: ingen hadde en legitim unnskyldning for å drøye etter at utgivelsen var ute.

To sårbarheter, én hasteutgivelse

Ingen av feilene er en logisk feil i selve applikasjonen. Begge ligger i hvordan PHP gjør klar og rydder opp etter en forespørsel, og derfor kan ingen rammeverkoppdatering, plugin-oppdatering eller WAF-regel erstatte oppgraderingen av tolken.

CVE-2026-109618 — RCE via korrupsjon når PHP går tom for minne. Når PHP går tom for minne, avbryter den forespørselen i stedet for å fortsette. Rådgivningen beskriver en angrepsvei der akkurat det avbruddet treffer PHP mens interne forespørselsdata bare er delvis initialisert, slik at oppryddingstrinnet senere behandler ugyldige data som gyldige. En angriper som kan presse minnebruken helt til grensen, kan dermed styre hva som skjer videre. Dette er feilen som gjør avbøttingsrådene så kontraintuitive: leverandøren ber administratorer sørge for at PHP ikke når sitt eget minnetak, ikke stramme det inn.

CVE-2026-109619 — RCE via gjenværende global tilstand. Intern tilstand som eies av én forespørsel, kan overleve etter at minnet bak den er frigjort. Neste forespørsel som håndteres av samme arbeidsprosess, kan bruke den gjenværende tilstanden før normal initialisering nullstiller den. På en arbeidsprosess med lang levetid — nettopp det PHP-FPM, mod_php og LiteSpeed er — er gjenbruk av minne en normal, permanent tilstand, og derfor er dette ikke et obskurt tilfelle som bare rammer eksotiske oppsett.

Navnet PHP2Shell er ikke et offisielt navn fra PHP-prosjektet; det oppsto hos forskere og sikkerhetsleverandører og ble hengende ved, så du kommer til å se det i utdata fra sårbarhetsskannere, webhotell-bulletiner og CERT-råd som viser til akkurat disse to CVE-ene.

Hvem er faktisk utsatt

Rådgivningen er helt konkret: alle PHP-installasjoner som betjener webforespørsler, er utsatt. Det omfatter PHP-FPM bak nginx eller Apache, Apache med mod_php, php-cgi, LiteSpeed og FrankenPHP. Forskjellen mellom dem er hvor mye arbeid en angriper må legge i det.

Hvis du drifter WordPress, WooCommerce, Laravel, Magento, Magento-beslektede ERP-systemer eller en PHP-bookingsportal for handelsvirksomheten din, hører du hjemme i de tre første radene selv om applikasjonskoden er feilfri. For et bredere perspektiv på hvem som egentlig bør eie kjøretidsmiljøet, se guiden vår om IT-outsourcing i Tyrkia.

Sjekk versjonen din på to minutter

Fellen her er versjonsregnestykket. Distribusjoner leverer PHP 8.3.6 eller 8.2.x i årevis og tilbakeporterer sikkerhetsrettelser inn i samme synlige versjonsnummer, så php -v alene forteller deg ikke om du er beskyttet. Sammenlign tre ting.

1. Den synlige PHP-versjonen og SAPI-en som betjener trafikken.

2. Pakkeversjonen fra distribusjonen, ikke den oppstrøms. På Debian og Ubuntu er endringsloggen det ærlige svaret; på RPM-systemer slår du opp endringsloggen til pakken.

Nevner endringsloggen begge CVE-ene i den installerte versjonen, er du patchet, selv om php -v fremdeles sier 8.3.6. Det er forskjellen på et reelt sikkerhetssvar og overtro på versjonsnumre.

3. Om den kjørende prosessen har lastet inn den patchede binærfilen på nytt. En pakkeoppdatering som aldri følges av en omstart, lar gammel kode bli liggende i minnet. Sammenlign tjenestens starttidspunkt med pakkens installasjonstidspunkt:

På cPanel, Plesk, DirectAdmin eller en administrert plattform er motstykket PHP-velgeren pluss vertens egne sikkerhetsbulletiner: finn den innebygde versjonen nettstedet ditt faktisk er tildelt, ikke den nyeste som annonses i panelet. Kan ikke verten din oppgi en patchdato, bør du regne nettstedet som upatchet. Våre tjenester innen digital infrastruktur dekker denne gjennomgangen i tillegg til selve oppgraderingen; du kan også rett og slett kontakte oss med stabelen din, så forteller vi hva vi ville sjekket.

Versjoner med rettelser og EOL-avgrunnen

PHP følger en støttemodell med to år aktiv utvikling og deretter to år sikkerhetsrettelser for hver gren. Det er denne policyen som ga fire samtidige rettelser 21. oktober — og den er også grunnen til at eldre grener står alene.

To praktiske advarsler fra rådgivningen. For det første: installerer du PHP fra et fellesskapslager i stedet for fra distribusjonen din, kan lageret henge etter i sikkerhetsvinduet; vedlikeholderne av de mye brukte Remi-pakkene opplyste at de ikke ville få ut oppdateringer samme dag, så tryggeste vei er distribusjonens egne pakker eller bygging fra kildekode. For det andre: står du på PHP 8.1 eller eldre, er «å vente på verten vår» en sikkerhetsbeslutning du tar på kundenes vegne — dokumenter den eller endre den.

Patch en produksjonstjener uten å skape en hendelse

Sikkerhetsoppdateringer innenfor samme minorversjon ødelegger sjelden en applikasjon; utestede omstarter gjør det. Rekkefølgen nedenfor er den vi bruker på handelsplattformer i produksjon, og den holder risikovinduet kort uten å sette nettstedet på spill.

1. Ta snapshot først. Et snapshot fra hypervisor eller volum som du faktisk har testet, gjenopprettes på minutter, og det gjør beslutningen om å patche billig.
2. Gjenskap versjonen i staging. Samme gren, samme utvidelser, samme PHP-konfigurasjonsfiler og en kopi av produksjonsdataene. Kjør kasseflyten, stien for tilbudsforespørsler og betalingsveiene, ikke bare forsiden.
3. Oppgrader pakkesettet som én enhet. Å blande en oppgradert CLI med en gammel FPM-binærfil er nettopp hvordan man ender opp med patchet php -v og en upatchet vei for webtrafikk: apt-get update && apt-get install --only-upgrade 'php8.3-*', eller dnf update --security 'php*' på RPM-verter.
4. Start prosessen som betjener forespørsler på nytt, og verifiser at den startet på nytt. systemctl restart php8.3-fpm (eller last Apache på nytt / start LiteSpeed på nytt), sjekk deretter tjenestens starttidspunkt på nytt og kjør spørringene på versjon og endringslogg igjen.
5. Følg med på feilloggen i én time. OOM-meldinger, nye signaturer av fatale feil og uvanlig høye 5xx-andeler er signaler om at avbøttingsinnstillingene nedenfor kan trenge justering — ikke grunner til å utsette oppgraderingen.
6. Lagre bevisene. Pakkeversjon, endringslogglinjen som nevner begge CVE-ene, og tidsstempelet for omstarten. Kunder, revisorer og kontrollgjennomganger etter ISO 27001-modellen ber om akkurat dette, og det tar ti sekunder å lagre.

Der oppgraderingen må vente — en validert ERP-integrasjon, en lanseringskalender under embargo, en runde med kundegodkjenning — setter du en kompenserende kontroll foran den samme dagen, i stedet for å la porten stå åpen og håpe. Akkurat dette anbefalte rådene fra nasjonale CERT-er i nettopp denne situasjonen: isoler PHP-applikasjoner som vender mot internett, fra det offentlige nettverket når umiddelbar patching ikke er mulig.

Midlertidige avbøttingstiltak: snevr inn vinduet, ikke lukk det

PHP-rådgivningen slår fast uten omsvøp at det ikke finnes fullgod avbøtting, og at oppdatering er det eneste trygge valget. Behold det følgende som dekning i dager, ikke uker, iverksatt på et nivå applikasjonen ikke kan overstyre, og med alle arbeidsprosesser startet på nytt etterpå.

Mot CVE-2026-109618 (angrepsveien via tom-for-minne)

• La PHP tømme maskinens minne i stedet for å treffe sin egen grense: memory_limit = -1, helst som php_admin_value memory_limit = -1, slik at applikasjonskoden ikke kan sette taket tilbake.
• Hold forespørselskroppene små ved tolken: rådgivningens veiledning er rundt 8 MB når det ikke lastes opp filer, og rundt 32 MB når det gjøres, med upload_max_filesize lavere enn post_max_size.
• Håndhev de kostbare grensene i proxyen, fordi skaden ligger i den dekodede forespørselen, ikke i overføringsstørrelsen: total dekodet kroppsstørrelse, antall inndatafelt, antall multipart-deler, antall headere, nøstingsdybde — og fang opp forespørsler som kommer uten en brukbar Content-Length.
• Begrens skadeomfanget med en minnegrense i container eller cgroup, dimensjonert slik at en drept arbeidsprosess blir en tilgjengelighetshendelse, ikke en hendelse for hele verten. Ikke bytt den ut med RLIMIT_AS eller RLIMIT_DATA: de utløser akkurat den allokasjonsfeilen som ligger i den sårbare koden.

Mot CVE-2026-109619 (angrepsveien via gjenværende tilstand)

• Deaktiver opplastingsfremdrift for økter med session.upload_progress.enabled = 0, satt i php.ini, FPM-poolen eller tjenerkonfigurasjonen — et sted som trer i kraft før forespørselen tolkes. Start deretter alle arbeidsprosesser på nytt, fordi FPM deler allerede initialisert modultilstand mellom forespørsler. ini_set() og .user.ini kommer for sent til å hjelpe.
• Sett fatal_error_backtraces = 0 på PHP 8.5, og start på nytt.
• Fjern innstillinger per forespørsel som er ugyldige eller utfaset og som derfor avgir diagnostikk under tidlig initialisering. Å dempe meldingen med error_reporting, display_errors eller @ fjerner ikke kodebanen.
• Let etter fatale feil og langvarige tidsavbrudd som er nåbare for angripere, i håndterere for opplasting og import, i callback-kode og i oppryddingsrutiner — de samme stedene der begge feilene bor.

En CDN eller WAF foran origin-tjeneren gjør fortsatt nytte: hastighetsbegrensning, blokkering av avvikende forespørselsformer og virtuell patching reduserer støy og bremser opportunistisk skanning. De er en fartshump for en målrettet angriper, ikke en kontroll du kan signere av som utbedring.

Hva du bør spørre webhotelleverandøren din om i dag

Kundestøtten svarer på dette spørsmålet med standardfrasen «vi er alltid patchet». Be i stedet om beviser du kan arkivere:

• Den innebygde PHP-versjonen som er tildelt vår konto, og om den er en distribusjonspakke eller et leverandørbygg.
• Datoen rettelsene for CVE-2026-109618 og CVE-2026-109619 nådde deres maskinpark, med den interne pakkeversjonsstrengen.
• Om rettelsen gjelder SAPI-en som betjener nettstedet vårt (FPM, LiteSpeed, mod_php), og eventuelle staging- eller sikkerhetskopinoder vi kan komme til å gjenopprette fra.
• Hvis plattformen ikke er patchet ennå: hvilken kompenserende kontroll som står, og til når.
• Deres faste praksis for EOL-grener — hva skjer med nettstedet mitt 1. januar 2027, når sikkerhetsstøtten for PHP 8.2 opphører.

En leverandør som svarer på alle fem spørsmålene i én e-post, er en leverandør verdt å beholde. En som kommer tilbake med markedsføringstekst, er en samtale om migrering; samme grundighet ligger til grunn som i arbeidet vårt med gap-analyse etter ISO 27001, der leveransen er beviser, ikke trygghetsforsikringer.

Bør du gå ut fra at du ble kompromittert?

Ikke automatisk — men undersøk i stedet for å anta, særlig hvis tjeneren sto eksponert mot det åpne internett i vinduet før patchen din.

• Se etter prosesser, lyttere og cron-oppføringer du ikke har opprettet selv, og utgående tilkoblinger fra brukeren som PHP-arbeidsprosessene kjører som.
• Sammenlign skrivbare applikasjonskataloger mot en autoritativ utrullingskilde: nye PHP-filer, endrede opplastingskataloger, midlertidige mapper som uventet er kjørbare.
• Søk i webloggene etter forespørselsstormer rundt offentliggjøringstimene, uvanlig store multipart-kropper, eller forespørsler som returnerte 500 med OOM-signaturer i PHP-feilloggen.
• Sjekk at den patchede binærfilen faktisk kjører — sammenligningen av omstartstidspunktet ovenfor gir svaret.
• Ser noe galt ut, behandler du det som en hendelse: sikre disken og loggene, bytt ut alle legitimasjoner applikasjonen kan lese, og gjenoppbygg fra et diskbilde med kjent god tilstand. Å installere PHP-pakken på nytt oppå en kompromittert vert er ikke utbedring.

Et praktisk eksempel fra vår egen infrastruktur

Vi drifter worldwidetradex.com på Ubuntu 24.04 LTS med nginx og PHP-FPM, og 22. oktober kjørte vi sjekkene ovenfor på oss selv. Resultatene viser godt hvorfor versjonsregnestykket betyr noe:

Lærdommen overføres til enhver stabel: sikkerhetsnivået ditt er pakkeversjonen pluss endringsloggen pluss omstarten, ikke markedsføringsversjonen i webhotellpanelet.

Gjør patching til rutine i stedet for heltedåd

PHP2Shell huskes ikke fordi det er eksotisk; det huskes fordi tolken som mesteparten av nettet kjører på, hadde en kritisk feil som kunne utnyttes før autentisering, og tusenvis av verter måtte reagere i løpet av få timer. Teamene som sov gjennom det, var ikke heldige — de hadde automasjon.

• Uovervåkede sikkerhetsoppgraderinger av tolken, med versjon og omstart logget automatisk.
• En oversikt som vet hvilken SAPI og hvilken PHP-gren hvert enkelt nettsted bruker, inkludert staging, sikkerhetskopier og den ene WordPress-installasjonen fra 2019.
• En innøvd gjenopprettingsvei, slik at «patch nå» aldri skal veies mot «vi kan ikke rulle tilbake».
• En plan for grenene: ingenting skal kjøre på en PHP-utgivelse der sikkerhetsstøtten opphører i løpet av de neste tolv månedene.
• Én navngitt ansvarlig per tjener og en skriftlig eskaleringsvei for de dagene en patch lander kl. 14:00 UTC på en onsdag.

Vil du heller kjøpe denne evnen enn å bemanne den selv, tar vi eierskap til PHP-plattformer i produksjon — patch-rytme, overvåking, sikkerhetskopier og dokumenterte gjenopprettinger — som en del av arbeidet vårt med administrert infrastruktur. Start med en kort beskrivelse og mengder: be om et tilbud.

Ofte stilte spørsmål

Kilder

• PHP — sikkerhetsrådgivningen «Critical remote code execution vulnerabilities, update now» og lanseringskunngjøringene 21. oktober 2026, inkludert veiledningen om avbøttingstiltak og støttetidslinjen på siden for støttede versjoner.
• GitHub-sikkerhetsrådgivningene for PHP-kodelageret: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) og GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Security Advisory 2026-018, «Critical Vulnerabilities in PHP», som navngir begge CVE-ene.
• Infosecurity Magazine — «Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches» (21. oktober 2026) og «PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure» (22. oktober 2026).

Vil du ha oppgraderingen håndtert for deg? For å diskutere patching, en gjennomgang av versjonene, migrering til en administrert og patchet PHP-plattform eller infrastrukturen rundt, kan du kontakte oss eller ringe +90 505 679 78 03.