Innledning
WordPress.org holder nå igjen hver ny programtilleggsutgivelse i inntil seks timer før den når auto-oppdateringene. Patchstack måler medianen for tiden fra en sårbarhet offentliggjøres til den utnyttes i stor skala til fem timer. Begge tallene har ligget offentlig tilgjengelig siden juli, og ingen har lagt dem ved siden av hverandre.
Kort sagt
- Seks timer er dagens ventetid for en utgivelse av programtillegg eller tema under initiativet Protect the Shire. Det startet 5. juni 2026 på inntil 24 timer og ble kuttet til seks før 18. juli 2026.
- Fem timer er medianen for tid til masseutnyttelse av en sårbarhet med høy konsekvens, ifølge Patchstack, State of WordPress Security in 2026 fra 25. februar 2026.
- 46 prosent av sårbarhetene mangler fiks når de offentliggjøres. Tallet er fra samme rapport og endrer betydningen av de to første.
- Om en sikkerhetsfiks er unntatt fra ventetiden, står ingen steder. Kunngjøringen omtaler hver ny utgivelse og skiller ikke.
- Kuttet til seks timer ble kunngjort bare på Slack. Utviklere oppdaget det da de ga ut.
- 11 334 nye sårbarheter i økosystemet i 2025, 42 prosent flere enn året før, og de lett utnyttbare steg 113 prosent.
- 12 prosent av kjente WordPress-angrep stoppes av vanlige oppsett med hosting og WAF. Det tallet beskjærer rådet jeg selv gir lenger nede.
Hvor ventetiden kom fra
I april 2026 ble trettien programtillegg fra ett og samme merke trukket fra katalogen samtidig. Alle hadde en bakdør. Ingenting ble brutt opp: noen kjøpte programtilleggene på Flippa, arvet SVN-tilgangen med dem og dyttet ut én ondsinnet oppdatering forkledd som en kompatibilitetsfiks for WordPress 6.8.2.
Det er verdt å dele angrepet opp i trinn, for hvert enkelt er lovlig alene, og først samlet utgjør de et innbrudd. Å kjøpe et programtillegg på en markedsplass er lovlig. Å arve repository-kontoen med det er innenfor reglene, for slik ser et eierskifte ut. Å publisere en oppdatering er en utvikleres normale handling. Å merke den som en kompatibilitetsfiks for en bestemt WordPress-utgivelse er troverdig, for slike fikser kom faktisk ut på den tiden. Rekkevidden ble oppgitt til opptil 400 000 nettsteder.
Ingen ledd i kjeden ser mistenkelig ut alene, og det er hele poenget. En kontroll basert på hvem som publiserer koden hadde ingenting å oppdage, for den ble publisert av den rettmessige eieren. Det eneste som kunne oppdages, var hva som lå inni.
Dette er et leverandørkjedeangrep i sin reneste form, og katalogen hadde ikke noe svar på det, fordi hele tillitsmodellen hvilte på at den som har commit-tilgang, er den han utgir seg for. Protect the Shire svarer på nettopp dette scenariet. Mellom commit og distribusjon settes det inn et vindu der en automatisk gjennomgang og et menneske kan se på det som straks går ut til millioner av installasjoner.
Som svar på det angrepet gir ventetiden mening, og det vil jeg si rett ut før jeg kommer til innvendingen. Seks timer mellom en ondsinnet commit og auto-oppdateringen er seks timer som ikke fantes før.
Der de seks timene slutter å hjelpe
Ventetiden er nøytral overfor innholdet i en utgivelse. Den vet ikke om det ligger en ny funksjon, en skrivefeilretting eller en fiks for en sårbarhet under aktiv utnyttelse inni. Kunngjøringen fra 5. juni omtaler hver ny utgivelse og skiller ikke. Jeg fant heller ingen kilde som beskriver en hurtigvei for sikkerhetsutgivelser.
Jeg vil være presis her, for det er her det er lett å skrive noe usant. Jeg påstår ikke at det ikke finnes en hurtigvei. Jeg påstår noe svakere og etterprøvbart: den er ikke dokumentert der en utvikler ville lete, altså i kunngjøringen og i de offentlige innleggene som fulgte. For en utvikler som nettopp har fått en sårbarhetsrapport og forbereder en hasteutgivelse, er en udokumentert vei i praksis det samme som ingen vei.
Og der lander det andre tallet. Patchstack setter medianen for tid til masseutnyttelse av en sårbarhet med høy konsekvens til fem timer etter offentliggjøring. Median, ikke gjennomsnitt, så halvparten av tilfellene går raskere.
Å sette de to tallene ved siden av hverandre krever varsomhet, for de måler ulike ting. Seks timer er en forsinkelse i distribusjonen av en oppdatering. Fem timer er tiden fra offentliggjøring til angrep i stor skala. De overlapper ikke perfekt, og jeg påstår ikke at hver fiks kommer en time for sent. Jeg påstår at katalogens beskyttelsesvindu er i samme størrelsesorden som angrepsvinduet, og ved det forholdet er det ikke lenger gratis å buffre en utgivelse.
Tallet som endrer de to andre
Samme Patchstack-rapport oppgir at 46 prosent av sårbarhetene manglet en fiks da de ble offentliggjort.
Det tallet flytter hele diskusjonen. I nesten halvparten av tilfellene er det ingenting å holde igjen, for det finnes ennå ingen utgivelse. Ventetiden koster ingenting der, men gir heller ingenting, og det eneste som beskytter et nettsted, er et lag som ikke venter på katalogen: en WAF-regel, en avskrudd funksjon, et deaktivert programtillegg.
I praksis betyr det at debatten om seks timer gjelder litt over halvparten av tilfellene. For resten er spørsmålet et helt annet, og katalogen er ikke part i det.
Skalaen som gjør seks timer viktige
Seks timer høres ufarlig ut helt til man setter det opp mot antallet hendelser som passerer gjennom vinduet.
Patchstack talte 11 334 nye sårbarheter i WordPress-økosystemet i 2025, 42 prosent flere enn året før. Det er mer enn tretti om dagen i snitt. Økende volum alene ville vært til å leve med hvis det økte jevnt, men det gjør det ikke: sårbarheter klassifisert som lett utnyttbare steg 113 prosent fra år til år, altså mer enn en dobling.
Sammen endrer de to tallene problemets karakter. Det er ikke bare flere hull. Det er den delen som kan utnyttes uten innsats som vokser raskest, altså i stor skala og maskinelt. Med den profilen er en median på fem timer til masseutnyttelse ikke lenger en statistisk kuriositet, men beskrivelsen av en vanlig dag.
I det lyset er en ventetid i katalogen en av de få spakene som i det hele tatt virker i skala. En automatisk gjennomgang som ser på hver utgivelse, skalerer bedre enn enhver prosess som avhenger av at en utvikler eller en administrator rekker å reagere. Derfor mener jeg retningen er riktig, og striden gjelder bare om vinduet skal forbli blindt for hva en utgivelse inneholder.
En korreksjon av mitt eget råd
Jeg skrev over at du bør bygge et lag som ikke venter på katalogen, og pekte på en WAF-regel. Samme Patchstack-rapport inneholder et tall som beskjærer det rådet kraftig, og jeg kommer ikke til å begrave det.
I penetrasjonstester blokkerte vanlige oppsett av hosting og WAF 12 prosent av kjente, aktivt utnyttede WordPress-spesifikke angrep, og 26 prosent av et bredere testsett. Åtte av ti reelle angrep går rett gjennom det de fleste byråer regner som sitt beskyttelseslag.
Skillet som redder rådet, er konkret og fortjener å bli navngitt. En generisk WAF hos hostingleverandøren filtrerer generiske mønstre, klumsete SQL-injeksjonsforsøk og stiskanninger. En sårbarhet i et konkret programtillegg ser sjelden ut som et generisk angrep. Den ser ut som en gyldig forespørsel til et gyldig endepunkt med én parameter satt slik utvikleren ikke forutså. En generisk regel ser ikke det.
En regel skrevet mot en konkret, offentliggjort CVE er noe annet, det bransjen kaller virtuell patching. Den trenger ikke forstå en angrepsklasse, den trenger bare signaturen til dette ene tilfellet. Det er laget jeg mente, og jeg vil være presis: poenget er ikke å eie en WAF, men å ha en prosess for å legge inn en regel innen timer etter offentliggjøring. Å bare ha en WAF er mindre verdt enn det vanligvis antas.
Her hører et ærlig forbehold om kilden med. Patchstack selger virtuell patching, så et tall som får generiske WAF-er til å se svake ut, passer selskapet godt. Det gjør det ikke usant, og metodikken er beskrevet i rapporten som penetrasjonstesting mot et kjent sett av exploits. Det betyr bare at tallet bør leses med kunnskap om hvem som publiserer det. Jeg nevner det så ingen må finne det ut selv.
Utviklerens side, som er halve problemet
Så langt har jeg skrevet fra posisjonen til den som drifter andres nettsteder. En programtilleggsutvikler har det samme problemet omvendt, og hans versjon er hardere, for det er han som sitter mot klokka.
Scenariet er slik. Du får en sårbarhetsrapport, som regel gjennom et bug bounty-program eller direkte fra en forsker. Dere avtaler en offentliggjøringsdato, du forbereder fiksen, tester, gir ut versjonen. Fram til juni 2026 var det minutter mellom commit og distribusjon. Nå er det inntil seks timer, og det finnes ingen offentlig dokumentert måte å korte det ned på.
Den praktiske konsekvensen er at datoen avtalt med forskeren trenger slakk. Avtaler du offentliggjøring mandag klokka ni, må utgivelsen ut søndag kveld, ikke mandag klokka åtte. Mot en median på fem timer til masseutnyttelse er den timen reell.
Den andre konsekvensen gjelder vakt. Utvikleren Lopo sa det kortest: å oppdage først etter utgivelsen at vaktene måtte legges om for å følge utrullingen. Gir du ut et programtillegg med en halv million installasjoner, må noen følge med på meldinger i de timene oppdateringen faktisk sprer seg. Med et vindu som flytter seg og ikke kunngjøres offentlig, lar det seg ikke planlegge.
Den tredje er mer subtil. Ventetiden endrer hva et versjonsnummer betyr. Til nå betydde det å dytte ut 2.4.1 at 2.4.1 var i omløp. Nå betyr det at den kommer til å være det, og i mellomtiden er 2.4.0 i omløp, altså den sårbare versjonen som allerede er offentlig kjent som sårbar. Utgivelsesnotatene må ta høyde for det, ellers er “rettet i 2.4.1” sant og villedende på samme tid.
Gandalf, eller tillit flyttet, ikke fjernet
Ventetiden kontrollerer ingenting i seg selv. Det som teller, er hva som skjer i løpet av den, og i kunngjøringen tilfaller den rollen en automatisk gjennomgang kalt Gandalf.
Det er verdt å merke seg hva som faktisk endret seg i tillitsmodellen. Fram til april stolte katalogen på den som hadde SVN-tilgang. Etter april er det kjent at slik tilgang av og til kjøpes sammen med programtillegget, så tilliten ble tatt bort derfra. Den ble ikke avskaffet, den ble flyttet over på en automatisk gjennomgang som vurderer innholdet i en utgivelse.
Det er den bedre løsningen, og det sier jeg rett ut, for en automatisk gjennomgang kan ikke kjøpes på Flippa. Men den reiser to nye spørsmål som det offentlige materialet ikke besvarer.
Det første gjelder feil i motsatt retning. En skanner som slipper gjennom en ondsinnet utgivelse, er det åpenbare problemet. En skanner som blokkerer en legitim utgivelse, er det stillere og for utvikleren mer smertefulle, for det er uklart hvem man klager til og hvor lang tid det tar. Jeg fant ingen beskrivelse av en klageordning.
Det andre gjelder hvor lang tid selve skanningen tar. Tar den tjue minutter, er seks timers-vinduet nittifem prosent buffer og ikke arbeid, og forslaget om å hoppe over ventetiden ved rent resultat løser i praksis hele problemet. Tar den fem timer, er det motsatt. Det ene tallet endrer konklusjonen, og det er ikke publisert.
Slack er ingen kunngjøringskanal
Kuttet fra 24 til seks timer kom uten et offentlig innlegg. Ajay D’Souza fant det da han ga ut et programtillegg før 18. juli 2026. Enrico Battocchi spurte direkte hvordan de skulle få vite om slike endringer og om det ville komme et innlegg. En utvikler ved navn Lopo beskrev den driftsmessige kostnaden.
Dette er et problem atskilt fra selve ventetiden, og etter min mening det alvorligste. En utvikler planlegger en hasteutgivelse rundt en kjent forsinkelse. Endrer forsinkelsen seg uten varsel, brytes planleggingen begge veier. Noen ganger venter du lenger enn budsjettert, andre ganger går det ut tidligere og ingen følger utrullingen.
Det finnes et utkast til å hoppe over ventetiden når Gandalf-skanningen ikke finner noe. Versjonen som ble skannet, slutter da å vente og begynner å bli levert. Det ville løst mesteparten av problemet, for en ren skanning er det overveldende flertallet av utgivelser. Forslaget er til vurdering og er ikke innført.
Hva du gjør på nettstedssiden
Drifter du kundenettsteder, er ventetiden i katalogen en variabel du ikke rår over. Fire andre rår du over.
Ikke slå av auto-oppdateringer som reaksjon på denne endringen. Det er den vanlige refleksen og det motsatte av det tallene støtter. Ventetiden koster timer. Manuell klikking koster dager, og over seks språk og dusinvis av nettsteder koster den uker. Siden halvparten av de kritiske feilene utnyttes det første døgnet, er din egen reaksjonstid den større risikoen.
Det hjelper å se på regnestykket. Ventetiden legger på høyst seks timer. Manuell oppdatering én gang i uka gir et snitt på rundt åttifire timers forsinkelse, fjorten ganger mer. Selv daglig manuell oppdatering gir tolv timer i snitt, fortsatt det dobbelte av katalogvinduet. Den som argumenterer med at ventetiden er for risikabel og derfor går over til manuelt, bytter seks timer mot flere dusin.
Bygg prosessen for å legge inn en regel, ikke bare WAF-en. Etter korreksjonen over leses dette rådet annerledes enn vanlig. Å eie en WAF hos hostingleverandøren stopper tolv prosent av kjente WordPress-angrep, ifølge Patchstacks testing. Verdien ligger i å kunne legge inn en regel for en konkret, nettopp offentliggjort CVE innen timer. Det er forskjellen på et produkt og en prosedyre, og her er det prosedyren som avgjør.
Ha en liste per kunde over forretningskritiske programtillegg, og vit hvilket som kan slås av i en time. Å deaktivere et skjemaprogramtillegg til fiksen kommer, er billig. Å deaktivere en betalingsløsning er det ikke. Det skillet hører hjemme i et dokument skrevet før hendelsen, ikke under. I praksis er det én kolonne i et regneark, fylt ut én gang ved oppstart.
Vit hvor du får høre om en sårbarhet før du hører det fra overvåkingen. Informasjonskanalen teller like mye som det tekniske laget her, for mot en median på fem timer er forskjellen mellom morgen og kveld forskjellen mellom en fiks og en hendelse. En sårbarhetsstrøm lest daglig er billigere enn ethvert verktøy, og den setter taket for hvor raskt du i det hele tatt kan reagere.
Hva denne endringen ikke løser
Det er verdt å si klart hva ventetiden ikke berører, for den er lett å overvurdere.
Den berører ikke programtillegg utenfor katalogen. Et premium-programtillegg kjøpt direkte fra utvikleren eller på en markedsplass oppdateres gjennom sin egen kanal, og ingen ventetid omfatter det. En typisk WooCommerce-butikk kjører flere slike, ofte de mest følsomme, for de rører ved betaling, frakt og kundedata.
Den berører heller ikke temaer og programtillegg installert manuelt fra en ZIP-fil, eller kode i kundens eget funksjonsprogramtillegg. Og det er nettopp der gjelden vanligvis ligger, i kode skrevet i forbifarten og ikke rørt på flere år.
Til slutt berører den ikke tilfellet der koden ikke er problemet i det hele tatt, men konfigurasjonen: for vide rettigheter, en administratorkonto uten andre faktor, en API-nøkkel i et repository. Katalogen har ingen rolle der, og andelen slike tilfeller blant reelle hendelser er høy.
Hva jeg ikke vet
Tre ting står åpne, fordi jeg ikke har kilde på dem og ikke akter å gjette.
Jeg vet ikke om sikkerhetsutgivelser har en hurtigvei som ikke er offentlig dokumentert. Jeg vet ikke hvor lang tid en full Gandalf-skanning faktisk tar, så jeg vet ikke hvor mye av de seks timene som er arbeid og hvor mye som er buffer. Jeg vet ikke når, eller om, forslaget om å hoppe over ventetiden ved ren skanning blir innført.
Blir noe av dette dokumentert offentlig, oppdaterer jeg dette innlegget og daterer endringen.
Kilder
- Protect The Shire, WordPress News, 5. juni 2026
- Patchstack, State of WordPress Security in 2026, 25. februar 2026
- Kuttet til seks timer og reaksjonen fra utviklerne
Sist verifisert: 10. august 2026.
