Rettelsen for PHP2Shell er klar, men for de fleste nettstedene som trenger den, finnes det ingen knapp å trykke på. Sårbarhetene ligger i selve PHP, motoren som driver alle WordPress-, Joomla- og Drupal-sider, under CMS-et, utvidelsene og innloggingssiden. Å oppdatere WordPress gjør ingenting med dem. Den oppdaterte PHP-tolken må komme fra den som drifter serveren: webhotellet, Linux-distribusjonens pakke eller containeravbildningen. Inntil det skjer, må nettstedet vente, uansett hva eieren gjør.

Det er denne delen av historien overskriftene om å «installere oppdateringen nå» hopper over. PHP-teamet har gjort sin jobb. Om arbeidet deres når fram til en bestemt server, avhenger av en leveringskjede som beveger seg like raskt som det tregeste leddet, og den første dagen viste hvor langt fra hverandre leddene står. En nettstedseier som ikke vet hvor PHP-en deres kommer fra, kan heller ikke vite hvor utsatt nettstedet fortsatt er.

Derfor løser ikke en WordPress-oppdatering problemet

Fordi feilene ligger i PHP-tolken, omfatter PHPs sikkerhetsvarsel alle installasjoner som håndterer webforespørsler, fra PHP-FPM og Apaches mod_php til php-cgi, FrankenPHP og LiteSpeed. The Hacker News påpeker at selv en enkel «Hello World»-side på en sårbar versjon kan angripes. Verst er det med mod_php, der én enkelt forespørsel fra noen uten brukerkonto kan utløse angrepet før applikasjonskoden kjører. Dermed får verken sikkerhetsutvidelser eller innloggingssiden noen mulighet til å oppdage det.

Wordfence, sikkerhetsleverandøren for WordPress, sa til nettstedseiere, ifølge The Verge, at rettelsen ikke kan komme gjennom automatiske oppdateringer, og at de må finne ut hvem som har ansvaret for PHP-installasjonen deres. Laravel Forge ga sine egne kunder samme beskjed om serverne deres: De automatiske sikkerhetsoppdateringene deres oppdaterer ikke PHP, og Ubuntus automatiske oppgraderinger henter bare pakker fra Ubuntus eget pakkearkiv, ikke fra tredjepartspakkene Forge installerer PHP fra.

Disse pakkekildene ble ikke oppdatert samtidig. På lanseringsdagen meldte nettstedadministrasjonstjenesten mySites.guru at cPanels EasyApache 4 hadde ferdige, rettede versjoner få minutter etter sikkerhetsvarslene, mens Ondřej Surýs PPA, Ubuntus pakkekilde som Laravel Forge selv er avhengig av, og Remis pakkearkiv ennå ikke hadde noen. InMotion Hosting sa at de delte serverne og WordPress-serverne deres ventet på CloudLinux-versjonene. Blant nettstedene mySites.guru overvåker, rapporterte 0,08 % en rettet PHP-versjon klokken 13.52 UTC.

Versjonsnummeret kan villede deg

Det er ikke så enkelt å kontrollere som å lese av et versjonsnummer. Ubuntu, Debian og Red Hat tilbakeporterer sikkerhetsrettinger uten å endre oppstrømsversjonen, så en rettet Ubuntu 24.04-server rapporterer fortsatt en 8.3.6-pakke. The Hacker News viser, med henvisning til Debian, til at man bør se etter CVE-en i pakkens endringslogg i stedet for å stole på versjonsnummeret. mySites.guru peker på en annen fallgruve: PHP-binærfilen som svarer på php -v i kommandolinjen, er ofte ikke den som serverer nettsidene. Derfor bør man kontrollere versjonen nettstedet selv rapporterer.

Deretter må rettelsen tas i bruk. Både PHPs sikkerhetsvarsel og Forge understreker at Apache, PHP-FPM og alle prosesser som kjører over lang tid, må startes på nytt. Køarbeidere og lignende bakgrunnsprosesser fortsetter å bruke den gamle tolken til de startes på nytt, selv om filene på disk er oppdatert.

Hvem får ingen offisiell rettelse?

De rettede versjonene er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. De tetter CVE-2026-109618 og CVE-2026-109619, som begge har fått 9,2 på CVSS v4.0-skalaen. PHP 8.1 og eldre får ingenting fra PHP-prosjektet, bortsett fra minimale rettelser tilbakeportert til kildekoden for 7.4, 8.0 og 8.1, beregnet på dem som kompilerer PHP selv. Noen leverandører tetter gapet: InMotion sier at cPanel har tilbakeportert rettelser til pakkene deres for versjonene 7.4 til 8.1, og at CloudLinux retter alle versjonene selskapet distribuerer. CentOS 7 får ingen rettelse i det hele tatt.

Den gruppen er ikke liten. Dagen før lanseringen kjørte 22,7 % av de aktive Joomla- og WordPress-nettstedene mySites.guru overvåker, PHP 8.1 eller eldre, og 16,6 % brukte fortsatt PHP 7 eller eldre. Selskapet mener noe av dette skyldes WordPress selv, som anbefaler PHP 8.3, men fremdeles oppgir den for lengst utgåtte versjonen 7.4 som kompatibel. PHP 8.2 fikk denne rettelsen, men sikkerhetsstøtten for versjonen opphører 31. desember 2026.

Dette blokkerer den midlertidige innstillingen

Omveien som ble delt før lanseringen, å sette session.upload_progress.enabled=0, fungerer, men løser bare deler av problemet. PHP sier at innstillingen blokkerer de bekreftede angrepsveiene via økter for CVE-2026-109619, men ikke andre varianter. Den må settes i php.ini eller i server- eller poolkonfigurasjonen, og alle arbeidere må deretter startes på nytt. I PHP 8.5 stenger fatal_error_backtraces=0 enda en bekreftet angrepsvei. Ingen av innstillingene berører CVE-2026-109618. For den anbefaler PHP en memory_limit=-1 som ikke kan overstyres, en lav post_max_size og grenser for forespørselsstørrelse på webserveren eller proxyen. PHP sier selv at det ikke finnes noen fullstendige skadebegrensende tiltak. InMotion påpeker at WordPress, Joomla, Drupal, Magento og PrestaShop ikke bruker funksjonen for opplastingsframdrift, så det får ingen konsekvenser for dem å slå den av.

Cloudflare aktiverte brannmurregler for alle abonnementer. Selskapets teknologidirektør, Dane Knecht, kalte dem et midlertidig tiltak. Som mySites.guru påpeker, hjelper reglene bare dersom serveren bak Cloudflare avviser trafikk som går utenom tjenesten, rett til IP-adressen.

Angrep så langt

watchTowr sier at honningfellene deres registrerte forsøk på å utnytte begge sårbarhetene på lanseringsdagen, og Cloudflare observerte at angripere endret angrepsdataene sine for å komme seg forbi reglene. Ingen kilder har bekreftet et vellykket innbrudd på en bestemt server. Noen aktører tok ingen sjanser: The Hacker News melder at BambooHR tok tjenesten sin av nettet, og at nederlandske offentlige tjenester, blant dem DigiD, ble utilgjengelige som et føre-var-tiltak. EUs CERT og Storbritannias National Cyber Security Centre ba organisasjoner som ikke kan installere rettelsen, om å isolere utsatte apper eller ta dem av nettet.

Sårbarhetene ble oppdaget av Wiz Research, Calif og OpenAIs Codex Security-team. Ifølge PHP Foundation dukket det opp tegn på minnesårbarheten i en sikkerhetsrevisjon i 2024, men arbeidet med en rettelse gikk i stå i flere måneder, noe stiftelsen kalte «en strukturell svikt». Forskerne sier at AI-modeller bidro til å gjøre de ti år gamle feilene om til fungerende angrep på omtrent en uke.

PHP trengte en sikkerhetsrevisjon, flere måneder med fastlåst arbeid og en lekkasje før denne rettelsen ble sendt ut. For et nettsted på delt webhotell er siste steg å sende en henvendelse til kundestøtten.

Tagger: Cloudflare, PHP, PHP2Shell, sårbarheter, WordPress