Innloggingssiden i WordPress slapp gjennom kode fra hvem som helst

WordPress ga 6. august ut versjon 7.0.3, som retter en sårbarhet på innloggingssiden. Feilen har nummeret CVE-2026-64638, og lar en angriper få egen kode til å kjøre i nettleseren til den som åpner en spesiallaget lenke. NVD har satt alvorlighetsgraden til 8,9 av 10 etter CVSS 4.0. Ifølge NVD gjelder feilen alle versjoner av WordPress, og rettelsen er lagt ut i alle grener som fortsatt får sikkerhetsoppdateringer, tilbake til 4.7. Ingen av kildene oppgir at feilen er utnyttet i angrep.

Hva som skjer teknisk

Sårbarheten ligger i brukernavnfeltet på wp-login.php, i parameteret som heter log. Finnerne i pwn.ai beskriver at innholdet passerer to filtre som er uenige om hva en HTML-tagg er. Det første filteret, wp_strip_all_tags, bygger på PHP-funksjonen strip_tags, og den regner bare et vinkeltegn som starten på en tagg når neste tegn er en bokstav. Setter angriperen et mellomrom mellom vinkeltegnet og taggnavnet, overlever strengen som ren tekst. Det andre filteret, wp_kses_post, tolker romsligere, og godtar den samme strengen som en gyldig og tillatt tagg. Resultatet er at angriperen får plassert egne HTML-elementer på en side som vises før noen har logget inn.

Elementene alene er ikke målet. pwn.ai viser hvordan de brukes til å styre WordPress sitt eget skript for brukerprofiler, slik at nettstedets egen JavaScript sender en forespørsel til et endepunkt angriperen velger. Derfra beskriver finnerne en kjede i fem trinn, der et klikk i en pålogget administrators økt godkjenner et applikasjonspassord, passordet brukes mot REST-grensesnittet, og et utvidelsesarkiv med PHP-kode lastes opp. NVD understreker at eskaleringen til kodekjøring krever at offeret lures til å gjøre noe aktivt, og at forhold utenfor angriperens kontroll må stemme. Selve sårbarheten på innloggingssiden krever derimot ingen pålogging.

Hva det betyr for deg som drifter et WordPress-nettsted

Berigos vurdering er at det viktigste her ikke er selve XSS-feilen, men hvor kort veien er derfra til kontroll over nettstedet ditt. Kjeden pwn.ai beskriver, ender med at PHP-kode kjører på tjeneren. En tjener som kjører angriperens kode, når også databasen bak nettstedet. Har du satt opp nettstedet en gang og siden latt det være i fred, er det ditt som blir stående igjen på gammel kode.

Forutsetningene demper risikoen din, men de fjerner den ikke. Eskaleringen krever ifølge NVD at en administrator lures til å gjøre noe aktivt. Er du selv den administratoren, er dette den typen forutsetning som pleier å bli oppfylt i en travel hverdag. Sikkerhetsutgivelsen 6. august rettet i alt tolv svakheter. Oppdateringen er verdt å ta uansett hvor sannsynlig akkurat denne kjeden virker for deg.

Berigo anbefaler

• Oppdater til WordPress 7.0.3, eller til den rettede utgaven i den grenen nettstedet står på.
• Kontroller at automatisk bakgrunnsoppdatering faktisk er slått på, og at den har kjørt.
• Gå gjennom applikasjonspassordene som finnes på nettstedet, og fjern dem ingen kjenner igjen.
• Begrens hvem som kan laste opp utvidelser, og steng opplasting i produksjon der det lar seg gjøre.
• Sett nettstedet på listen over det noen har et navngitt ansvar for å oppdatere.