AI oversvømmer WordPress med sårbarhetsrapporter. Hvem betaler for rettelsene?

På 90 dager fikk WordPress sitt sikkerhetsprogram 2004 sårbarhetsrapporter og utbetalte over 90 000 dollar for dem. Det er nesten halvparten av alt programmet har utbetalt siden 2017. Til nå har én aktør betalt for det, Automattic. Mandag 5. oktober 2026 skrev Mary Hubbard, administrerende direktør i WordPress, til lederne i over 30 selskaper og ba dem bidra.

Jeg skriver dette på grunnlag av en artikkel fra The Repository av 8. oktober 2026, som siterer Hubbards e-post (The Repository, 8. oktober 2026), og kunngjøringer på wordpress.org. Selve e-posten har jeg ikke sett. Tallene og sitatene sjekket jeg mot kildene 9. oktober 2026.

#Hva Mary Hubbard ba hosting- og utvidelsesselskapene om

E-posten gikk til toppsjefer i vert-, plugin- og sikkerhetsselskaper mandag kveld UTC. The Repository skriver “Monday evening UTC” i teksten fra torsdag 8. oktober. Hovedpoenget: AI har gjort det billigere å lete etter sårbarheter.

“AI hadde fått kostnaden ved å finne, rapportere og utnytte sårbarheter til å kollapse”

Mary Hubbard, sitert av The Repository, 8. oktober 2026, egen oversettelse

Ifølge henne fikk programmet nesten 2000 rapporter på 90 dager, flere enn noen gang, “og tempoet øker fortsatt” (egen oversettelse). The Repository sjekket programsiden på HackerOne: 2004 rapporter og over 90 000 dollar i belønninger på 90 dager, mot drøyt 200 000 dollar utbetalt siden starten i april 2017.

“Nesten halvparten av alt programmet har betalt ut siden starten, skjedde i ett enkelt kvartal, og kurven går bare én vei.”

Mary Hubbard, sitert av The Repository, 8. oktober 2026, egen oversettelse

Hubbard skriver også at Automattic finansierte programmet 100 %: hver belønning, triage, verifisering, rettelser og koordinerte sikkerhetsutgivelser for alle støttede grener helt ned til WordPress 4.7. Hun ber om ett av tre: et bidrag til en felles belønningspott, sponsing av folk til triage og utgivelser, eller en annen form som avtales sammen. Hun understreker at en del av veksten er ekte forskning som går raskere med nye verktøy og faktisk gjør WordPress tryggere. Hun oppsummerer det slik: “Det er økonomien som er i stykker, ikke programmet” (egen oversettelse).

#Hvilke selskaper ble bedt om å finansiere WordPress-sikkerheten

Øverst blant mottakerne var GoDaddy, Newfold Digital og Hostinger. The Repository nevner videre:

Kilde: The Repository, 8. oktober 2026.

E-posten gikk ikke til WP Engine, som har ligget i rettstvist med Automattic siden 2024, selv om representanter for WP Engine er nevnt i takkelisten for sikkerhetsutgivelsene 7.0.2 og 7.1.1. Nexcess sto heller ikke på listen.

#Hvordan hosting- og utvidelsesselskapene svarte

De som svarte The Repository er positive, men vil vite nøyaktig hva de forplikter seg til.

• Hostinger (Marco Chiesi): vurderer å frigjøre egne folk. Siden juli har de samarbeidet med sikkerhetsteamet og innført WAF-regler før rettelsene publiseres.
• Kinsta (Jon Penland): vil ha et “clearly defined” (klart definert) program som selskapene kan bidra til.
• Awesome Motive (Syed Balkhi): sponser allerede flere bidragsytere i sikkerhets- og pluginteamene, men påpeker at forespørselen er “quite open-ended”.
• Human Made (Tom Willmot): sponser John Blackbourn, som representerer sikkerhetsteamet på heltid. Byrået har tidligere forsøkt å samle selskaper rundt et sikkerhetsfond, “dessverre uten særlig gjennomslag” (egen oversettelse).
• Patchstack (Oliver Sild): selskapet har betalt ut 600 000 dollar i belønninger av egen lomme siden 2022, men har aldri blitt sluppet inn i WordPress sine sikkerhets- og pluginteam. Etter hans mening “må denne prosessen reformeres” (egen oversettelse).

GoDaddy, Newfold Digital og Wordfence hadde ikke svart da teksten ble publisert.

#WordPress 7.1.4: 22 sårbarheter og hva det betyr for nettstedet ditt

Oppdatering, 30. oktober 2026. WordPress 7.1.4 kom 28. oktober. Versjonssiden teller 22 sårbarheter. Den alvorligste er en kappløpstilstand i oppdateringsprosessen i kjernen, som ifølge den som meldte den, Umut Bayram, kunne føre til fjernkjøring av kode. De fleste av de andre er lagret XSS som krever minst en bidragsyterkonto. To av meldingene er kreditert Anthropic. Rettelsene er tilbakeført til eldre grener, fra 7.0.8 ned til 4.7.39, og nettsteder med automatiske bakgrunnsoppdateringer får oppdateringen av seg selv.

Det er den sjuende sikkerhetsutgivelsen av kjernen siden juli. I statusen etter to måneder med Core Security Initiative skriver Rudy Faile at teamet har fått over 3000 meldinger i år, flere enn de tolv foregående årene til sammen, og at 73 % av de 109 stegene i en sikkerhetsutgivelse nå er automatisert. I det tempoet er det ikke lenger trygt å vente med sikkerhetsoppdateringen til helgen. I WordPress-oppdateringene mine går sikkerhetsutgivelser først til et testmiljø og deretter til produksjon.

#Hva WordPress 7.1.3 retter, og hvem som rapporterte feilene

Dagen etter e-posten, 6. oktober 2026, kom WordPress 7.1.3 med 7 sikkerhetsrettelser og 4 andre feilrettinger. Kunngjøringen oppgir for hver rettelse hvem som meldte den:

Kilder: rapportører ifølge WordPress.org, 6. oktober 2026, utnyttelsesvilkår ifølge Patchstack, 6. oktober 2026.

Bare ett av sju hull virker uten noen konto og uten at et offer må gjøre noe: lekkasjen av kommentarer fra private innlegg. Patchstack forklarer mekanismen: i kommentarfeeden til ett enkelt innlegg hentet WordPress først kommentarene og sjekket deretter om den besøkende fikk se innlegget. Sjekken skjulte innlegget, men ikke kommentarene, og feeder returnerer ikke 404, så kommentarene havnet i feeden. Tre av de øvrige seks krever en Bidragsyter- eller Forfatter-konto.

Fire av de sju rapportene kommer fra selskaper som bygger AI-modeller, eller fra partnerne deres. Det illustrerer Hubbards tese godt: i dag er det også AI som finner hullene, og for hvert av dem må noen betale med triage, rettelse og utgivelse for hver støttede gren. I kunngjøringen står det at rettelsene portes til alle grener som får sikkerhetsrettelser, for tiden helt ned til 4.7, og utgis etter hvert som de blir klare.

#Sikkerhetsrettelser i WordPress 7.1.1 og 7.1.2

Ifølge Patchstack kom utgivelse 7.1.2 to uker før 7.1.3 og rettet én sårbarhet (CVE-2026-87902). Den lot en besøkende uten innlogging utløse inkludering av en lokal fil, og med riktig PHP-konfigurasjon kunne den føre til ekstern kjøring av kode (Patchstack, 6. oktober 2026).

Tidligere, i september, beskrev Patchstack også en sårbarhet for ekstern kjøring av kode som ble rettet i 7.1.1. Hvis nettstedet ditt står på 7.1.0, mangler det rettelser fra tre utgivelser på rad.

#Hva er Core Security Initiative i WordPress

28. august 2026 kunngjorde sikkerhetsteamet Core Security Initiative på make.wordpress.org (Make WordPress Security, 28. august 2026). Kunngjøringen knytter en “substantial increase” i antall rapporter til den raske utviklingen av frontier-AI-modeller. Den beskriver det som et godt problem, men et som krever skalering av triage, verifisering og retting.

Initiativet gjelder WordPress-kjernen. Det omfatter ikke plugins eller temaer. Rapporter tas imot av programmet på HackerOne, mens sårbarheter i WordPress.com og mobilappene går separat, via Automattics program.

#Hvordan Patchstack og Wordfence filtrerer KI-genererte sårbarhetsrapporter for utvidelser

Tallene fra HackerOne gjelder bare kjernen. Hull i utvidelser og temaer går gjennom andre programmer, og der vises den samme kurven. I mars 2026 mottok Wordfence Bug Bounty Program 1718 sårbarhetsrapporter, 59,4 % flere enn i februar, fra 321 aktive forskere, og betalte ut 62 174 USD i dusører den måneden (Wordfence, rapport for mars 2026). Rapporten sier ikke hvor mange av rapportene som ble skrevet med hjelp fra KI.

Patchstack navngir årsaken direkte. 29. mai 2026 skrev Dave Jong, leder for sikkerhetsforskning i selskapet, at programmet siden KI-støttet forskning tok av, særlig i 2026, får flere rapporter med lav innvirkning som så vidt oppfyller kriteriene, flere duplikater (én sårbarhet fikk mer enn 20 dupliserte rapporter fra ulike forskere) og rapporter bygget på feilaktige KI-genererte antakelser (Patchstack, 29. mai 2026). Fra 1. juni 2026 har Patchstack:

• fjernet rollen Bidragsyter (Contributor) fra omfanget, så et hull må kunne nås av en gjest, Abonnent, Kunde eller en lignende lav rolle,
• knyttet vilkår til hver sårbarhetsklasse, for eksempel må XSS ha virkning på hele nettstedet eller være reflektert,
• begrenset den månedlige dusørpotten til de 5 beste forskerne,
• innført én ukes utestengelse for alle som sender inn feilaktige KI-genererte antakelser eller en rapport som ikke er testet mot den faktiske utvidelsen eller temaet.

Retningslinjene slik de var publisert 13. oktober 2026 krever også et trinnvis proof of concept i tekst med rå HTTP-forespørsler og eksakte payloads, og en komponent med minst 1000 aktive installasjoner (Patchstacks retningslinjer for bug bounty).

For en utvidelsesutvikler betyr dette filteret mer enn kjernebudsjettet. En rapport som kommer gjennom plattformens triage, havner likevel hos utvikleren, som må gjenskape den og levere en rettelse, som regel uten egne penger fra dusørene.

#Hvem som håndterer sårbarheter i utvidelser og CVE-numre på WordPress.org

Utvidelseskatalogen har sin egen vei. Plugin Handbook ber den som rapporterer om å kontakte utvikleren først, og bare hvis det mislykkes skrive til [email protected], uten å omtale problemet offentlig. Utvidelsesteamet handler da på selve oppføringen: de fleste utvidelser stenges for nye nedlastinger til problemet er løst. Samme side sier at teamet ikke hjelper med å registrere CVE-er på grunn av mangel på ressurser (Plugin Handbook, Reporting plugin security issues, sist endret 2. januar 2026).

CVE-numre for WordPress-utvidelser kommer derfor i stor grad fra sikkerhetsselskaper registrert som CVE Numbering Authorities. Partnerlisten i CVE-programmet gir Wordfence ansvar for sårbarheter i utvidelser, temaer og kjerne som teamet oppdager eller får rapportert, WPScan WordPress-kjernen, utvidelser og temaer, og Patchstack sårbarheter funnet av eget team og deltakerne i selskapets bug bounty (CVE Program, partnerliste).

Disse selskapene betaler for triage av utvidelser med egne inntekter og selger beskyttelse oppå. Wordfence skriver at brukere av Premium, Care og Response får brannmurregler i sanntid, mens gratisbrukere får dem etter 30 dager. Det er det andre svaret på hvem som betaler: for utvidelser ligger triagekostnaden allerede hos sikkerhetsleverandørene, og to av dem, Wordfence og Patchstack, står på Hubbards liste.

#Hva EUs Cyber Resilience Act krever av leverandører av WordPress-utvidelser

Fra 11. september 2026 er en del av denne kostnaden også en lovpålagt plikt i EU. Cyber Resilience Act, forordning (EU) 2024/2847, gjelder fullt ut fra 11. desember 2027, men artikkel 71 nr. 2 fremskyndet artikkel 14 om rapportering til 11. september 2026 (forordning (EU) 2024/2847, EUR-Lex). En produsent som får kjennskap til en aktivt utnyttet sårbarhet i sitt produkt, må varsle den utpekte CSIRT-en og ENISA via én felles rapporteringsplattform:

Artikkel 3 nr. 13 definerer en produsent som den som utvikler et produkt og markedsfører det under eget navn eller varemerke, mot betaling, for inntjening eller gratis. Et selskap som selger en premium-utvidelse under sitt merke, passer rett inn i den ordlyden. Artikkel 13 nr. 6 legger til at en produsent som finner en sårbarhet i en integrert komponent, også åpen kildekode, må rapportere den til den som vedlikeholder komponenten og dele rettelsen. Brudd på artikkel 13 og 14 kan koste opptil 15 millioner EUR eller 2,5 % av den samlede årlige omsetningen globalt, avhengig av hva som er høyest (artikkel 64 nr. 2). Svært små og små foretak slipper bøter bare for å overskride fristen for tidlig varsel på 24 timer (artikkel 64 nr. 10).

Forvaltere av åpen kildekode (open-source software stewards), juridiske personer som systematisk støtter fri programvare beregnet for kommersiell virksomhet, får et lettere regime: en dokumentert retningslinje for cybersikkerhet (artikkel 24) og ingen administrative bøter i det hele tatt (artikkel 64 nr. 10 bokstav b). Forordningen sier ikke hvem som betaler for slik forvalters triage, og det er det samme spørsmålet Hubbards e-post stiller selskapene på listen hennes.

#Hva du bør gjøre med WordPress-nettstedet etter 7.1.3

E-posten fra Hubbard endrer ingenting på nettstedet ditt over natten. Tallene fra HackerOne og listen fra 7.1.3 gir likevel noen konkrete konsekvenser:

1. Installer 7.1.3 hvis du ikke har gjort det ennå. Kunngjøringen anbefaler oppdatering umiddelbart. Sjekk i Dashbord, Oppdateringer at nettstedet faktisk har 7.1.3, også om du har automatiske oppdateringer slått på.
2. Eldre grener får rettelsene senere. Ifølge Patchstack havnet rettelsene på utgivelsesdagen i grener fra 6.6 og opp, mens grenene fra 4.7 til 6.5 fortsatt ventet på dem. Et nettsted på 7.1 var beskyttet fra første dag.
3. Tøm cachen etter oppdateringen. Patchstack advarer om at 7.1.3 ikke fjerner oEmbed-innbygginger som allerede er lagret i databasen, så en ondsinnet Imgur-innbygging som ble lagt til tidligere, vises fortsatt til du tømmer cachen.
4. Gå gjennom brukerrollene. Patchstack anbefaler det direkte, fordi tre av de sju hullene krever en Bidragsyter- eller Forfatter-konto. Kontoer til tidligere forfattere og byråer som for lenge siden er ferdige med jobben, bør slettes eller få lavere rettigheter.
5. Kjernen er ikke alt. Core Security Initiative omfatter ikke plugins. Har du ikke gått gjennom pluginene dine på lenge, start med revisjon av utdaterte plugins og kjente CVE-er.
6. Det kan komme flere sikkerhetsutgivelser. Hubbard skriver at tempoet i rapporteringen fortsatt øker. Oppdaterer du bare én gang i kvartalet, kan du gå glipp av flere utgivelser på rad. Med fast vedlikehold av WordPress-nettsiden testes oppdateringene på en kopi og rulles ut i løpet av dager, ikke måneder.

Vil du sjekke hvilken stand nettstedet ditt er i nå, start med en sikkerhetsrevisjon av WordPress.

#Når selskapene må forplikte seg til finansiering

Hubbard tilbød interesserte selskaper detaljerte programdata og skrev at hun vil ha “en første gruppe bidragsytere som står sammen med oss dette kvartalet” (egen oversettelse), altså innen utgangen av desember 2026. Foreløpig har ikke noe selskap offentliggjort et konkret beløp. Jeg legger til en oppdatering når noen gjør det.

#Anbefalt oppdateringstakt etter WordPress 7.1.3 og kostnader i vedlikeholdsavtaler. Oppdatering 10.10.2026

Per 10. oktober 2026 fant jeg ingen offentlig forpliktelse fra noen av selskapene på listen, så finansieringsbildet over står. Risikobildet lar seg derimot presisere. Patchstack vurderer 7.1.3 slik:

“Oppdater så snart du kan, men dette er ikke en nødsituasjon der du må legge alt annet til side.”

Patchstack, WordPress 7.1.3 security release, 6. oktober 2026, egen oversettelse

En av de sju rettelsene virker uten konto og uten at offeret gjør noe, og Anthropic meldte tre. For en nettstedseier betyr det en rytme: kjerne-patch i løpet av dager, etter test på en kopi, ikke neste kvartal.

Pengene Hubbard ber om dekker premier og triage i kjernen. Arbeidet på ditt eget nettsted (testing, utrulling, kontroll av utvidelser) er en egen kostnad som avtalen må nevne. Spør den som tar seg av vedlikehold av nettsiden om tre ting: hvor mange dager etter en sikkerhetsutgivelse kjerneoppdateringen rulles ut, om den testes på staging, og om en utgivelse utenfor vanlig syklus er med i abonnementet.

Sist oppdatert: 13. oktober 2026.