Hvorfor kommer der flere og flere sikkerhedshuller? PHP2Shell, AI og det, du kan gøre

Hvorfor kommer der flere og flere sikkerhedshuller?

I går skrev jeg om, hvordan jeg håndterede PHP2Shell på de hjemmesider, jeg passer. Det var en lang dag, men den endte godt.

Det her indlæg handler om det større billede. PHP2Shell er ikke en enlig ulykke. Den er det seneste eksempel på en udvikling, der har taget fart: flere sikkerhedshuller end nogensinde, fejl dybt nede i de byggesten, alle bruger, og angreb der starter, før rettelsen er ude. Og midt i det hele står AI, både hos dem der finder fejlene, og hos dem der udnytter dem.

Hvad er en CVE?

En CVE er et løbenummer for et kendt sikkerhedshul, fx CVE-2026-109618 for den ene af PHP2Shell-fejlene. Nummeret gør det muligt for udviklere, hostingfirmaer og sikkerhedsværktøjer at tale om den samme fejl. Det siger ikke i sig selv, hvor farlig fejlen er. Det gør scoren (CVSS), der går fra 0 til 10. PHP2Shell fik 9,2.

PHP2Shell kort fortalt

PHP2Shell er to fejl i selve PHP, programmeringssproget bag WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel og et hav af andre systemer. Ifølge W3Techs kører omkring 69 % af de hjemmesider, hvor man kan se serversproget, på PHP.

Et par ting gør den særlig:

• Fejlen har ligget i koden i over ti år og virker i standardopsætningen. Man behøver ikke have gjort noget forkert for at være sårbar.
• Den sidder under alt det, ejeren ser. Opdagerne viste, at de kunne overtage servere med WordPress, Drupal, Joomla, Magento, Nextcloud og Laravel uden at logge ind. At opdatere WordPress hjalp ikke. Det var motoren under, der skulle skiftes.
• Den blev fundet med hjælp fra AI. Sikkerhedsfirmaet Calif skriver åbent, at de brugte en sprogmodel som "audit buddy" og byggede videre på et mønster, modellen hjalp dem med at finde. Wiz Research og OpenAI krediteres også for fundene.
• Angrebene startede før rettelsen. Detaljerne slap ud dagen før, og Cloudflare så de første angreb kl. 9.43 dansk tid, omkring seks timer før PHP udgav de rettede versioner.

Hvor udbredt udnyttelsen er nu, er kilderne ikke enige om. Amazon skriver, at fejlen bliver udnyttet bredt, mens PHP's eget sikkerhedsteam ikke havde set fungerende angrebskode, da rettelsen kom ud. Det ændrer ikke på, hvad man skal gøre: opdatere.

Det er ikke første gang

Kritiske fejl i byggesten, som millioner af systemer står på, er blevet et fast mønster:

• Log4Shell (2021) i Java-biblioteket Log4j fik den højeste score, 10. Det svære var ikke at rette fejlen, men at finde ud af, hvor man overhovedet brugte biblioteket.
• xz-utils (2024) var en bagdør, som nogen bevidst havde plantet i et lille komprimeringsbibliotek i Linux. Den blev fundet ved et tilfælde, fordi en udvikler undrede sig over, at SSH-logins brugte for meget CPU.
• Next.js (marts 2025) havde en fejl, der lod angribere springe login-tjek over på selvhostede sider.
• React Server Components (december 2025) fik også scoren 10: kode kunne køres på serveren uden login, og det ramte blandt andet Next.js.
• WordPress core (juli 2026) fik selv en kæde af fejl, kaldet wp2shell, der gav fuld kontrol over en side uden konto og uden plugins. Den blev også fundet med AI.
• PHP2Shell (oktober 2026) ramte sproget under det hele.

Fællesnævneren er, at fejlene sidder i lag, som ejeren af en hjemmeside aldrig ser og sjældent ved, at de har.

Hvorfor kommer der flere CVE'er?

Tallene taler deres eget sprog. Sikkerhedsforskeren Jerry Gamblin tæller de offentliggjorte CVE'er hvert år:

Første halvår af 2026 gav altså flere CVE'er end hele 2023. Det amerikanske standardiseringsinstitut NIST, som driver den store database over sårbarheder (NVD), skriver, at antallet af indberetninger er steget 263 % fra 2020 til 2025. De kan ikke længere nå at gennemgå dem alle og prioriterer nu dem, der bliver udnyttet.

Der er flere grunde til væksten:

• Flere må udstede numre. I 2025 var der 365 organisationer, der kunne tildele CVE-numre. To af de største er Patchstack og Wordfence, der begge arbejder med WordPress. De stod tilsammen for over 10.000 CVE'er i 2025, omkring hver femte.
• Linux-kernen tildeler nu et nummer til næsten enhver fejlrettelse, også dem der næppe kan udnyttes.
• AI finder flere fejl. Sprogmodeller gennemgår kode hurtigere end mennesker, og de finder fejl, som har ligget urørt i årevis.
• Der bliver skrevet mere kode end nogensinde, også med AI, og mere kode giver flere fejl.

Men flere CVE'er betyder ikke, at verden er blevet tilsvarende farligere. Kun 8,3 % af CVE'erne i 2025 var kritiske. Og af de 35.364 fra første halvår af 2026 er kun 85 kommet på den amerikanske cybermyndigheds (CISA) liste over sårbarheder, der rent faktisk bliver udnyttet. Det svarer til 0,24 %.

Problemet er altså ikke, at alt er farligt. Problemet er at finde de få, der er, i en bunke, der vokser hurtigere end nogen kan læse den.

Tiden fra fejl til angreb er forsvundet

Det, der for alvor har ændret sig, er tempoet.

• Googles sikkerhedsfirma Mandiant anslår, at fejl i gennemsnit bliver udnyttet 7 dage før rettelsen kommer. Angreb starter altså rutinemæssigt, før der findes en rettelse at installere. For få år siden havde man flere uger.
• VulnCheck har opgjort, at 29 % af de sårbarheder, der blev udnyttet i 2025, blev udnyttet på eller før den dag, fejlen blev offentliggjort.
• For WordPress er det endnu hurtigere. Patchstack har målt, at de mest udnyttede fejl i mediantal bliver angrebet 5 timer efter offentliggørelsen.

Tidligere kunne man opdatere en gang om måneden og være nogenlunde dækket. Det kan man ikke længere.

WordPress: problemet sidder i plugins

WordPress er et særligt kapitel, fordi så mange mindre virksomheder bruger det. Patchstack registrerede 11.334 nye sårbarheder i WordPress-verdenen i 2025, 42 % flere end året før.

• 91 % sad i plugins, 9 % i temaer, og kun 6 i selve WordPress.
• 46 % havde ingen rettelse, da de blev offentliggjort.

Hvert plugin er altså en dør, der skal holdes øje med. Og næsten halvdelen af gangene er der ingen ny lås at sætte i, når hullet bliver kendt. 2026 har så vist, at selv WordPress' egen kerne og PHP under den kan ramme alle på én gang.

AI: på begge sider af bordet

Jeg bruger selv AI hver dag i mit arbejde, og jeg ser det som et værktøj, der gør mig hurtigere og grundigere. Men det er tydeligt, at det samme værktøj ændrer sikkerhedsbilledet i begge retninger.

AI finder fejl, mennesker ikke fandt

Google har en AI-agent, Big Sleep, som har fundet fejl i blandt andet databasen SQLite, før angribere nåede at bruge dem. I den amerikanske forsvarskonkurrence AIxCC i 2025 fandt AI-systemer 54 ud af 63 plantede fejl og rettede 43 af dem, og de fandt samtidig 18 ægte, ukendte fejl. Anthropic, firmaet bag Claude, skriver, at deres nyeste model har fundet tusindvis af alvorlige fejl i styresystemer og browsere. Det er firmaets egen opgørelse, men retningen er tydelig.

Det mest interessante ved PHP2Shell er en detalje, Calif selv fortæller: den samme type fejl blev fundet ved en gennemgang af PHP i 2024, men den blev ikke rettet, fordi ingen kunne bevise, at den kunne udnyttes. Med AI kunne de bevise det. AI gør det billigere at gå fra "her ser mistænkeligt ud" til "her er et angreb, der virker". Det er godt for dem, der retter fejl. Det er også godt for dem, der vil misbruge dem.

AI hjælper angribere

Efter wp2shell i WordPress byggede Calif en udvidelse af angrebet, der gav fuld kontrol over serveren. Med en AI-assistent tog det under en time. Ifølge dem tager den slags normalt nogle uger.

Anthropic har beskrevet, hvordan en statsstøttet gruppe brugte Claude til en spionagekampagne mod omkring 30 mål, hvor AI'en ifølge Anthropic udførte 80 til 90 % af arbejdet. Google har set den første skadelige software, der spørger en sprogmodel om hjælp, mens den kører. Den blev brugt af en russisk gruppe mod Ukraine.

AI skaber også støj

Daniel Stenberg, der står bag curl, et af verdens mest brugte stykker software, lukkede i januar 2026 sit dusørprogram for fejlrapporter. Det blev oversvømmet af AI-genererede rapporter, der lød overbevisende, men var forkerte. Andelen af ægte fejl faldt fra over 15 % til under 5 %. Og af de 1.061 sårbarheder, VulnCheck har set tilskrevet AI-fund i første halvår af 2026, er kun 14 blevet udnyttet i praksis.

AI skriver også fejl

Når AI skriver kode, er den ikke automatisk sikker. Sikkerhedsfirmaet Veracode testede over 100 sprogmodeller i 2025, og 45 % af koden fejlede deres sikkerhedstest. Større og nyere modeller var ikke bedre. Et forskningsstudie viste, at AI-modeller af og til finder på navne på softwarepakker, der ikke findes, hos de kommercielle modeller i mindst 5 % af tilfældene. Det kan angribere udnytte ved at oprette pakker med netop de navne.

Min holdning

Jeg tror ikke på, at AI gør verden mere eller mindre sikker af sig selv. Den gør alting hurtigere. Fejl bliver fundet hurtigere, rettet hurtigere og udnyttet hurtigere. Det belønner dem, der er hurtige til at opdatere, og straffer dem, der venter.

For mit eget arbejde betyder det, at AI må skrive og foreslå, men at det er mig, der gennemgår, tester og står inde for det, der kommer ud på en kundes server. Og at opdateringer ikke er noget, man gør, når man lige har tid.

Lovgivningen følger efter

EU har vedtaget Cyber Resilience Act. Fra 11. september 2026 skal producenter af software og digitale produkter i EU melde aktivt udnyttede sårbarheder inden for 24 timer, og fra december 2027 gælder resten af reglerne om sikkerhed i produkterne. I Danmark trådte NIS2-loven i kraft 1. juli 2025 og stiller krav til virksomheder i en række kritiske sektorer.

Reglerne rammer først og fremmest producenter og større virksomheder. Min vurdering er, at mindre virksomheder vil mærke dem indirekte, når kunder og samarbejdspartnere begynder at spørge, hvordan man håndterer sikkerhed og opdateringer.

Sådan beskytter du dig

Den gode nyhed er, at det, der beskytter mod PHP2Shell, også beskytter mod det meste andet. Styrelsen for Samfundssikkerhed udgav i denne uge ni nationale råd til små virksomheder, og de passer fint med min egen erfaring. Her er, hvad jeg vil anbefale for en hjemmeside:

1. Find ud af, hvem der opdaterer hvad. WordPress, plugins, tema, PHP og serveren bliver ofte opdateret af forskellige. På delt hosting er det hostingfirmaet, der opdaterer PHP. Har du en server selv, er det dig eller din udvikler.
2. Slå automatiske opdateringer til, og tjek, at de kører. Det nytter ikke, at de er slået til, hvis de stille fejler. Nogen skal se efter.
3. Kør en PHP-version, der stadig får rettelser. PHP 8.1 og ældre fik ingen rettelse af PHP2Shell.
4. Hav færre plugins. Når 91 % af sårbarhederne sidder i plugins, er hvert plugin, du fjerner, en dør mindre. Fjern dem, du ikke bruger, og vælg dem, der bliver vedligeholdt.
5. Tag backup, og test, at den kan lægges tilbage. En backup, der aldrig er prøvet, er et håb, ikke en plan. Læs min guide til backup af WordPress.
6. Brug to-faktor-login på WordPress, hosting, domæne og mail. Den amerikanske cybermyndighed CISA anbefaler det som et af de første skridt.
7. Brug en firewall (WAF) som ekstra lag, ikke som erstatning for opdateringer. Den kan købe tid, mens man venter på en rettelse.
8. Overvåg siden, så du opdager det, hvis den går ned, ændrer sig eller begynder at sende besøgende videre til fremmede sider.
9. Aftal, hvad der skal ske, når det går galt. Hvem ringer du til, og hvem har adgang til hvad? Det er langt nemmere at aftale en tirsdag formiddag end en fredag aften med et hacket site.

Vil du gå mere i dybden, har jeg samlet otte punkter i en sikkerheds-baseline for små virksomheder.

Kilder

• Calif: PHP2Shell, opdagernes egen gennemgang
• Sansec: PHP2Shell, tidslinje og afhjælpning
• Tenable: ofte stillede spørgsmål om PHP2Shell
• Jerry Gamblin: 2025 CVE Data Review og CVE Mid-Year 2026 Check-In
• NIST: NVD prioriterer på grund af rekordmange CVE'er
• Mandiant: M-Trends 2026
• VulnCheck: State of Exploitation 2026 og første halvår 2026
• Patchstack: State of WordPress Security in 2026
• Calif: wp2root, fra wp2shell til fuld kontrol
• Google: Big Sleep og SQLite
• DARPA: resultater fra AIxCC
• Anthropic: Project Glasswing og AI-styret spionagekampagne
• Google Threat Intelligence: angriberes brug af AI
• Daniel Stenberg: curl lukker sit dusørprogram
• Veracode: sikkerheden i AI-genereret kode
• Studie: AI-modeller der finder på pakkenavne
• EU-Kommissionen: Cyber Resilience Act
• Digitaliseringsstyrelsen: NIS2
• CISA: Cyber Essentials
• Sikkerdigital.dk: ni råd om digital sikkerhed for små virksomheder