Kritiske PHP-sårbarheter (PHP2Shell): hva som skjedde og hva du bør gjøre

21. oktober 2026 slipper PHP-teamet en nødsikkerhetsoppdatering. Den fikser to kritiske sårbarheter i selve PHP-tolkeren som lar en angriper kjøre kode på en server eksternt. Sårbarhetene har allerede fått det uoffisielle navnet PHP2Shell.

Nettstedene deres fortsetter å kjøre. Nedenfor finner du hva som skjedde, hvem som er berørt, hva vi allerede har gjort og hva du må gjøre.

Hva skjedde

PHP-sikkerhetsteamet har annonsert rettelser for to kritiske sårbarheter. Begge er vurdert til 9.2 av 10 på CVSS v4.0-skalaen. Forskere sporer dem som CVE-2026-109618 og CVE-2026-109619.

Rettelsene slippes 21. oktober klokken 14:00 UTC (17:00 Moskva-tid) . Utgivelsen var opprinnelig planlagt en dag senere, men detaljer om sårbarhetene lekket tidligere enn planlagt, og PHP fremskyndet utgivelsen. Ifølge Patchstack rapporterte hostingleverandører allerede om utnyttelsesforsøk morgenen 21. oktober.

Hvem er berørt

Sårbarheten ligger ikke i et CMS eller en plugin, men i selve PHP. Alle nettsteder som kjører en sårbar PHP-versjon er i faresonen: WordPress, WooCommerce, Joomla, Drupal, 1C-Bitrix, Magento, Laravel og spesialbygde prosjekter. Oppdatering av CMS og pluginer beskytter ikke mot dette problemet.

Ifølge foreløpige rapporter er alle versjoner fra PHP 5.4 og utover berørt. Offisielle rettelser vil kun bli utgitt for støttede grener:

PHP vil publisere den nøyaktige listen over berørte og reparerte versjoner sammen med utgivelsen. Vi vil oppdatere denne artikkelen så snart den er tilgjengelig.

Hva som er kjent og hva som ikke er offentliggjort ennå

PHP har ikke publisert tekniske detaljer ennå. Alt som er kjent så langt kommer fra lekkasjen og analyser utført av uavhengige forskere:

• Sårbarhetene tillater vilkårlig kodekjøring på serveren uten autentisering – en spesiallaget forespørsel til nettstedet er nok;
• minst én av dem er relatert til sporingsmekanismen for filopplasting (session.upload_progress), som er aktivert i PHP som standard;
• ifølge forskere er den andre i filopplastingshåndtereren og er ikke avhengig av denne innstillingen.

Ikke offisielt bekreftet før utgivelsen:

• en nøyaktig beskrivelse av sårbarhetene og angrepsforholdene;
• listen over berørte og reparerte versjoner;
• indikatorer på kompromiss (IoC-er).

Sikkerhetseksperter forventer masseangrep innen få minutter etter at rettelsene er publisert: ved å sammenligne gammel og ny kode vil angriperne raskt finne ut hvordan sårbarheten fungerer. Derfor må ikke oppdateringen utsettes.

Det vi gjør

Uten å vente på den offisielle utgivelsen har vi iverksatt tiltak på tvers av hele infrastrukturen vår:

1. Lagt til regler for forespørselsfiltrering som blokkerer det kjente angrepsscenariet. Dette er et begrenset tiltak: noen angrep kan omgå filteret, så det kjøper bare tid frem til oppdateringen.
2. Økt overvåkingVi sporer mistenkelig PHP-prosessaktivitet på serverne våre og PHP-krasj som kan indikere angrepsforsøk.
3. Har forberedt PHP-oppdateringen. Så snart utgivelsen er ute, vil vi installere de reparerte versjonene for gren 8.2–8.5 på alle delte hostingservere. Vi vil varsle deg separat når arbeidet er fullført.

Midlertidige tiltak reduserer risikoen, men eliminerer ikke sårbarheten fullstendig. Den eneste pålitelige beskyttelsen er å oppdatere PHP.

Det du trenger å gjøre

Hvis du bruker delt hosting

Vi håndterer mesteparten av arbeidet selv. Alt du trenger å gjøre er:

1. Sjekk PHP-versjonen din i PHP-innstillinger-delen av kontrollpanelet for hvert nettsted.
2. Hvis versjonen er 8.2 eller nyere, ingen handling er nødvendig: vi installerer den reparerte versjonen automatisk.
3. Hvis versjonen er 8.1 eller eldre, bytt nettsiden til PHP 8.2 eller nyere (se neste avsnitt).
4. Ikke aktiver på nytt session.upload_progress i dine egne PHP-innstillinger, selv om instruksjonene til en plugin antyder det.

Hvis du har en VPS eller dedikert server

På VPS og dedikerte servere administrerer du PHP selv, og vi kan ikke oppdatere det for deg. Gjør følgende så snart som mulig:

1. Finn alle installerte PHP-versjoner på serveren. Husk at kontrollpaneler (ISPmanager, cPanel, Plesk, FastPanel og andre) ofte har flere versjoner samtidig.
2. Deaktiver sporing av opplastingsfremdrift til oppdateringen er ute. For PHP-FPM, legg til disse linjene i konfigurasjonen til hver pool, for eksempel /etc/php/8.3/fpm/pool.d/www.conf: php_admin_flag[session.upload_progress.enabled] = off php_admin_flag[session.use_strict_mode] = on Hvis PHP kjører som en Apache-modul (mod_php), angi disse parameterne i php.ini og start Apache på nytt. Denne innstillingen kan ikke endres fra kode med ini_set().
3. Start PHP-FPM på nytt og sjekk resultatet: opprett en fil som inneholder <?php phpinfo(); i nettstedroten, åpne den i en nettleser og sørg for at session.upload_progress.enabled er Av. Slett filen umiddelbart etterpå. Sjekker med php -i i konsollen fungerer ikke – den viser kommandolinjeinnstillingene, ikke webserverens.
4. Oppdater PHP så snart de fiksede pakkene vises i distribusjonens eller kontrollpanelets repository. Start deretter PHP-FPM eller Apache på nytt – uten omstart fortsetter den gamle versjonen å kjøre.

Ifølge forskere, invalidisering session.upload_progress lukker bare én av de to sårbarhetene. Det er et midlertidig tiltak, ikke en erstatning for oppdateringen.

Hvis nettstedet ditt kjører på PHP 8.1 eller eldre

PHP 8.1 og eldre grener er utgått og vil ikke få en offisiell løsning. Disse nettstedene vil forbli sårbare inntil de flyttes til en støttet versjon.

1. Planlegg overgangen til PHP 8.2 eller nyere. Vi anbefaler PHP 8.4. Merk at 8.2-grenen kun mottar sikkerhetsrettinger frem til 31. desember 2026.
2. Test kompatibiliteten på en kopi av nettstedet ditt. Å flytte mellom grener er en migrering, ikke en enkel oppdatering: eldre versjoner av CMS, temaer og plugins fungerer kanskje ikke på nyere PHP. Oppdater CMS og utvidelser først, og bytt deretter PHP-versjon.
3. Hvis du ikke kan migrere raskt, fjern nettstedet fra offentlig tilgang inntil migreringen er fullført: begrens tilgang via IP-adresse, med et passord eller via et VPN.

Hvis det er vanskelig å vurdere kompatibilitet selv, kan du kontakte supportteamet vårt – vi hjelper deg med migreringen.

Slik sjekker du om nettstedet ditt har blitt kompromittert

Angrepene startet før feilrettingen ble utgitt, så etter oppdatering av PHP er det verdt å sørge for at nettstedet ditt ikke ble kompromittert tidligere. Vær spesielt oppmerksom på perioden siden 20. oktober.

1. Sjekk nettsidens filer for ukjente PHP-filer, spesielt i opplastings-, mellomlagrings- og midlertidige mapper. Se nøye på filer som er endret etter 20. oktober.
2. Sjekk cron-jobber for ukjente oppføringer.
3. Sjekk administratorkontoer i CMS-et ditt, og på en VPS, systembrukere og nøkler inn ~/.ssh/authorized_keys.
4. Gjennomgå webserverlogger for mistenkelige POST-forespørsler med filopplastinger, spesielt til URL-er som ikke skal godta opplastinger.
5. På en VPS, sjekk prosessene: PHP-FPM- eller Apache-prosesser skal ikke startes sh, bash, curl, wget, nc, python or perl.
6. Kjør en malware-skanning av nettstedet ditt ved hjelp av kontrollpanelet eller en dedikert skanner.

Hvis du finner noe mistenkelig, ikke slett filer med en gang: ta vare på kopier og logger, endre CMS-, database- og FTP/SSH-passordene dine, og kontakt oss.

Trenger hjelp?

Er du usikker på hvilken PHP-versjon nettstedet ditt bruker, trenger du hjelp med å flytte til en nyere gren, eller har du funnet noe mistenkelig på serveren din? Kontakt supportteamet vårt – så ordner vi det sammen.

Vi oppdaterer denne artikkelen når PHP publiserer de offisielle detaljene og de fiksede versjonsnumrene, og vi varsler deg separat når oppdateringene er installert på serverne våre.