Illustration av fem likadana dörrar i rad, fyra av dem lyser grönt medan en dörr står mörk och osläckt
Nyheter
Fredrik Eriksson
Fredrik Eriksson

WordPress 7.0.3 tätar ett förautentiserat hål i inloggningssidan, kontrollera att uppdateringen nått din sajt

WordPress 7.0.3 släpptes den 6 augusti 2026 som en ren säkerhetsuppdatering. Versionen rättar tolv sårbarheter, bland annat en förautentiserad cross-site scripting-brist, lagrad XSS, behörighetseskalering, informationsläckage, CSS-injektion, en förbikoppling av e-postverifiering och en SSRF-brist. Flera av rättningarna är backportade ända tillbaka till WordPress 4.7, vilket betyder att även äldre installationer som aldrig uppgraderats till version 7 kan vara berörda.

Den mest uppmärksammade rättningen gäller CVE-2026-64638, som forskarteamet bakom upptäckten döpt till XSS2Shell. Det är en förautentiserad reflekterad XSS-sårbarhet i WordPress inloggningssida, med CVSS-poängen 8.9. Under vissa förutsättningar kan den kedjas vidare till att en angripare kan köra egen PHP-kod på servern, alltså full kontroll över sajten. Enligt WordPress egen säkerhetsrådgivning fanns det per den 8 augusti 2026 inga rapporter om att luckan utnyttjats aktivt. Det är ingen pågående attackvåg. Det är en tyst men ovanligt allvarlig kärnuppdatering, värd att se till att den har landat.

Så fungerar XSS2Shell, i korthet

Sårbarheten sitter i hur inloggningssidan visar ett misslyckat inloggningsförsök, mer specifikt i hur användarnamnet (parametern log) hanteras när WordPress skriver ut felmeddelandet. Två olika saneringsfunktioner i kärnan, strip_tags och KSES, tolkar samma skadliga indata på olika sätt. Den skillnaden gör att en angripare kan smyga in egna element på sidan trots att koden ser ut att rensa bort dem. Därifrån kan WordPress egen JavaScript kapas, och i värsta fall leder kedjan vidare till att en inloggad administratör oavsiktligt godkänner ett applikationslösenord eller laddar upp ett skadligt tillägg, vilket öppnar för att köra kod på servern.

Den sårbara renderingsvägen kom in i kärnan med funktionen wp_admin_notice() i WordPress 6.4, och det är också där XSS2Shell praktiskt sett biter. Versioner från 6.4 till och med 7.0.2 är berörda. Sårbarheten upptäcktes av säkerhetsforskarna på pwn.ai, som rapporterade den till WordPress den 26 och 27 juli 2026. Teamet höll medvetet tillbaka den fullständiga tekniska beskrivningen fram till den offentliga publiceringen den 7 augusti, för att ge sajtägare tid att uppdatera innan detaljerna blev allmänt kända. Den som vill läsa den officiella genomgången hittar den i WordPress egen versionsinformation för 7.0.3.

Rättningen finns redan, frågan är om den nått fram

Här skiljer sig den här nyheten från de flesta CVE-genomgångar. Att sårbarheten finns och är rättad är i sig inte det svåra. Det svåra är att veta om just din WordPress-sajt faktiskt fått rättningen, och det avgörs till stor del av ditt webbhotell och några inställningar du kanske inte vet är avstängda.

Uppdateringen levereras osynligt, och villkorat av värden

Säkerhets- och delversioner som 7.0.3 rullas normalt ut via WordPress automatiska bakgrundsuppdateringar, utan att du behöver göra något. Men "automatiskt" döljer några villkor. Bakgrundsuppdateringar schemaläggs via WP-Cron, och på en sajt där WP-Cron av någon anledning inte körs, till exempel för att loopback-anrop är blockerade, kan även en säkerhetsuppdatering ligga och vänta tills någon råkar logga in eller besöka sajten och utlöser den. Uppdateringen kan också vara avstängd via konstanter som WP_AUTO_UPDATE_CORE satt till false eller DISALLOW_FILE_MODS, av felaktiga filrättigheter, eller av att servern inte når api.wordpress.org. Vi har skrivit mer om när det är läge att slå på automatiska uppdateringar och när det är läge att vänta. Poängen här är enklare. Om du kör en managed WordPress-lösning sköter värden ofta det här åt dig, men anta det inte utan att kontrollera. Kör du ett vanligt delat webbhotell vilar ansvaret oftare på WordPress egen uppdaterare och de inställningar du själv gjort.

"Uppdaterad" är inte samma sak som "kör 7.0.3"

Eftersom rättningarna för den här versionen är backportade, XSS2Shell ända från gren 6.4 och andra buggar ända från 4.7, kan din sajt vara skyddad utan att sitta på exakt 7.0.3. Sitter du på till exempel gren 6.4 kan din installation ha fått en rättad 6.4.x utan att versionsnumret säger "7". Omvänt kan en sajt som borde ha uppdaterats fortfarande sitta kvar på en osäker version om uppdateringen av någon anledning aldrig kördes. Det räcker alltså inte att veta att "en uppdatering finns". Du behöver veta vilken faktisk version din sajt kör och om säkerhetsrättningen är tillämpad på just den grenen.

Attackytan är inloggningssidan, inte ett tillägg

Till skillnad från många av de sårbarheter i tillägg som brukar dominera säkerhetsnyheter sitter XSS2Shell i själva kärnan och utlöses av ett misslyckat inloggningsförsök mot wp-login.php. Att gömma undan inloggningsadressen med ett tillägg för att dölja wp-login tar inte bort den sårbara koden, den ligger kvar oavsett vilken URL du nås på. Rättning är åtgärden här, inte obskuritet.

Så kontrollerar du din egen sajt

  • Gå in under Verktyg > Hälsa (Site Health) eller Kontrollpanel > Uppdateringar och se vilken WordPress-version sajten faktiskt kör, och om det finns en väntande uppdatering.
  • Kör du managed WordPress hos ditt webbhotell, verifiera att värden redan rullat ut uppdateringen i stället för att anta det.
  • Kör du delat webbhotell, kontrollera att automatiska uppdateringar för del- och säkerhetsversioner är påslagna, och att WP-Cron faktiskt körs och inte fastnat.
  • Är du osäker, uppdatera manuellt via Kontrollpanel > Uppdateringar i stället för att vänta.

Misstänker du att din sajt inte uppdaterats i tid och redan uppvisar konstigt beteende, till exempel okända administratörskonton eller filer du inte känner igen, är det läge att gå igenom vår genomgång av hur du sanerar en hackad WordPress-sajt innan du drar för snabba slutsatser om orsaken.

Den andra förautentiserade kärnkedjan på kort tid

XSS2Shell är inte den enda förautentiserade kedjan i WordPress-kärnan som dykt upp under kort tid. Tidigare i år skrev vi om wp2shell, en annan sårbarhet som gick att utnyttja utan inloggning. Två sådana fynd på kort tid är inte skäl till panik, men ett tecken på att tillförlitligheten i bakgrundsuppdateringarna blivit viktigare, inte mindre. Den som vet att uppdateringarna faktiskt landar behöver inte oroa sig särskilt mycket för den här typen av nyheter. Den som inte vet det gör klokt i att ta reda på det nu, innan nästa lucka.