PHP2Shell er to familier af sikkerhedsfejl i PHP, som kan give angribere mulighed for at køre kode uden at logge ind. AI hjalp forskere med at undersøge fejlene. Hændelsen viser samtidig, hvorfor et fund først bliver til beskyttelse, når rettelsen er installeret og kører på den berørte server.
PHP2Shell viser, hvordan AI kan hjælpe med at finde alvorlige fejl i webserveres software, mens beskyttelsen kræver bekræftede sikkerhedsrettelser. En opdateret hjemmeside og et positivt versionstjek dokumenterer ikke alene, at PHP-installationen er rettet, eller at tidligere misbrug er udelukket.
Hvad dækker PHP2Shell over?
Navnet dækker fejl i PHP-motorens håndtering af hukommelse og afbrudte webforespørgsler. De er samlet under identifikatorerne CVE-2026-109618 og CVE-2026-109619. PHP behandler blandt andet programkode på en webserver og sender resultatet til browseren.
Problemet kan opstå, når en forespørgsel afbrydes, men ugyldig intern tilstand bliver tilbage. Senere behandling kan så bruge hukommelse forkert. Wiz beskriver både mulighed for at læse proceshukommelse og for at udføre kode. Rapporten viser konkrete demonstrationer, ikke at alle berørte installationer kan angribes på præcis samme måde.
Hvilken rolle spillede AI i fundene?
OpenAI offentliggjorde den 21. oktober 2026 en redegørelse for arbejdet gennem Patch the Planet. Ifølge redegørelsen fandt Calif en kritisk fejl med GPT-5.6 Sol, mens Wiz uafhængigt fandt og rapporterede begge sårbarheder.
Wiz oplyser, at forskerne brugte Wiz Atlas, Gemini 4 Argon og GPT-5.6 Sol. AI indgik i analyse, udvikling af angrebsdemonstrationer og kontrol af rettelser. Menneskelige forskere og PHP-vedligeholdere deltog i arbejdet.
Forløbet udbygger anvendelsen af AI til at finde sårbarheder i software. Det dokumenterer et konkret samarbejde; det giver ikke en generel succesrate for automatiske sikkerhedstjek.
Hvorfor kan en opdateret hjemmeside stadig være berørt?
Wiz demonstrerede angreb mod installationer af WordPress, Drupal og Joomla. Fejlene ligger i PHP under applikationen. En opdatering af et tema eller en udvidelse er derfor ikke i sig selv dokumentation for, at PHP-fejlen er rettet.
Som praktisk eksempel kan en webredaktør have opdateret hjemmesidens indholdssystem, mens en hostingudbyder styrer PHP-versionen. De to vedligeholdelsesopgaver har forskellige ansvarlige. Spørgsmålet til leverandøren bliver derfor, om den konkrete PHP-installation har fået sikkerhedsrettelsen.
Eksemplet beskriver en ansvarsfordeling, ikke et konstateret problem hos en bestemt udbyder.
Hvilke PHP-versioner indeholder rettelserne?
PHP-projektet udgav den 21. oktober 2026 følgende rettede versioner:
| Versionsgren | Rettet udgave |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Linux-distributioner og leverandører med udvidet vedligeholdelse kan levere tilbageførte rettelser, også kaldet backports. Versionsnummeret skal derfor læses sammen med leverandørens sikkerhedsmeddelelse.
PHP 8.1 og ældre modtager ikke længere almindelige opdateringer fra PHP-projektet. Projektet har dog stillet minimale koderettelser til rådighed for 7.4, 8.0 og 8.1 i denne sag. Det er ikke det samme som genoptaget generel vedligeholdelse.
Hvordan bliver et AI-fund til en sikkerhedsrettelse?
En model kan pege på mistænkelig kode, men et muligt fund kræver bekræftelse. En sårbarhedstest skal afklare, hvad der faktisk kan udløses, under hvilke betingelser og med hvilken konsekvens.
I PHP-forløbet ledte vedligeholderne rettelserne og udgivelsen med støtte fra forskere og infrastrukturleverandører. Rettelser blev også undersøgt for omgåelser og beslægtede fejl.
Der er dermed flere selvstændige kontrolpunkter: Er fundet reelt? Retter ændringen problemet? Er ændringen installeret? Kører den rettede software? Et positivt svar på det første spørgsmål besvarer ikke de øvrige.
Hvad betyder koordineret offentliggørelse?
Koordineret offentliggørelse giver vedligeholdere og relevante leverandører mulighed for at forberede rettelser og beskyttelse, før detaljer bliver offentlige. OpenAI beskriver et forslag til en ramme, hvor vedligeholderne afgør, hvem der skal involveres tidligt.
Afvejningen er konkret: Tid kan gøre opdateringer klar, mens deling af detaljer også kan afsløre angrebsveje. OpenAI foreslår at genoverveje tidsplanen ved blandt andet læk eller aktiv udnyttelse. Rammen er et oplæg, ikke en bindende standard.
Hvad kan en versionskontrol faktisk vise?
OpenAI har udgivet en PHP-versionskontrol. Den sammenholder versionsoplysninger fra HTTP-headers eller en lokal PHP-kommando med indbyggede grænser. Den er ikke en fuld undersøgelse af serverens sikkerhed.
- OK betyder, at den oplyste stabile version ligger over kontrollens grænse for den pågældende gren.
- VULNERABLE betyder, at det oplyste versionsnummer ligger på eller under grænsen.
- UNKNOWN betyder, at kontrollen ikke kan afgøre status, eksempelvis fordi versionsoplysninger er skjult.
Dokumentationen præciserer, at OK ikke uafhængigt bekræfter rettelsen. Værktøjet følger heller ikke omdirigeringer. Et manglende eller uklart svar kan derfor ikke bruges som bevis for sikkerhed.
En distributionspakke med tilbageførte rettelser kan omvendt bevare et ældre versionsnummer. Derfor må resultatet sammenholdes med den konkrete pakkes sikkerhedsstatus.
Kan midlertidige værn erstatte opdateringen?
PHP-projektets advarsel siger, at kun en opdatering er en fuldstændig løsning. De beskrevne konfigurationsændringer kan reducere bestemte angrebsveje, men gør ikke installationen sikker.
Den praktiske forskel er mellem at begrænse eksponering og at fjerne årsagen. Et midlertidigt værn kan indgå i en plan med et tydeligt sluttidspunkt: den bekræftede udbedring. En meddelelse om beskyttelse bør derfor præcisere, om den beskriver en installeret rettelse eller en midlertidig foranstaltning.
Hvad betyder hændelsen for arbejdspladser i Danmark?
For webbureauer, virksomheder og offentlige arbejdspladser er den umiddelbare relevans driften af websystemer. Organisationen behøver ikke selv bruge AI for at være afhængig af software, hvor AI har bidraget til at finde en fejl.
En nyttig opdeling af ansvaret kan være:
- Webredaktionen identificerer de hjemmesider og tjenester, organisationen bruger.
- Leverandøren beskriver de relevante PHP-pakker og de gennemførte rettelser.
- It-driften bekræfter den aktive installation og vurderer eventuelle tegn på misbrug.
Det er en praktisk fortolkning af hændelsen, ikke en oplysning om bestemte angreb i Danmark. Kilderne dokumenterer ikke, hvor mange lokale organisationer der er berørt.
Hvordan kan udbedringen dokumenteres?
En afgrænset arbejdsgang kan gøre en sikkerhedsaudit mere konkret:
- Registrér tjenesten, den driftsansvarlige og den relevante leverandørmeddelelse.
- Notér, hvilken pakke eller PHP-udgave der indeholder rettelsen.
- Få bekræftet, at webtjenesten faktisk kører den rettede installation.
- Kontrollér tjenestens funktion efter ændringen, og gem resultat og tidspunkt.
- Vurder særskilt, om hændelsesdata giver anledning til at undersøge tidligere kompromittering.
Listen er et eksempel på dokumentation, ikke en komplet procedure for alle systemer. Den skelner mellem en bestilt opdatering, en gennemført ændring og et kontrolleret resultat. En installeret rettelse afgør ikke i sig selv, hvad der skete før installationen.
Hvornår bliver GDPR relevant?
En sårbar PHP-version er ikke alene dokumentation for et brud på persondatasikkerheden. Hvis undersøgelsen viser et sådant brud, skal den dataansvarlige vurdere anmeldelsespligten og risikoen for de berørte personer.
Datatilsynet angiver anmeldelse uden unødig forsinkelse og om muligt inden 72 timer efter, at den dataansvarlige er blevet bekendt med bruddet. Undtagelsen er, hvis det er usandsynligt, at bruddet medfører risiko for personers rettigheder eller frihedsrettigheder.
Teknisk udbedring og håndtering af et muligt datalæk er derfor to forskellige spor. En bekræftelse af, at serveren nu er opdateret, er ikke samtidig en afklaring af, om personoplysninger tidligere er blevet berørt.
Hvilke kilder ligger til grund?
OpenAIs redegørelse beskriver AI-arbejdet og koordinationen. PHP-projektets sikkerhedsadvarsel dokumenterer rettelserne, og Wiz-forskernes tekniske rapport beskriver demonstrationerne. Begrænsningerne følger dokumentationen til PHP-versionskontrollen; anmeldelsesreglerne følger Datatilsynets vejledning.