aibi.dk » Nyheder & tendenser » Seneste AI-nyheder » PHP2Shell rammer PHP: Det skal du spørge din hosting om

PHP2Shell rammer PHP: Det skal du spørge din hosting om

AIBI

23. oktober 2026

4 min. læsning

To kritiske fejl i PHP kan føre til fjernkørsel af kode uden login. Se, hvem der skal reagere, hvilke versioner der er rettet, og hvad du konkret skal bede hosting eller support om at bekræfte.

Indholdsfortegnelse Vis

Kort svar: Driver dit website eller din tjeneste PHP, skal du bede din hostingudbyder eller driftsansvarlige om at bekræfte, at den kørende PHP-installation er rettet mod CVE-2026-109618 og CVE-2026-109619. En versionsstreng alene er ikke altid nok, fordi Linux-distributioner og langtidsunderstøttede leverandører kan have lagt rettelsen ind i deres egne pakker.

PHP-projektet offentliggjorde 21. oktober 2026 sikkerhedsopdateringer til to kritiske fejl, der kan føre til fjernkørsel af kode uden login. Det betyder i værste fald, at en angriber kan få kode til at køre på en berørt server. Der er ikke tale om en fejl i WordPress, Drupal eller Joomla, men i selve PHP-motoren under dem.

I et LinkedIn-opslag 23. oktober oplyser Emil Hørning fra Defend Denmark, at han har fundet 21.539 .dk-sider med PHP-versionsoplysninger, som han vurderer peger på sårbarhed over for PHP2Shell. Han beskriver en headerbaseret opgørelse uden subdomæner og uden en komplet offentlig liste over .dk-domæner. Det er hans estimat, ikke en måling foretaget af AIBI, dokumentation for kompromittering eller en uafhængig bekræftelse af, at hver side kan udnyttes. Headers og versionsnumre kan desuden være ufuldstændige, og en leverandør kan have backportet en rettelse uden at ændre den viste version. Bed derfor hostingudbyderen om at bekræfte den faktiske patchstatus for den kørende PHP-build.

Hvad var AI’s rolle i fundet?

AI fandt ikke og rettede ikke PHP2Shell alene. OpenAI oplyser, at sikkerhedsforskerne hos Calif identificerede en kritisk fejl med GPT-5.6 Sol som del af initiativet Patch the Planet. Wiz oplyser, at deres forskere uafhængigt fandt og indberettede begge sårbarheder, og at de brugte Wiz Atlas, Gemini 4 Argon og GPT-5.6 Sol i forskningen. Wiz fremhæver især Gemini 4 Argons bidrag til fund, analyse, detektion og validering af rettelsen.

Menneskelige forskere stod for undersøgelsen og den ansvarlige indberetning. PHP’s vedligeholdere stod for rettelserne og udgivelserne, mens flere sikkerheds- og infrastrukturvirksomheder bidrog til test, beskyttelse og koordination før offentliggørelsen. Den præcise lære er derfor, at avancerede modeller kunne hjælpe forskere med en vanskelig sikkerhedsopgave, ikke at en model autonomt sikrede internettet.

Hvem skal reagere?

PHP’s sikkerhedsteam skriver, at alle PHP-installationer, som modtager webanmodninger, er omfattet af rådet om at opdatere. Det gælder blandt andet PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Risikoen vurderes som højest for mod_php, hvor en angrebsvej er demonstreret, før websitets egen kode begynder at køre.

Du skal derfor reagere, selv om dit CMS, tema og dine plugins allerede er opdateret. De opdateringer erstatter ikke en rettelse af PHP. På delt hosting er det normalt hostingudbyderen, der opdaterer PHP-motoren. På en selvadministreret server ligger opgaven hos den, der driver operativsystemet og PHP-tjenesten.

CMS og plugins ligger over PHP på domænet. Terminalens PHP kan være en anden installation. — Forenklet oversigt: Rettelsen skal nå den PHP-installation, der håndterer hjemmesidens webtrafik.

Hvilke versioner indeholder rettelserne?

PHP-gren	Rettet upstream-version
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

PHP-projektets rettede versioner for de to PHP2Shell-CVE’er.

PHP 8.1 og ældre får ikke længere almindelige opdateringer fra PHP-projektet. Projektet har dog stillet minimale kilde-backports til rådighed for 7.4, 8.0 og 8.1, og nogle distributioner og LTS-leverandører leverer egne rettede pakker. Derfor kan en leverandørpakke være beskyttet uden at vise et af versionsnumrene i tabellen. Omvendt bør et gammelt versionsnummer uden dokumentation ikke antages at være sikkert.

Bed om navnet på den installerede pakke eller build, leverandørens sikkerhedsmeddelelse og en udtrykkelig bekræftelse på, at begge CVE’er er rettet i den version, som faktisk kører. Hvis udbyderen kun svarer med “seneste PHP”, mangler du stadig den afgørende kobling til CVE-2026-109618 og CVE-2026-109619.

Officiel PHP-release eller dokumenteret leverandørrettelse skal begge bekræftes i den aktive web-PHP. Manglende dokumentation skal afklares med hosten.

Sådan får du et brugbart svar fra hosting eller support

Find ejeren af PHP-driften. Er det din hostingudbyder, en serverleverandør eller din egen driftsansvarlige? En WordPress-redaktør kan normalt ikke gennemføre denne opdatering.
Bed om den kørende version og pakkens identitet. Svaret skal gælde den PHP-tjeneste, som håndterer webtrafikken, ikke kun en kommandolinjeversion på samme server.
Bed om CVE-bekræftelse. Få oplyst, om den konkrete build indeholder rettelser til begge CVE’er, også hvis de er backportet.
Bed om genstart og kontrol. PHP-workers skal genstartes efter relevante konfigurationsændringer. Bed derefter om, at den faktisk kørende build bliver kontrolleret igen via udbyderens godkendte driftsværktøj.
Følg op på CVE-2026-115560 i PHP-meddelelsen fra 23. oktober. Den særskilte fejl har snæver anvendelighed: Session upload progress skal være aktiveret, konfigurationen skal bruge handleren php_binary eller php_serialize, og applikationskoden skal skifte til php under kørsel før session_start(). PHP oplyser, at applikationer, som aldrig skifter handler under kørsel, kan beholde funktionen aktiveret. Er den allerede deaktiveret som afværgelse, skal den forblive deaktiveret. Bed hosting eller den driftsansvarlige om at vurdere betingelserne og foretage eventuelle ændringer.

Du kan sende denne korte besked:

Kører vores website en PHP-build, som er rettet mod både CVE-2026-109618 og CVE-2026-109619? Oplys gerne den version eller leverandørpakke, der faktisk håndterer webtrafikken, samt den sikkerhedsmeddelelse eller buildreference, som dokumenterer eventuelle backports. Er PHP-workers genstartet efter opdateringen? Er vores opsætning omfattet af CVE-2026-115560, hvor session upload progress er aktiveret, handleren er php_binary eller php_serialize, og applikationen skifter til php før session_start()?

Hvis du selv driver serveren, bør opdatering, genstart og kontrol følge din distributions eller PHP-leverandørs vejledning. Undgå at lægge en offentlig phpinfo()-side ud for at finde versionsnummeret. Den kan afsløre flere oplysninger om serveren end nødvendigt. Undgå også at afprøve et offentligt exploit eller en proof of concept mod sitet. En defensiv versions- og pakkekontrol er tilstrækkelig til den første afklaring.

De to fejl kort forklaret

CVE-2026-109618 handler om fejltilstande ved mangel på hukommelse. PHP kan blive afbrudt, mens interne data kun er delvist initialiseret, hvorefter oprydningen kan behandle ugyldige data som gyldige.

CVE-2026-109619 handler om intern tilstand, der kan overleve, efter at den tilhørende hukommelse er frigivet. En senere webanmodning i samme worker kan ramme den forældede tilstand. De præcise betingelser afhænger af servertype, konfiguration og applikationsforløb, men PHP’s råd er ikke at forsøge at afgøre sikkerheden ud fra CMS’et alene.

Midlertidige konfigurationsændringer kan begrænse bestemte angrebsveje, men PHP understreger, at de ikke erstatter den fulde rettelse. Hvis en udbyder endnu ikke kan opdatere, bør udbyderen følge PHP’s konkrete afværgeråd og forklare både begrænsningerne og tidsplanen for en varig opdatering.