Vulnerabilitat de WordPress CVE-2026-119977: Llocs web piratejats durant les actualitzacions i com protegir el vostre

A finals d'octubre de 2026, es va trobar una vulnerabilitat en el mecanisme d'actualització de WordPress: CVE-2026-119977 . Permet a un atacant sense nom d'usuari ni contrasenya executar codi arbitrari al servidor, però només mentre el lloc s'està actualitzant. La vulnerabilitat ja s'està utilitzant en atacs reals.

A continuació s'explica com funciona, qui es veu afectat i què cal fer per protegir el vostre lloc web.

La vulnerabilitat en breu

• Què és: una condició de cursa (classe TOCTOU) en el procés complet d'actualització del nucli de WordPress.
• Severitat: CVSS 8.1 (Alt).
• Versions afectades: WordPress 4.7 fins a 7.1.3 ambdós inclosos.
• Què necessita l'atacant: només accés HTTP al lloc. No cal autenticació ni cap acció d'administrador.
• Explotació: El 3 de novembre de 2026, CISA va afegir la vulnerabilitat al seu catàleg de vulnerabilitats explotades conegudes (KEV). Wordfence va registrar més de 18,500 sol·licituds a les rutes vulnerables durant les primeres 21 hores després que es revelessin els detalls.

Com funciona l'atac

Durant una actualització completa del nucli, WordPress fa el següent:

1. Descarrega l'arxiu amb la nova versió.
2. L'extreu a una carpeta temporal dins de wp-content/upgrade/.
3. Copia els fitxers sobre el lloc web en directe.
4. Elimina la carpeta temporal.

El problema és que la carpeta temporal es troba a camí previsible i és accessible des d'un navegadorA dins hi ha una còpia completa de WordPress, incloent-hi el setup-config.php instal·lador.

Mentre l'actualització s'està executant, l'atacant pot obrir aquest instal·lador i executar-lo. Com a resultat, pot substituir el fitxer en directe. wp-config.php i apunta el lloc a la seva pròpia base de dades buida. WordPress ofereix llavors una "instal·lació": l'atacant la completa, es converteix en administrador i executa el seu propi codi PHP al servidor.

La finestra d'atac són els pocs segons que triga l'actualització. Això fa que l'atac sigui difícil de dur a terme a la pràctica, però els escàners massius sondegen constantment els camins vulnerables, comptant exactament amb aquest moment per alinear-se.

La versió 7.1.4 aleatoritza el nom de la carpeta temporal, afegeix protecció contra l'accés directe i impedeix que la configuració es transfereixi de la còpia temporal.

Línia de temps

Versions fixes

La correcció s'ha aplicat a totes les branques compatibles fins a la versió 4.7. Recomanem actualitzar a la darrera versió, la 7.1.4.

Les versions 4.6 i anteriors no han rebut cap correcció. Cal actualitzar aquests llocs a una versió actual o retirar-los del servei.

Pas 1. Comprova la teva versió de WordPress

Al tauler d'administració: Tauler de control → Actualitzacions . No confieu en les actualitzacions automàtiques; és possible que no s'hagin executat: que estiguin desactivades, que fallin a causa dels permisos de fitxer o que un connector les hagi anul·lat.

Amb WP-CLI:

wp core version

Si teniu diversos llocs al servidor, podeu trobar totes les instal·lacions de WordPress i les seves versions així:

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

Reemplaçar /var/www amb el directori on resideixen els vostres llocs web.

Pas 2. Bloqueja l'accés a wp-content/upgrade/ (per a servidors VPS i dedicats)

Aquesta és la mesura més important. Tanca la finestra d'atac independentment de la versió de WordPress i no interfereix amb les actualitzacions: WordPress treballa amb aquesta carpeta a través del sistema de fitxers, no a través del web. Feu-ho abans d'actualitzar, ja que l'atac es produeix precisament durant l'actualització.

nginx

Afegeix això al teu lloc web server bloc:

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

Proveu la configuració i torneu a carregar nginx:

nginx -t && systemctl reload nginx

Apache i LiteSpeed

Afegiu això a .htaccess fitxer a l'arrel del lloc, dalt la norma # BEGIN WordPress bloc:

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

Si teniu accés a la configuració de l'amfitrió virtual d'Apache, és més fiable bloquejar el directori allà:

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

Substitueix la ruta per la teva pròpia i torna a carregar Apache:

apachectl configtest && systemctl reload apache2

En AlmaLinux, Rocky i altres sistemes basats en RHEL, el servei s'anomena httpd.

Comproveu que el bloc funciona

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

La resposta ha de retornar codi 403.

Pas 3. Fes una còpia de seguretat

Abans d'actualitzar, feu una còpia de seguretat dels fitxers i la base de dades del lloc. Amb WP-CLI:

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

Si teniu un VPS, també podeu fer una captura de pantalla del servidor al tauler de control.

Pas 4. Actualitza WordPress

A través del panell d'administració o WP-CLI

Si heu bloquejat l'accés a wp-content/upgrade/ (Pas 2), actualitzeu com de costum — des del tauler d'administració o amb WP-CLI:

wp core update
wp core update-db
wp core version

L'última ordre hauria de mostrar la versió 7.1.4 o la versió fixa per a la vostra branca.

Manualment, sense finestra d'atac

Si no podeu bloquejar l'accés al directori a nivell del servidor web (per exemple, si no teniu accés a la seva configuració), és més segur actualitzar-lo manualment. L'arxiu s'extreu fora de l'arrel del lloc i els fitxers es copien sense tocar-los. 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

A continuació, restaureu la propietat del fitxer (l'usuari del servidor web pot ser diferent, per exemple) nginx or apache) i actualitzar la base de dades:

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

En lloc de l'última ordre, podeu obrir https://example.com/wp-admin/upgrade.php al teu navegador.

No us oblideu dels complements i temes

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

Pas 5. Comproveu si el vostre lloc web està compromès

Si el vostre lloc web s'ha actualitzat des d'una versió vulnerable després del 28 d'octubre, assegureu-vos que ningú s'hagi aprofitat de l'atac.

Sol·licituds als instal·ladors temporals als registres:

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

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

Sol·licituds amb un 200 el codi de resposta és especialment sospitós.

Un wp-config.php substituït: comproveu la data de modificació del fitxer i la configuració de connexió a la base de dades.

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

Integritat del fitxer principal:

wp core verify-checksums

Fitxers i administradors de PHP desconeguts:

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

Si trobeu un substitut wp-config.php, administradors desconeguts o fitxers PHP inesperats, considereu el lloc com a compromès. Restaureu-lo des d'una còpia de seguretat feta abans del 28 d'octubre, actualitzeu WordPress i canvieu totes les contrasenyes: administrador, base de dades, FTP i SSH.

Si un contractista manté el vostre lloc

Envia'ls aquest article i demana'ls que confirmin que el lloc web s'ha actualitzat a una versió corregida i que s'ha comprovat si hi ha signes de compromís.

Necessites ajuda?

No esteu segur de poder gestionar-ho vosaltres mateixos o heu trobat fitxers sospitosos? Poseu-vos en contacte amb el nostre equip d'assistència: us ajudarem a resoldre-ho.