Vad WordPress-hacket säger oss om plugin-säkerhet
- Vad gjorde hacket?
- Vad innebar det för webbplatsägarna?
- En klassisk supply chain-attack
- Är WordPress osäkert?
- Så minskar Statamic risken
- Vill du läsa mer?
En person vid namn "Kris" (med bakgrund inom SEO, crypto och online gambling) köpte ett företag på Flippa den 8 augusti 2025 som hette Essential Plugin. Det företaget hade utvecklat 31 plugins. Efter köpet planterade han en så kallat "bakdörr" i alla plugins. Fast han gjorde inget mer märkbart under cirka 8 månader innan bakdörren aktiverades i april 2026.
Vad gjorde hacket?
Det gav hackaren en total kontroll över webbplatsen och allt på servern, en så kallat full remote code execution (RCE).
Det som hände var att hacket gjorde det möjligt att mata in dold SEO-spam i webbplatsen, allt utan att webbplatsägaren märkte något – attacken var optimerad för att bara visa spam till Googlebot, inte för den som äger webbplatsen. Så ingen såg "reklamen" som den här attacken utförde.
Vad innebar det för webbplatsägarna?
Det "Kris" tjänade på här var att han utnyttjade användarens webbplats autenticitet för sin egna vinning. Han fick Googlebot att höja hans egna affiliate-länkar och dylikt. Därav hamnade han högre upp i Googles sök resultat utan att behöva göra någonting mer än att låta hacket jobba gör honom. Hade det här pågått under en längre tid så hade de hackade webbplatserna riskerat att få sämre ranking för att webbplatserna flaggades som spam. Helt utan vetskap om varför. WordPress stängde permanent ner alla 31 plugins när det upptäcktes, men den injicerade koden i wp-config.php sitter kvar och måste rensas manuellt av en utvecklare.
En klassisk supply chain-attack
Detta är ett klassiskt supply chain-attack som i det här fallet utnyttjar WordPress beroende av tredjeparts-plugins från olika utvecklare.
Är WordPress osäkert?
Det här betyder inte att WordPress är dåligt eller att alla WordPress-sidor blir hackade. Med en kunnig utvecklare, få installerade plugins och bra rutiner går det utmärkt. Men ribban för att hålla en WordPress-sida säker över tid är högre än många tror, och risken finns där, oavsett hur försiktig du är.
Så minskar Statamic risken
Jag vill säga att ingen kan undvika att bli utsatt av en supply chain-attack men med Statamic undviker du den risken nästan helt:
- Inget behov av flera plugins. De flesta funktioner du behöver finns redan inbyggt i Statamic.
- Statamic utvecklas av ett enda team, som är väldigt aktivt.
- Flat-file-arkitektur (ingen databas) bara det i sig eliminerar vanliga attacker som SQL injection.
- Byggt på det moderna och säkra PHP-ramverket Laravel.
- Mycket mindre attackyta och betydligt lägre risk för massinfektioner.
Ingen databas betyder ingen SQL injection är möjlig
När du använder Statamic kan en besökare inte utföra SQL injection via kontaktformulär eller andra email-formulär. Anledningen till det är enkelt, statamic lagrar inte någon data i en databas. Allt är lagras i filer (YAML-, Markdown- och PHP-filer).
Utan databas → inga SQL-frågor → SQL injection är tekniskt omöjligt.
Detta är en av de största skillnaderna jämfört med WordPress, där nästan alla formulärs-plugins (Contact Form 7, Gravity Forms, WPForms m.fl.) skriver sin data till en MySQL-databas och därmed kan vara sårbara om de inte är perfekt säkrade.
En marknad, en pakethanterare
En annan viktig aspekt är att kunder kan köpa plugins på ett antal olika webbplatser så som CodeCanyon, WordPress.org och PluginsForWordPress det gör marknaden väldigt fragmenterad för WordPress.
Det jag också tycker är lite besvärligt och osäkert är att när man köper eller laddar ned ett plugin till WordPress så är det en .zip fil. För mig som utvecklare ryggar jag tillbaka lite. Jag får ingen information om historiken om vad som har gjorts och ändrats i detta plugin (Är lite osäker om detta). Vilket medför att jag själv måste in och granska koden eller ta hjälp av AI för att hitta sårbarheter som kan finnas. Nu är jag väl väldigt kritisk och försiktig, men det är något jag lärt mig av den här branschen.
Till skillnad mot Statamic som använder sig av ett ställe där du köper addons. När du installerar det, vilket det bara är jag som utvecklare kan göra, så gör jag det via composer, som är PHP:s egna pakethanterare. Och på köpet så kan jag även se historiken av dessa plugins genom versionshistoriken i git. Jag känner att jag har mer kontroll över vad som faktiskt installeras på min kunds server när jag jobbar med Statamic och Laravel.
Vill du läsa mer?
Austin Ginder. var personen som larmade WordPress.org att något var fel. Han har en väldgt detaljerad artikel om denna händelse, och även vilka plugins som blev infekterade.