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 i upp till 24 timmar innan de distribueras via uppdateringssystemet. 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) på 24 timmar för plugin- och temasläpp, innan de går ut via auto-uppdateringar. 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.

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 efter upp till 24 timmar. Fördröjningen skapar alltså ett sårbarhetsfönster i motsatt riktning mot det den ska stänga. Det är inte en bisak. Det ä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 på upp till 24 timmar via WordPress.org räckt för att skydda sajten? 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 24-timmarsspä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 hade rymts med bred marginal inom ett 24-timmarsfönster. 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. Det är inte samma sak som att 24-timmarsspärren orsakade utfallet. Vi vet bara att hela förloppet, från infektion till nedstängning, rymdes inom knappt två och en halv timme, gott och väl inom fönstret som gäller sedan 5 juni. 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, plattformen gör redan det jobbet.
• 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.