WordPress-sårbarhet CVE-2026-119977: Webbplatser hackade under uppdateringar och hur du skyddar din

I slutet av oktober 2026 upptäcktes en sårbarhet i WordPress uppdateringsmekanism: CVE-2026-119977 . Den tillåter en angripare utan inloggning eller lösenord att exekvera godtycklig kod på servern – men bara medan webbplatsen uppdateras. Sårbarheten används redan i verkliga attacker.

Nedan följer hur det fungerar, vilka som påverkas och vad du ska göra för att skydda din webbplats.

Sårbarheten i korthet

• Vad det är: ett kappvillkor (TOCTOU-klassen) i den fullständiga WordPress-kärnuppdateringsprocessen.
• Stränghet: CVSS 8.1 (Hög).
• Berörda versioner: WordPress 4.7 till och med 7.1.3.
• Vad angriparen behöver: endast HTTP-åtkomst till webbplatsen. Ingen autentisering och ingen administratörsåtgärd krävs.
• Utnyttjande: Den 3 november 2026 lade CISA till sårbarheten i sin katalog över kända utnyttjade sårbarheter (KEV). Wordfence registrerade mer än 18 500 förfrågningar till de sårbara sökvägarna under de första 21 timmarna efter att detaljerna avslöjades.

Hur attacken fungerar

Under en fullständig kärnuppdatering gör WordPress följande:

1. Laddar ner arkivet med den nya versionen.
2. Packar upp den till en tillfällig mapp inuti wp-content/upgrade/.
3. Kopierar filerna över den aktiva webbplatsen.
4. Tar bort den tillfälliga mappen.

Problemet är att den temporära mappen ligger på en förutsägbar väg och är nås från en webbläsareInuti finns en komplett kopia av WordPress, inklusive setup-config.php installatör.

Medan uppdateringen körs kan angriparen öppna installationsprogrammet och gå igenom det. Som ett resultat kan de ersätta live-uppdateringen. wp-config.php och peka webbplatsen mot sin egen tomma databas. WordPress erbjuder sedan en "installation" – angriparen slutför den, blir administratör och kör sin egen PHP-kod på servern.

Attackfönstret är de få sekunder som uppdateringen tar. Det gör attacken svår att genomföra i praktiken, men massskannrar undersöker de sårbara vägarna konstant och räknar med att just den tidpunkten ska vara korrekt.

Version 7.1.4 slumpmässigt väljer namn på den tillfälliga mappen, lägger till skydd mot direkt åtkomst och blockerar konfigurationen från att överföras från den tillfälliga kopian.

tidslinje

Fasta versioner

Åtgärden har bakåtportats till alla stödda grenar ner till 4.7. Vi rekommenderar att du uppdaterar till den senaste versionen, 7.1.4.

Version 4.6 och äldre fick ingen åtgärd. Dessa webbplatser måste uppdateras till en aktuell version eller tas ur bruk.

Steg 1. Kontrollera din WordPress-version

I administratörspanelen: Instrumentpanel → Uppdateringar . Förlita dig inte på automatiska uppdateringar – de kanske inte har körts: de kan vara inaktiverade, misslyckas på grund av filbehörigheter eller åsidosättas av ett plugin.

Med WP-CLI:

wp core version

Om du har flera webbplatser på servern kan du hitta varje WordPress-installation och dess version så här:

find /var/www -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} \;

ersätta /var/www med katalogen där dina webbplatser finns.

Steg 2. Blockera åtkomst till wp-content/upgrade/ (för VPS och dedikerade servrar)

Detta är den viktigaste åtgärden. Den stänger attackfönstret oavsett din WordPress-version och stör inte uppdateringar: WordPress arbetar med den här mappen via filsystemet, inte via webben. Gör detta innan du uppdaterar, eftersom attacken sker just under uppdateringen.

nginx

Lägg till detta på din webbplats server blockera:

location ^~ /wp-content/upgrade/ {
    deny all;
}

Testa konfigurationen och ladda om nginx:

nginx -t && systemctl reload nginx

Apache och LiteSpeed

Lägg till detta till .htaccess fil i webbplatsens rotmapp, ovan standard # BEGIN WordPress blockera:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Om du har tillgång till Apaches virtuella värdkonfiguration är det mer tillförlitligt att blockera katalogen där:

<Directory "/var/www/example.com/wp-content/upgrade">
    Require all denied
</Directory>

Ersätt sökvägen med din egen och ladda om Apache:

apachectl configtest && systemctl reload apache2

På AlmaLinux, Rocky och andra RHEL-baserade system kallas tjänsten httpd.

Kontrollera att blocket fungerar

curl -I https://example.com/wp-content/upgrade/

Svaret ska returnera kod 403.

Steg 3. Gör en säkerhetskopia

Säkerhetskopiera webbplatsens filer och databas innan du uppdaterar. Med WP-CLI:

wp db export ~/backup-$(date +%F).sql
tar -czf ~/site-files-$(date +%F).tar.gz -C /var/www/example.com .

Om du har en VPS kan du också ta en server-ögonblicksbild i kontrollpanelen.

Steg 4. Uppdatera WordPress

Via administratörspanelen eller WP-CLI

Om du har blockerat åtkomst till wp-content/upgrade/ (Steg 2), uppdatera som vanligt — från administratörspanelen eller med WP-CLI:

wp core update
wp core update-db
wp core version

Det sista kommandot ska visa 7.1.4 eller den fixade versionen för din gren.

Manuellt, utan attackfönster

Om du inte kan blockera åtkomst till katalogen på webbservernivå (till exempel om du inte har åtkomst till dess konfiguration) är det säkrare att uppdatera manuellt. Arkivet extraheras utanför webbplatsens rot och filerna kopieras över utan att vidröra wp-config.php or wp-content:

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
rsync -a --exclude 'wp-content' --exclude 'wp-config.php' /tmp/wordpress/ /var/www/example.com/
rm -rf /tmp/wordpress /tmp/latest.tar.gz

Återställ sedan filägarskapet (webbserveranvändaren kan vara en annan, till exempel nginx or apache) och uppdatera databasen:

chown -R www-data:www-data /var/www/example.com
wp core update-db

Istället för det sista kommandot kan du öppna https://example.com/wp-admin/upgrade.php i din webbläsare.

Glöm inte plugins och teman

wp plugin update --all
wp theme update --all

Steg 5. Kontrollera din webbplats för tecken på intrång

Om din webbplats uppdaterades från en sårbar version efter den 28 oktober, se till att ingen utnyttjade attacken.

Förfrågningar till tillfälliga installatörer i loggarna:

# nginx
grep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*

# Apache
grep -E "wp-content/upgrade/.*\.php" /var/log/apache2/access.log*

Förfrågningar med en 200 svarskoden är särskilt misstänkta.

En ersatt wp-config.php: kontrollera filens ändringsdatum och inställningarna för databasanslutningen.

ls -l /var/www/example.com/wp-config.php
grep -E "DB_(NAME|USER|HOST)" /var/www/example.com/wp-config.php

Kärnfilintegritet:

wp core verify-checksums

Okända PHP-filer och administratörer:

find /var/www/example.com/wp-content/upgrade /var/www/example.com/wp-content/uploads -name "*.php"
find /var/www/example.com -name "*.php" -mtime -10
wp user list --role=administrator

Om du hittar en ersatt wp-config.php, okända administratörer eller oväntade PHP-filer, behandla webbplatsen som komprometterad. Återställ den från en säkerhetskopia som gjordes före den 28 oktober, uppdatera WordPress och ändra alla lösenord: administratör, databas, FTP och SSH.

Om en entreprenör underhåller din anläggning

Vidarebefordra den här artikeln till dem och be dem bekräfta att webbplatsen har uppdaterats till en korrekt version och kontrollerats för tecken på intrång.

Behövs hjälp?

Är du osäker på om du kan hantera detta själv, eller har du hittat misstänkta filer? Kontakta vår support – vi hjälper dig att lösa det.