Automatiska uppdateringar eller vänta? Vad de kapade pluginen faktiskt visar

Sedan den 5 juni 2026 håller WordPress.org tillbaka nya plugin- och temasläpp innan de distribueras via uppdateringssystemet, i dag i 6 timmar. Sedan den 9 september granskas dessutom varje släpp under pausen och blockeras automatiskt om det bedöms som en säkerhetsrisk. Frågan som miljontals sajtägare grubblat över i flera år, uppdatera direkt eller vänta några dagar, har alltså delvis fått ett svar från plattformen själv. Men fem dokumenterade kapningar under 2026 visar var skyddet räcker och var det inte gör det.

Det mest talande fallet i registret längre ner är inte det mest dramatiska. Det är det enda där en fördröjning på några timmar faktiskt hade räddat sajten, och just den attacken gick genom en kanal spärren inte täcker. Tre av fem attacker under 2026 gick helt utanför WordPress.org, och i två av dem var gratisversionen uttryckligen oskadd medan det var betalversionen som bar bakdörren.

Vad Protect The Shire faktiskt ändrar

Initiativet heter Protect The Shire och beskrevs av WordPress-grundaren Matt Mullenweg i ett tillkännagivande på wordpress.org den 5 juni 2026. I korthet innebär det en tillfällig fördröjd distribution av uppdateringar (på engelska cooldown) för plugin- och temasläpp, innan de går ut via auto-uppdateringar. Utgångsläget var 24 timmar. Före ändringen distribuerades varje släpp omedelbart, "as soon as a developer presses the button", skrev Mullenweg.

Skalan förklarar varför manuell granskning inte räcker. Katalogerna innehåller över 78 000 plugins och teman, sammanlagt över 400 miljoner installationer, och under ett enda dygn kommer det in mer än 3 000 commits till plugin-katalogen. Mullenweg är tydlig med att lösningen är provisorisk. Han skriver "temporary" och räknar med att 24 timmar kan kortas ner till minuter. Spärren ska alltså inte läsas som ett permanent tillstånd utan som ett första steg, och den har mycket riktigt rört sig sedan dess. I september 2026 uppger plugin-teamet att fördröjningen ligger på 6 timmar.

Den 9 september tog teamet dessutom steget från paus till granskning, i ett inlägg om automatiserad säkerhetsgranskning av plugin-släpp. Under fördröjningen analyseras ändringarna i varje släpp av flera AI-modeller tillsammans med Jetpack Scan, resultaten korsvalideras och vägs ihop till en riskpoäng. Får ett släpp hög poäng stoppas distributionen automatiskt så snart granskningen är klar, och alla med skrivrättigheter till pluginen får ett mejl om vad som utlöste stoppet. Poängen mäter dock risk och inte uppsåt, så en oavsiktligt införd sårbarhet kan slå lika högt som medveten skadekod, och falska positiva förekommer trots att korsvalideringen håller dem nere. Det är den delen som skiljer dagens spärr från junis. Då väntade plattformen, nu tittar den också på vad den håller tillbaka.

Han formulerar också själva dilemmat i orden "We're in a liminal period now, and I believe 2026 will be a year of tension between two approaches: updating as quickly as possible to stay secure, and holding back on updating to stay secure." Frågan han ställer, hur man balanserar säkerhetsuppdateringar mot att säkra själva uppdateringarna, är precis den frågan artikeln försöker besvara utifrån fem faktiska fall. Mullenweg bekräftar själv en av orsakerna till initiativet, incidenten med Essential Plugins där "good plugins were unknowingly sold to a new author who had malicious intent".

Fördröjningen gäller mer än auto-uppdateringar

Mullenwegs inlägg formulerade spärren kring auto-uppdateringar, men den visade sig omfatta mer. Enligt branschpublikationen The Repository flaggade Rebecca Markowitz, Developer Outreach Manager på Elementor, i kanalen #pluginreview på WordPress Slack att en ny version inte syntes på sajter tre timmar efter släpp. Samuel "Otto" Wood, bidragsgivare sponsrad av Audrey Capital, bekräftade orsaken ordagrant. "It means an update shown through the update system are delayed 24 hours, that is both manual and automatic." WordPress.org talar bara om för sajten att en uppdatering finns. Det kontrollerar inte om sajten installerar den manuellt eller automatiskt.

I praktiken sitter fördröjningen i vad WordPress.org rapporterar till din sajt. Ser sajten ingen uppdatering, går det inte heller att klicka fram den för hand. Det som inte fördröjs är att ladda ner zip-filen direkt och installera manuellt, samt att koden och changeloggen publiceras offentligt lika snabbt som förut.

Priset för skyddet

Den 17 juni tog Miriam Schwab, Head of WordPress på Elementor (14 plugins, sammanlagt över 10 miljoner aktiva installationer), upp en invändning i samma Slack-kanal, värd att ta på allvar. Hennes poäng är att när en utvecklare släpper en säkerhetsfix publiceras koden och changeloggen på WordPress.org omedelbart, synligt för vem som helst som skannar efter nyss patchade sårbarheter, medan uppdateringen inte når sajterna förrän fördröjningen löpt ut. Fördröjningen skapar alltså ett sårbarhetsfönster i motsatt riktning mot det den ska stänga. Det är inte en bisak. Invändningen väger mindre i dag än när den restes, eftersom fönstret krympt från ett dygn till 6 timmar, men den gäller fortfarande. Den är kärnan i varför Mullenweg kallar lösningen tillfällig snarare än färdig.

Fem kapningar, samma fråga

Så till registret. Vi ställer fem verifierade kapningar under 2026 mot en enda fråga. Hade en fördröjning via WordPress.org räckt för att skydda sajten? Fallen inträffade medan fönstret var ett dygn, så tabellen prövar dem mot 24 timmar. Där dagens 6 timmar ger ett annat svar säger vi det. Jämför med vad vi tidigare skrivit om vanliga plugin-sårbarheter, en bugg i koden. Fallen nedan är av allvarligare sort, en kapad leveranskedja (på engelska supply chain attack), där själva distributionskanalen manipuleras.

Awesome Motive och ShapedPlugin har vi skrivit om tidigare. Ingen hade stoppats av spärren, eftersom ingen gick via WordPress.org.

Det enda fallet där tid faktiskt hade räckt

Smart Slider 3 Pro är fallet som verkligen skiljer ut sig. Bakdörren i version 3.5.1.35 distribuerades genom Nextends egen uppdateringsinfrastruktur, inte via WordPress.org, och upptäcktes efter ungefär sex timmar. Patchstack, som gjorde malware-analysen, slår fast att endast Pro-versionen var påverkad. Gratisversionen i WordPress.org-katalogen var aldrig komprometterad. Säker version blev 3.5.1.36, sårbarheten registrerades som CVE-2026-34424, och Smart Slider 3 har över 800 000 aktiva installationer sammanlagt.

Sex timmar rymdes med bred marginal inom det dygn som gällde då. Mot dagens 6-timmarsfönster hade det i stället blivit en kapplöpning, vilket visar att en kortare paus också ger mindre tid att hinna upptäcka något. Men den kanalen, en betalversion som uppdateras direkt från leverantörens servrar, ligger utanför det WordPress.org kan skydda. Det är precis hålet som gör initiativet ofullständigt för alla som kör premium-plugins.

En bakdörr byggd för att smälta in

Det senaste fallet, Advanced Responsive Video Embedder (ARVE) version 10.8.7, gick faktiskt via WordPress.org. Ett enda HTTP-anrop med en hårdkodad token gav full adminsession, och filen var döpt för att smälta in som en rutinmässig uppdateringskontroll. Bakdörren infördes 08:42 EST den 28 juli, Wordfences analysagent PRISM identifierade den redan 10:33 EST, och WordPress.org stängde pluginen 11:09 EST. Cirka 20 000 sajter körde pluginen. Sårbarheten fick beteckningen CVE-2026-18072 med CVSS-poäng 9.8.

Wordfence rapporterar att WordPress.org bekräftat att släppet ännu inte hunnit distribueras när det stängdes ner, så sajter ska inte automatiskt ha hämtat den skadliga versionen. När vi först skrev det här kunde vi inte säga om spärren var orsaken eller om förloppet bara råkade rymmas inom fönstret. Den frågan har plugin-teamet sedan besvarat själva. I inlägget om automatgranskningen beskriver de ett släpp den 28 juli där en bakdörr committades till ett plugin med omkring 20 000 aktiva installationer, och skriver att den automatiska granskningen upptäckte den och satte hög riskpoäng, och att den komprometterade versionen aldrig distribuerades eftersom släppet fortfarande låg inne i fördröjningen. De namnger inte pluginet, men datum, storleksordning och förlopp sammanfaller med ARVE-fallet. Spärren gjorde alltså jobbet här, och den gjorde det innan någon människa hann ingripa. Utvecklaren bakom ARVE bör ses som ett sannolikt offer snarare än ansvarig, mest troligt genom att någon fick åtkomst till kontot.

Bakdörren avslöjar också något om vem som ligger bakom den. Den väljer ett administratörskonto att låtsas vara, men hoppar medvetet över konton vars namn börjar med wpsvc_, developer_, dev_ eller wp_update_, ett mönster som antyder att den bakom själv planterar adminkonton med de prefixen. I junivågen dokumenterade vi konton med namn som developer_api1 och dev_ följt av tecken. Vi kan inte säga om det är samma aktörer, men det är ett överlapp värt att kolla i din egen användarlista.

Var ansvaret faktiskt ligger nu

För en svensk WooCommerce-butik eller en byråkund med en handfull sajter är det sällan WordPress.org-plugins som är den ömma punkten. En sådan sajt kör nästan alltid några premium-plugins, en bildspelsplugin, ett formulärverktyg, en fraktintegration, kanske en betallösning, och det är exakt den profilen som ligger i räckviddshålet spärren lämnar öppet. Slutsatsen är tydlig. Din egen fördröjningspolicy bör flytta från WordPress.org-pluginen, där plattformen numera sköter granskningspausen åt dig, till premium-pluginen, där ingen gör det.

• Låt auto-uppdatering vara påslagen för plugins från WordPress.org. Argumentet "vänta ett par dagar själv" har flyttat dit, och sedan september gör plattformen mer än att vänta. Den granskar också det den håller tillbaka.
• Egen fördröjning, staging och manuell kontroll hör hemma på premium-plugins som uppdateras från leverantörens egna servrar, precis den kanal Smart Slider-fallet gick genom.
• Backup som räcker bakåt i tiden gäller oavsett kanal. Rådet "rulla tillbaka till före den skadliga versionen" är värdelöst om kopian redan är borta. Kontrollera hur långt tillbaka ditt webbhotells backup faktiskt sparas.
• Gör det till en vana att gå igenom administratörskontona då och då och leta efter namn som inte hör hemma där.

På managed WordPress-hosting ligger uppdateringspolicyn ofta hos webbhotellet snarare än hos dig själv. Se vår genomgång av webbhotell för WordPress. Vi har inte belagt att någon enskild svensk värd hanterar just den här spärren på ett visst sätt, så håll resonemanget generellt.

Ett kort ord om GDPR också, eftersom ARVE-bakdörren i smyg skickade sajtens adress och ett administratörsnamn till en server angriparen kontrollerade. Ett konstaterat intrång av den typen räknas som en personuppgiftsincident, och då gäller anmälan till Integritetsskyddsmyndigheten inom 72 timmar, oavsett hur liten sajten är.

Vi skrev själva i vår genomgång av junivågen att det kunde vara rimligt att låta uppdateringar ligga ett par dagar innan man installerade dem. Det rådet behöver nyanseras nu. Fördröjningen sköts till stor del av plattformen för WordPress.org-plugins, medan frågan som faktiskt avgör om du blir träffad, vilken kanal pluginen uppdateras genom, sällan syns förrän det redan hänt. Under hela resonemanget ligger en generell observation från drift. "Vänta med uppdateringar" har en tendens att glida över i "aldrig uppdatera" på sajter där ingen tydligt äger ansvaret. Misstänker du att din sajt redan är drabbad, finns vår genomgång av sanering efter en hackad WordPress-sajt.