21. oktober 2026 ga PHP-teamet ut rettelser for to kritiske sårbarheter, CVE-2026-109618 og CVE-2026-109619, som til sammen kalles PHP2Shell. En angriper trenger verken innlogging eller passord. Én spesiallaget forespørsel til nettstedet ditt kan være nok til at angriperen kjører egen kode på serveren og tar over nettstedet. Få timer etter utgivelsen meldte sikkerhetsselskapet watchTowr om forsøk på å utnytte begge feilene, og Cloudflare sa at de så de første angrepene.
Hvis nettstedet, nettbutikken eller adminpanelet ditt kjører på PHP, trenger serveren den oppdaterte PHP-versjonen i dag.
Hva skjedde
PHP-teamet varslet en kritisk utgivelse 20. oktober og publiserte de rettede versjonene 8.5.12, 8.4.27, 8.3.36 og 8.2.35 21. oktober kl. 14.00 UTC. Teamet gir dem 9,2 av 10 på CVSS v4.0, som er kritisk nivå. Den ene gjelder hvordan PHP håndterer at minnet går tomt. Den andre lar data fra én forespørsel lekke inn i neste forespørsel i samme serverprosess.
De rammer alle måter å kjøre PHP på en webserver: PHP-FPM, Apache med mod_php, php-cgi, LiteSpeed og FrankenPHP. PHP-teamet vurderer Apache med mod_php som høyest risiko: sikkerhetsvarselet deres beskriver en demonstrert utnyttelse der én forespørsel uten innlogging utløser angrepet før noe av nettstedets kode kjører.
Per kvelden 21. oktober hadde ingen sikkerhetsselskaper meldt om et bekreftet innbrudd. Kode som skal utnytte feilene, sirkulerer allerede på nettet, og masseangrep kan starte når som helst.
Gjelder dette deg?
Sjekk disse punktene. Ett “ja” er nok.
- Nettstedet ditt kjører på WordPress, WooCommerce, Laravel, OpenCart, Bitrix, Drupal, Magento eller et annet PHP-system.
- Bedriften din har et adminpanel, en kundeportal eller et API skrevet i PHP. Backend for en mobilapp teller også.
- Du har ikke fått bekreftet fra hostingleverandøren eller utvikleren at PHP på serveren din allerede er oppdatert.
- Serveren din kjører et kontrollpanel for hosting, for eksempel aaPanel. Noen paneler hadde ikke oppdatert PHP på utgivelsesdagen.
- PHP-versjonen din er 8.1 eller eldre.
Hvis du ikke vet svarene, er det grunn nok til å spørre i dag.
Hva en angriper kan gjøre med nettstedet ditt
Kodekjøring på serveren gir angriperen samme tilgang som nettstedet ditt har. I praksis betyr det:
- full kontroll over nettstedet: endre sider, legge til administratorkontoer, sende besøkende videre til andre steder;
- tilgang til databasen: kundenes navn, e-postadresser, adresser og bestillinger;
- skadevare eller spamsider plantet på nettstedet;
- en advarsel fra Google i søkeresultatene og i nettleseren, som stopper trafikk og salg til du har ryddet opp.
Å rydde opp etter et kompromittert nettsted kan ta dager, og noen ganger må alt bygges opp på nytt. En oppdatering tar timer.
Dette gjør du i dag
1. Finn PHP-versjonen din. Kontrollpanelet hos hostingleverandøren viser den, vanligvis under “PHP-versjon” eller “PHP-innstillinger”. I WordPress åpner du Verktøy → Nettstedshelse → Info → Server. På Ubuntu kan versjonsnummeret fortsatt vise et gammelt tall, for eksempel 8.3.6, etter en sikkerhetsoppdatering, fordi Ubuntu retter pakken og beholder nummeret. Da må hostingleverandøren eller utvikleren sjekke pakkeversjonen.
2. Be hostingleverandøren eller utvikleren om å oppdatere PHP. Du kan sende denne meldingen som den er:
Hei. 21. oktober 2026 ga PHP ut rettelser for de kritiske sårbarhetene CVE-2026-109618 og CVE-2026-109619 (PHP2Shell). Kan dere bekrefte at PHP på serveren vår er oppdatert til en rettet versjon (8.5.12, 8.4.27, 8.3.36, 8.2.35 eller en patchet pakke fra distribusjonen), og at PHP-FPM eller Apache er startet på nytt? Hvis vi kjører PHP 8.1 eller eldre, ber vi dere fortelle hvordan dere planlegger å få inn rettelsen. Vi ber dere også gå gjennom serverloggene for tegn på utnyttelse siden 21. oktober.
3. Kjører du PHP 8.1 eller eldre, bør du planlegge overgang til en støttet versjon. For 7.4, 8.0 og 8.1 publiserte PHP-teamet bare rettelser i kildekoden. Noen må bygge PHP fra kildekode med disse rettelsene, eller flytte nettstedet til en nyere versjon.
Å slå av session.upload_progress.enabled i PHP-innstillingene stenger en del av angrepsveien. PHP-teamet presiserer at dette ikke gjør serveren trygg. Se på det som en midlertidig løsning frem til oppdateringen.
Din versjon og hva du gjør
| Din PHP-versjon | Hva du gjør |
|---|---|
| 8.5 | Oppdater til 8.5.12 |
| 8.4 | Oppdater til 8.4.27 |
| 8.3 | Oppdater til 8.3.36 |
| 8.2 | Oppdater til 8.2.35. Støtten for 8.2 slutter 31. desember 2026, så planlegg neste oppgradering |
| 8.1, 8.0, 7.4 | Ingen offisiell oppdatering. Bygg PHP med rettelsene fra kildekoden eller gå over til en støttet versjon |
| 7.3 og eldre | Ingen rettelse fra PHP-teamet. Gå over til en støttet versjon |
Ubuntu har allerede gitt ut rettede pakker. På andre Linux-distribusjoner bør du sjekke sikkerhetsvarselet fra leverandøren.
Slik håndterte vi det for kundene våre
PHP-teamet publiserte rettelsene kl. 14.00 UTC. Ingeniørene våre startet arbeidet omtrent en time senere. To timer etter det, rundt kl. 17.00 UTC, hadde vi tettet hullet på alle serverne vi drifter: 88 prosjekter under vår support.
På hver server slo vi først av den sårbare mekanismen og installerte deretter rettet PHP. Hostingpaneler som aaPanel hadde ikke oppdatert PHP på utgivelsesdagen, så vi bygde PHP fra kildekode med rettelsene. Det samme gjorde vi for prosjekter på PHP 7.4, 8.0 og 8.1, som PHP-teamet ikke lenger oppdaterer. Etter oppdateringen gikk vi gjennom serverloggene etter tegn på at noen hadde utnyttet sårbarheten. Vi fant ingen.
Den automatiske overvåkingen vår går døgnet rundt, og ingeniørene våre reagerer når den melder en hendelse.
Slik gjorde vi det, steg for steg: slik patchet vi 88 PHP-prosjekter på tre timer.
Usikker på om nettstedet ditt er beskyttet?
Vi sjekker PHP-versjonen din og oppdaterer den innen én arbeidsdag. Hvis nettstedet kjører på PHP 8.1 eller eldre, forteller vi deg hvilken vei som er raskest og rimeligst i ditt tilfelle: en egen PHP-bygg med rettelsene eller en oppgradering.
Vil du ha løpende oppfølging etterpå, kan du se på support for nettsteder og serverdrift. For WordPress- og WooCommerce-butikker har vi en egen side. Mistenker du at noen kom seg inn før oppdateringen, eller vil du vite hva annet som står åpent, gir en penetrasjonstest svaret.
FAQ
Må jeg oppdatere hvis nettstedet mitt kjører på WordPress?
Ja. WordPress kjører på PHP, og sårbarheten ligger i selve PHP. Å oppdatere WordPress og utvidelsene løser det ikke. Serveren din trenger den rettede PHP-versjonen.
Oppdaterer hostingleverandøren PHP automatisk?
Noen gjør det, noen venter, og på mange VPS-er og dedikerte servere er det ingen som oppdaterer PHP med mindre du ber om det. Be leverandøren om skriftlig bekreftelse med nøyaktig versjon.
Slutter nettstedet å fungere etter oppdateringen?
En oppdatering innenfor samme gren, for eksempel fra 8.3.x til 8.3.36, inneholder bare sikkerhets- og feilrettinger og påvirker sjelden et nettsted. Å gå fra 7.4 eller 8.1 til en nyere gren kan ødelegge gamle utvidelser eller gammel kode, så den overgangen må testes først.
Er det nok å slå av session.upload_progress?
Nei. Det stenger en del av én angrepsvei. PHP-teamet sier at bare oppdateringen løser problemet.
Kilder
- Kunngjøring 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
- Rapporter om angrepsforsøk og utnyttelseskode: https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote