PHP2Shell: Kritiske PHP-sårbarheter – slik patcher du nå

21. oktober 2026 | PHP | IT-sikkerhet

Den 21. oktober 2026 publiserte PHP-sikkerhetsteamet oppdateringer for alle PHP-versjoner som fortsatt støttes. De tetter to kritiske sårbarheter som er blitt kjent som PHP2Shell. BSI har gitt ut en advarsel om dette og krever at berørte systemer patches umiddelbart. Den som driver en webserver med PHP, bør handle i dag. Det gjelder også alle som «bare» driver en WordPress, Nextcloud eller Joomla, for disse applikasjonene kjører på PHP.

Dette innlegget oppsummerer hva som har skjedd, hvilke PHP-versjoner som er berørt, hvilken versjon du trenger nå og hvordan du på noen få minutter kontrollerer om serveren din er sikret.

Hva har skjedd? Tidsforløpet

PHP-sikkerhetsteamet har varslet publiseringen av rettelsene på forhånd, slik at leverandører av webhotell og administratorer hadde tid til å forberede seg. Selve publiseringen fant sted 21. oktober 2026. BSI ga ut sin advarsel (versjon 1.1) samme dag.

• 20. oktober 2026: Forhåndsvarsel fra PHP-sikkerhetsteamet om at sikkerhetsoppdateringer kommer dagen etter.
• 21. oktober 2026, 14:00 UTC (kl. 16:00 CEST): Patchene for PHP 8.5, 8.4, 8.3 og 8.2 publiseres.
• 21. oktober 2026: BSI advarer mot «kritiske sårbarheter som truer webapplikasjoner over hele verden» og anbefaler å patche umiddelbart. Ifølge BSI har store hostingleverandører til dels tatt servere offline som en forholdsregel.

De to PHP-sårbarhetene i oversikt

Det dreier seg om to separate feil i PHP-kjernen: CVE-2026-109618 og CVE-2026-109619. Begge kan ifølge PHP-sikkerhetsteamet føre til at en angriper kan kjøre programkode på serveren uten å logge inn (unauthenticated Remote Code Execution). Sårbarhetene er vurdert til CVSS v4.0: 9,2 (kritisk).

Etter BSIs vurdering fantes det på publiseringstidspunktet ingen bekreftede angrep, men det fantes ubekreftede indikasjoner på utnyttelsesforsøk. Ved kritiske sårbarheter i så utbredt programvare må man erfaringsmessig regne med at angripere analyserer rettelsene og forbereder automatiserte angrep. Tidsvinduet for å patche er derfor kort.

Hvem er berørt?

Berørt er i prinsippet hver server der PHP kjører, uavhengig av hvordan PHP er koblet til: PHP-FPM, mod_php i Apache, php-cgi, FrankenPHP eller LiteSpeed. Risikoen er ifølge PHP-sikkerhetsteamet høyest ved Apache med mod_php.

BSI nevner uttrykkelig applikasjoner som bygger på PHP og derfor kan være berørt:

• Innholdsstyringssystemer: WordPress, Drupal, TYPO3, Joomla
• Nettbutikksystemer: Magento
• Sky- og fillagring: Nextcloud
• Brannmurgrensesnitt: pfSense, OPNsense

Selve applikasjonen trenger for dette ikke å være feilaktig. Sårbarheten ligger i PHP, derfor hjelper en oppdatering av WordPress, Nextcloud & Co. alene ikke. PHP-versjonen på serveren må oppdateres. Ved brannmurer som pfSense og OPNsense kommer den rettede PHP-versjonen via produsentens respektive firmwareoppdatering.

Disse PHP-versjonene er sikre

Sårbarhetene er rettet i de følgende versjonene. Alt under regnes som sårbart.

Slik kontrollerer og oppdaterer du serveren din

1. Fastslå installert PHP-versjon

På serverens kommandolinje viser php -v versjonen av kommandolinje-PHP. Webserveren kan bruke en annen PHP-versjon. Kontroller derfor også versjonen av PHP-FPM henholdsvis Apache-modulen, for eksempel med php-fpm8.3 -v eller via en side som viser phpinfo() (fjern denne umiddelbart etterpå).

2. Installere oppdateringen via pakkebehandlingen

Ved Debian, Ubuntu, RHEL og beslektede kommer den rettede versjonen via den vanlige pakkebehandlingen, for eksempel apt update && apt upgrade eller dnf upgrade. Ved tredjepartskilder som Sury-PPA eller Remi-repositoriet dukker de nye pakkene som regel opp raskt.

3. Starte PHP-tjenesten på nytt

En pakkeoppdatering alene er ikke nok: kjørende PHP-prosesser beholder den gamle koden i minnet. Start PHP-FPM (systemctl restart php8.3-fpm) henholdsvis Apache (systemctl restart apache2) på nytt, og kontroller deretter om prosessene ble startet etter oppdateringen.

4. Hostede nettsteder

Ved delt webhotell oppdaterer som regel leverandøren. I kundemenyen kan PHP-versjonen som regel stilles inn per nettsted. Velg der en av de sikre versjonene nevnt ovenfor, eller spør leverandøren om status for patchene. Ifølge BSI har enkelte leverandører tatt servere av nettet som en forholdsregel. Hvis siden din en kort stund ikke er tilgjengelig, kan det være årsaken.

PHP 8.1 og eldre: ingen offisiell oppdatering

For PHP 8.1 og eldre finnes det ikke lenger offisielle sikkerhetsoppdateringer. Operatører av slike systemer har to muligheter:

• Bytte til en støttet versjon (anbefalt). Jo eldre versjonen er, desto større er tilpasningsarbeidet for applikasjon og utvidelser, derfor bør et bytte testes på forhånd.
• Portere rettelser tilbake. PHP-sikkerhetsteamet har gjort rettelsene tilgjengelige i utviklingsgrener på GitHub. Den som kompilerer PHP selv, kan overføre disse endringene til eldre versjoner. Det er en midlertidig løsning og krever fagkunnskap.

Også PHP 8.2 støttes bare frem til 31. desember 2026. Planlegg derfor overgangen til PHP 8.4 eller 8.5 nå, og utsett den ikke til årsskiftet.

Midlertidige tiltak og spørsmålet «ta serveren offline?»

PHP-sikkerhetsteamet har sammen med varselet også beskrevet midlertidige beskyttelsestiltak. Disse reduserer risikoen, men tetter ikke sårbarhetene fullstendig. De erstatter ikke oppdateringen og er bare ment for å bygge bro over tiden frem til oppdateringen.

Om en server bør tas av nettet frem til oppdateringen, avhenger av dens betydning og tilgjengelighet. BSI uttaler at store leverandører har gått dette trinnet. Som tommelfingerregel gjelder:

• Offentlig tilgjengelig server, oppdatering mulig nå: patch umiddelbart, ingen avstenging nødvendig.
• Offentlig tilgjengelig server, oppdatering ikke mulig på kort sikt: begrens tilgangen (for eksempel via brannmur bare for kjente adresser) eller slå tjenesten midlertidig av, særlig ved mod_php.
• Server som bare er tilgjengelig internt: patch snart, hastegraden er lavere.

Ofte stilte spørsmål

Må jeg oppdatere WordPress, Joomla eller Nextcloud?

Ikke på grunn av dette sikkerhetshullet. Det ligger i PHP, ikke i applikasjonen. Oppdater PHP-versjonen på serveren. En oppdatering av applikasjonen er uansett fornuftig, uavhengig av dette.

Hvordan ser jeg om noen allerede har utnyttet sikkerhetshullet?

Det er vanskelig å gi et sikkert svar. Tegn å se etter er ukjente PHP-filer i webkatalogen, uvanlige prosesser under webserverens bruker, nye brukerkontoer eller cron-jobber og uvanlig utgående datatrafikk. Ved en konkret mistanke bør systemet undersøkes rettsteknisk og, om nødvendig, settes opp på nytt.

Er en Web Application Firewall nok?

En brannmur kan fange opp kjente angrepsmønstre, men er ingen erstatning for oppdateringen. Mer om samspillet mellom flere beskyttelseslag kan du lese i innlegget vårt Sikre Odoo 19: brannmur, 2FA & Web RBL. Prinsippene gjelder for alle webapplikasjoner.

Er Odoo berørt?

Nei. Odoo er skrevet i Python og kjører ikke på PHP. Det er bare PHP-applikasjoner som kjører på samme server som kan være berørt.

Hvor finner jeg den offisielle informasjonen?

Kunngjøringen fra PHPs sikkerhetsteam finner du i nyhetsarkivet på php.net (oppføring fra 20. oktober 2026), og versjonene under php.net/downloads. Advarselen fra BSI har nummer 2026-297981-1032 og er publisert på bsi.bund.de .

Støtte fra Biricon IT Services

Hvis du er usikker på hvilken PHP-versjon som kjører på serveren din, eller trenger hjelp med oppdateringen, bistår vi deg gjerne: med kartlegging av alle PHP-systemer, med installasjon av oppdateringene, med overgang til en støttet PHP-versjon og med kontroll for kompromittering. Som IT-tjenesteleverandør drifter vi servere, brannmurer og webapplikasjoner for små og mellomstore bedrifter.

Ta kontakt nå

Status: 21. oktober 2026. Situasjonen kan endre seg raskt; det er publikasjonene fra PHPs sikkerhetsteam og BSI som gjelder.