På tretti dager, mellom tidlig april og starten av mai 2026, stengte WordPress.org-plugin-katalogen minst seks plugins av leverandørkjedeårsaker. Fire av avsløringene kom fra én uavhengig forsker, Austin Ginder fra Anchor Hosting. Én kom fra en fem år gammel skjult oppdateringsserver som stille hadde distribuert modifiserte versjoner av en plugin med over 70 000 aktive installasjoner. Én eksplosjonsradius dekket en hel plugin-butikk med over 80 plugins på .org. Plugins Team-co-rep Francisco Torres fortalte The Repository at Ginder “is doing an excellent job investigating these issues, correlating events, and drawing conclusions from them.”
Les sitatet en gang til. Teamet som driver WordPress-plugin-katalogen takker offentlig grunnleggeren av et enkelt hostingselskap for arbeid katalogen selv ikke gjør i denne skalaen. Det er WordPress plugin-leverandørkjeden i mai 2026, og hvis du driver en stack som må klare NIS2 Article 21 leverandørkjedekontroller eller DORA Article 28 tredjepartsavhengighetskartlegging, er det sitatet ditt problem.
Dette innlegget er bevisst meningsbærende. Faktaene er offentlige, avsløringene er lenket, og konklusjonene er mine.
Hva som faktisk skjedde i april 2026
Austin Ginder avdekket fire separate plugin-kompromitteringer i april. Den siste skrev han opp 30. april, og Plugins Team bekreftet analysen og stengte Scroll To Top-pluginen kort etterpå. Torres fortalte The Repository at Ginders oppsummering var “essentially what happened” og krediterte arbeidet for å ha “having a positive impact on the ecosystem’s security.” Ved siden av den fjerde avsløringen forhåndsviste Ginder et nytt verktøy, WP Beacon, designet for å spore potensielle sikkerhetstrusler i .org-katalogen. Torres sa at Plugins Team jobbet med “something similar.”
Parallelt rapporterte The Repository om stengningen av Quick Page Post Redirect, en plugin med over 70 000 aktive installasjoner, etter at det kom frem at forfatteren hadde drevet en skjult oppdateringsserver i omtrent fem år. Poenget med den skjulte serveren var å sende ut versjoner som ikke gikk gjennom WordPress.orgs gjennomgangspipeline. Fem år.
I samme nyhetsbølge stengte Plugins Team midlertidig over 80 WPFactory-plugins etter at en bruker rapporterte en mistenkt bakdør i premium-versjonen av EU/UK VAT for WooCommerce. WPFactorys første reaksjon var, ifølge WP-CONTENT.CO, å antyde at brukerens miljø var kompromittert. Managing Partner Pablo Pacheco erkjente senere problemet og beklaget det forsinkede svaret. WPFactorys plugin-katalog har over 170 000 aktive installasjoner i katalogen.
Det er overflateopptellingen. Ingen av disse kompromitteringene var en eksotisk null-dag i WordPress-kjernen. Hver eneste var en kompromittering på vedlikeholder- eller distribusjonssiden, som er lærebokens definisjon av et leverandørkjedeangrep.
Hvor .org-gjennomgangsprosessen faktisk slutter
Det er fristende å lese fire-på-én-måned-avsløringene som tegn på at noe har endret seg. Den ærlige lesningen er det motsatte. Ingenting ved katalogens strukturelle gjennomgangsprosess endret seg i april 2026. Det som endret seg, er at én uavhengig forsker begynte å se etter, og én journalist begynte å skrive.
Quick Page Post Redirect-saken er den reneste demonstrasjonen av det strukturelle hullet. En plugin-forfatter som bestemmer seg for å omgå .org-gjennomgangen, kan gjøre det med et privat oppdateringsendepunkt og noen kodelinjer. Når pluginen først er installert, bryr ikke WordPress-kjernen seg om hvor neste versjon kommer fra. Fem-års-deteksjonsforsinkelsen er ikke katalogens svikt i å gjøre jobben; det er katalogen uten innsikten til å gjøre den jobben i utgangspunktet. Dagens gjennomgangsprosess kontrollerer hva som lastes opp til .org-repoet på dag null. Den kontrollerer ikke hva brukere faktisk installerer på dag ett tusen åtte hundre og tjuefem.
Ginders WP Beacon er, etter hans egen beskrivelse, et forsøk på å legge til observerbarhet til det hullet utenfra. Plugins Teams parallelle verktøy, når det kommer, gjør noe lignende innenfra. Inntil begge er sendt og stabilisert, er hullet ditt, ikke deres.
Hva NIS2 og DORA faktisk krever her
Hvis du rådgir en omfattet virksomhet, er innrammingen i regulatorisk tekst utvetydig. NIS2 Article 21 nummer 2 bokstav d krever “supply chain security, including security related aspects concerning the relationships between each entity and its direct suppliers or service providers.” DORA Article 28 krever at finansforetak fører et register over “all contractual arrangements on the use of ICT services provided by ICT third party service providers” og anvender et risikoproporsjonalt due diligence-regime på disse avtalene.
En WordPress plugin-forfatter hvis kode kjører i din produksjonskritiske bane, er en tredjeparts IKT-tjenesteleverandør for DORAs formål. Om det er en enpersons åpen kildekode-vedlikeholder eller et 130-personers selskap som WPFactory, endrer ikke den klassifiseringen, fordi forskriften bryr seg om den operasjonelle avhengigheten, ikke om foretaksformen. Quick Page Post Redirect-saken viser hva som skjer når en omfattet virksomhet ikke har kartlagt den avhengigheten: pluginen oppdaterer seg stille, det regulatorvendte avhengighetsregisteret flagger ikke endringen, og det reviderbare sporet ender et sted i .org-katalogens stengningslogg.
For vesentlige og viktige virksomheter under NIS2 er det praktiske spørsmålet det samme med annet ordforråd. Article 21 tiltak “shall include at least” leverandørkjedebestemmelsene i bokstav d. Medlemsstatens gjennomføringslov og kompetent myndighets veiledning fyller ut hva “include at least” betyr i praksis, men hver gjennomføring vi har sett så langt, leser “supply chain” inkluderende, ikke smalt.
To ting følger av dette. For det første: plugin-listen din er ikke bare en administrativ bekvemmelighet; den er et regulatorisk artefakt. For det andre: revisjonssporet som beviser at du visste om stengningen innenfor regulatorens forventede vindu, er ikke et skjermbilde av WordPress-dashbordet, fordi dashbordet sier at pluginen er “ikke lenger tilgjengelig” uten å si hvorfor. Du trenger en ekstern feed.
Eksempel på avhengighetskartlegging som overlever et regulatortilsyn
En nyttig test for ethvert plugin-avhengighetsregister er om det svarer på fire spørsmål for hver aktive plugin i produksjon:
| Spørsmål | Hvordan et reviderbart svar ser ut |
|---|---|
| Hvem vedlikeholder den? | En navngitt juridisk eller fysisk person, med en verifiserbar kontaktvei utover .org-profilen |
| Hva pakker den med? | Listen over tredjepartsbiblioteker inne i pluginen, med låste versjoner |
| Hvordan oppdateres den? | Den eksakte mekanismen (WordPress.org, privat oppdateringsserver, Composer satis, speil) |
| Hva skjer ved stengning? | En forhåndsskrevet runbook med målt tid-til-fjerning |
Quick Page Post Redirect-saken stryker på spørsmål tre i fem år og på spørsmål fire på dag null. WPFactory-saken stryker på første spørsmål, fordi den første offentlige reaksjonen flyttet skylden til den rapporterende brukeren før vedlikeholderens egen gjennomgang tok igjen. De fire Ginder-avsløringene stryker samlet på spørsmål to, fordi laget med innpakkede avhengigheter i en typisk plugin er ugjennomsiktig for de fleste driftsteam.
Hvis avhengighetsregisteret ditt ikke består fire-spørsmåls-testen for hver plugin i produksjon, vil ikke leverandørkjedeangrepet som lander hos deg neste kvartal være en overraskelse. Det vil være et regulatortilsynsfunn.
Hva du faktisk kan gjøre denne uken
Det mellomlange arbeidet er å sette plugin-oppdateringer på samme grunnlag som applikasjonskode: låste versjoner i et manifest, Renovate eller Dependabot mot manifestet, versjoner sendt gjennom CI, automatisk rollback ved feilet røyktest. Det kortsiktige arbeidet får plass i en arbeidsuke.
Legg Patchstack og Wordfence Threat Intelligence-feeden i samme Slack- eller Teams-kanal teamet ditt bruker for CVE-varsler. Abonner på RSS-en for plugin-stengninger på WordPress.org slik at katalogens egne takedowns treffer kanalen før en kunde nevner dem. Revidere pluginene på siden som genererer mest omsetning, og fjern alle plugins der vedlikeholderprofilen ikke kan spores til en reell vedlikeholder på under fem minutter; hvis vedlikeholderen er et pseudonym uten organisatorisk støtte, er leverandørkjederisikoen strukturelt høyere enn funksjonell verdi nesten hver gang. Skriv stengnings-runbooken nå for pluginene som overlever det filteret. Quick Page Post Redirect-eksplosjonsradiusen var 70 000 nettsteder, og eksponeringsvinduene ble målt i år; forskjellen mellom operatørene som legger merke til det, og operatørene som ikke gjør det, er om noen skrev runbooken før e-posten kom fra Plugins Team.
For byråene og frilanserne som leser dette: avhengighetsregisteret er også en salgsartefakt. En kunde som kan vise NIS2-leverandørkjedekontrollene sine i et regneark i stedet for et skjermbilde av wp-admin-Plugins-siden, er en kunde som overlever neste bransjeomfattende kompromittering uten juridisk eksponering. Byrået som leverte regnearket, beholder den kunden.
Der Austin Ginder slutter og WordPress.org begynner
Den ubehagelige sannheten i Plugins Teams eget sitat er at arbeidet Ginder gjør akkurat nå, er arbeidet katalogen burde gjort institusjonelt. Teamet bekrefter dette. Torres’ formulering “we believe he’s doing a fantastic job that is having a positive impact on the ecosystem’s security” er sjenerøs, treffende og stille fordømmende. Et økosystem av denne størrelsen kan ikke gå på velviljen til en enkelt hosting-grunnlegger og en enkelt nyhetsbrevredaktør. WP Beacon, det parallelle interne verktøyet hos Plugins Team og Patchstacks eksisterende avsløringspipeline beveger seg alle i samme retning; helt til de møtes på midten og blir der, må hver omfattet virksomhet som kjører WordPress i produksjon, gjøre det institusjonelle arbeidet selv.
Det er ubehagelig i 2026 fordi resten av den regulerte programvareleverandørkjeden beveger seg i motsatt retning. SBOM-krav, signerte versjoner og reproduserbare bygg er nå minimumsforventningen i finansielle tjenester og kritisk infrastruktur, og WordPress-plugin-katalogen møter ennå ikke det minimumet. Å lukke gapet er ikke en svikt fra Plugins Team; det er et strukturelt misforhold mellom et åpent økosystem bygget rundt frivillige vedlikeholdere og et regulatorisk miljø som nå forventer at hver avhengighet i produksjon skal være reviderbar.
Den gode nyheten er at gapet kan lukkes fra din side uten å vente på at katalogen tar igjen. Behandle plugins som kode, lås dem, revidere vedlikeholderne, overvåk avsløringsstrømmene og skriv runbooken. De fire Ginder-avsløringene og den fem år gamle skjulte oppdateringsserveren er ikke spådommer; de er kvitteringer. Hvis du ikke har bygget avhengighetsregisteret ennå, er ikke neste kompromittering et spørsmål om hvis, det er et spørsmål om hvilken tirsdag morgen e-posten lander.
