Verificar checksums de WordPress: archivos modificados

Si sospecha que su web ha sido atacada, verificar los checksums de WordPress es una buena comprobación inicial, pero no debe retrasar la contención ni la conservación de las pruebas. Un solo comando le dice si los archivos del núcleo son idénticos, byte a byte, a los de la versión oficial. Los archivos incluidos en la lista oficial de checksums deben coincidir con su versión e idioma exactos. Los archivos propios del sitio, como wp-config.php, quedan fuera de esa comparación. Cualquier diferencia es un cambio local que usted conoce o algo que hay que investigar hoy mismo.

Por qué cambian los archivos del núcleo de WordPress tras un ataque

Los archivos del núcleo son un buen escondite porque nadie los lee. Los propietarios revisan los ajustes del tema y de los plugins. Casi nadie abre wp-includes/load.php ni cuenta los archivos de wp-admin/includes. Un atacante puede ocultar código en un archivo del núcleo que se carga con regularidad, o añadir un archivo de apariencia legítima para volver a entrar más tarde. Un archivo añadido no se ejecuta solo por estar en un directorio del núcleo.

Los checksums convierten el «parece que está bien» en una comparación demostrable. WordPress.org publica un hash MD5 de cada archivo del núcleo de cada versión. Usted compara sus archivos con esa lista.

Aun así, no pierda de vista la causa. El informe State of WordPress Security in 2026 de Patchstack es el de un proveedor del sector. Contabiliza solo 6 vulnerabilidades en el núcleo de WordPress en 2025, todas de baja prioridad. Esa cifra no explica cómo entró el atacante en su sitio. Los archivos del núcleo modificados pueden ser el resultado de una intrusión a través de un plugin, un tema o credenciales robadas. Reemplazar el núcleo repara esos archivos, pero sigue siendo necesario identificar y cerrar la vía de entrada.

Cómo verificar los checksums de WordPress con WP-CLI

Conéctese por SSH y ejecute el comando desde el directorio raíz de WordPress:

cd /var/www/example.com
wp core verify-checksums

Si está en otro directorio, añada --path=/var/www/example.com. Ejecute el comando con el usuario propietario de los archivos del sitio, no como root. WP-CLI se niega a ejecutarse como root salvo que añada --allow-root, y ese comportamiento por defecto es sensato: como root, cualquier código malicioso que cargue WordPress también se ejecutaría como root.

Por defecto, WP-CLI lee la versión de wp-includes/version.php. En un sitio comprometido, ese archivo también puede estar modificado. Si sabe qué versión instaló, indíquela de forma explícita. En instalaciones que no estén en inglés, indique además el idioma. El ejemplo usa de_DE; para español de España sería es_ES:

wp core verify-checksums --version=6.8.3 --locale=de_DE

Use su propio número de versión. En un sitio limpio verá una sola línea:

Success: WordPress installation verifies against checksums.

En un sitio con problemas verá avisos como estos:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Cómo leer el resultado: archivos modificados y archivos extra

Los dos tipos de aviso significan cosas distintas y se tratan de forma distinta.

Tome en serio un archivo modificado, salvo que sepa de un parche local legítimo. Esos parches son raros, y quien hizo uno debería haberlo documentado.

Un archivo extra es menos claro. Algunas actualizaciones dejan archivos de versiones anteriores, así que un archivo sobrante no prueba que haya malware. Un archivo PHP con nombre aleatorio en wp-includes es sospechoso hasta que lo haya leído. También lo es un archivo cuyo nombre solo suena a componente del núcleo.

Los archivos extra pueden aparecer como avisos sin que el comando falle. Es posible ver líneas File should not exist seguidas de Success. Lea cada aviso en lugar de fiarse de la última línea.

Por defecto, la comprobación de archivos extra cubre wp-admin y wp-includes. Algunas versiones de WP-CLI pueden revisar también el directorio raíz. Ejecute wp help core verify-checksums para ver si la suya ofrece --include-root.

¿Sin WP-CLI? Use la API de checksums de WordPress.org

Algunos hostings ofrecen SSH pero no WP-CLI. En ese caso, consulte directamente la API de checksums y deje que md5sum compare los archivos. Necesita curl y jq:

cd /var/www/example.com
VER=6.8.3        # su versión exacta de WordPress
LOC=en_US        # o es_ES, de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

El filtro select omite los temas y plugins incluidos en wp-content, que quizá haya borrado a propósito. Con --quiet, md5sum muestra solo los archivos que fallan.

Si no hay salida y el código de salida es cero, los archivos de la lista de checksums filtrada coinciden. Un error de descarga, de análisis o de verificación no es un resultado limpio. La subshell usa un directorio temporal privado y se detiene si falla un paso anterior.

Este método no detecta archivos extra. Para encontrarlos, descargue la misma versión, por ejemplo https://wordpress.org/wordpress-6.8.3.zip. En instalaciones en otro idioma, use el sitio de WordPress de ese idioma. Descomprima el archivo y compare las carpetas:

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

Las líneas Only in /var/www/... señalan archivos extra instalados. Las líneas Only in wordpress/... señalan archivos que faltan en la instalación. Las líneas Files ... differ señalan diferencias de contenido. Inspeccione también los directorios inesperados.

Plugins y temas: hasta dónde llegan los checksums

WP-CLI también puede comprobar plugins:

wp plugin verify-checksums --all

Esto solo funciona con plugins alojados en WordPress.org, porque solo esos tienen checksums publicados. Los plugins que no tienen un conjunto de checksums correspondiente en WordPress.org no pueden verificarse así.

Si una copia pirata (nulled) o manipulada conserva el slug y la versión de un plugin de WordPress.org, el comando puede compararla igualmente y marcará los archivos modificados. WP-CLI no incluye un comando equivalente para los checksums de temas.

Para esos plugins y para los temas, obtenga la versión instalada exacta de su fuente oficial o de un archivo de compilación de confianza. En el caso de código a medida, use un artefacto de versión que sepa que es correcto, no una copia sacada del sitio sospechoso. Después compárelo con la copia instalada:

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Busque también carpetas de plugins que no pueda asociar a nada que usted instalara. Una carpeta desconocida en wp-content/plugins es una señal de alarma. Un plugin nulled es un problema en sí mismo, muestre lo que muestre el diff. La guía sobre vulnerabilidades de plugins explica cómo sustituir plugins nulled y abandonados.

Cómo reinstalar el núcleo de WordPress con seguridad

Primero guarde las pruebas y haga una copia de seguridad completa. Después reemplace el núcleo por una copia limpia de la misma versión:

wp core download --force --skip-content --version=6.8.3

Añada --locale=de_DE o el de su idioma si hace falta. El comando sobrescribe los archivos del núcleo. No toca wp-config.php, porque el paquete no contiene ese archivo. --skip-content deja wp-content intacto.

El comando no elimina los archivos extra. Un archivo como wp-includes/class-wp-cache-handler.php se queda donde está, porque la descarga solo escribe archivos oficiales. Copie y revise primero cada archivo extra. Después elimine los que sean maliciosos o que haya confirmado que sobran. Vuelva a ejecutar wp core verify-checksums y compruebe que no quedan avisos sin explicar.

Lo que un resultado limpio no le dice

Un resultado correcto solo cubre el núcleo de WordPress. No dice nada sobre:

• wp-content: temas, plugins premium y a medida, mu-plugins y uploads
• wp-config.php y .htaccess, que no figuran en la lista de checksums
• La base de datos: opciones inyectadas, spam en entradas, cuentas de administrador ajenas, eventos de cron programados
• Archivos ajenos a WordPress, como otros archivos PHP de la cuenta de hosting o la configuración a nivel de servidor

Los atacantes saben qué archivos se comprueban. Es una de las razones por las que wp-content/uploads es un lugar preferido para las web shells. Repase los signos de un sitio hackeado para el resto de comprobaciones. Para uploads, use la guía sobre web shells.

Supervisión continua de la integridad de los archivos

Una comprobación puntual sirve durante un incidente. Una comprobación programada puede acortar el tiempo que una modificación pasa inadvertida, aunque los cambios pueden afectar a los visitantes antes de la siguiente ejecución. Basta un pequeño script lanzado por cron:

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Instálelo en el crontab del usuario propietario del sitio, no en el de root. El script avisa cuando el código de salida no es cero y ante cualquier aviso, incluidos los archivos extra. Defina un PATH conocido o use rutas completas a los ejecutables, porque cron tiene un entorno limitado. Compruebe que la alerta llega de verdad; si hace falta, sustituya mail por el sistema de alertas que tenga operativo.

Para wp-content, guarde su propia línea base después de cada actualización que sepa que es correcta:

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Guarde la línea base fuera del directorio web y, a ser posible, fuera del servidor. Para detectar cambios, ejecute sha256sum -c --quiet con la línea base desde la raíz del sitio. Así se detectan archivos modificados y borrados, pero no los nuevos. Para los nuevos, compare una lista reciente de archivos obtenida con find con la de la línea base. Cree una línea base nueva tras cada actualización legítima; de lo contrario, la siguiente comprobación marcará sus propios cambios.

Las comprobaciones periódicas también ayudan a cumplir la normativa. El art. 32, apartado 1, letra d) del RGPD exige un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas de seguridad. Una comprobación de integridad programada, con los resultados guardados, es una prueba concreta de ese proceso. Para el contexto general, consulte el artículo 32 del RGPD en WordPress.

Si prefiere no mantener scripts, el plugin Security Audit & Compliance de secaudit.eu mantiene una línea base de integridad de archivos e informa de los archivos modificados y del contenido ofuscado. También ejecuta la verificación de checksums del núcleo. Detecta e informa; la limpieza sigue siendo cosa suya o de su agencia.

FAQ

¿Funciona verify-checksums en multisite y en instalaciones que no están en inglés?

Sí. Una red multisite comparte un único conjunto de archivos del núcleo, así que una ejecución cubre toda la red. En instalaciones que no estén en inglés, indique el --locale correcto, porque los paquetes localizados pueden diferir de en_US.

¿Un aviso «File should not exist» siempre es malware?

No. También lo provocan los archivos que dejan versiones antiguas de WordPress. Guarde una copia e inspeccione el archivo. Elimínelo si es malicioso o si ha confirmado que sobra. El código PHP sin explicación dentro de una carpeta del núcleo siempre merece un análisis a fondo.

¿Con qué frecuencia debo ejecutarlo?

Para la mayoría de los sitios de empresa es razonable una ejecución diaria con cron. Ejecútelo también tras un incidente, después de cada actualización del núcleo y siempre que alguien nuevo obtenga acceso al servidor.

¿Puede un atacante falsear el resultado de los checksums?

Los checksums proceden de WordPress.org por HTTPS. Un atacante que controle su servidor podría, no obstante, manipular las herramientas locales, como el archivo de WP-CLI o los binarios del sistema. En caso de duda, copie los archivos del sitio a un equipo limpio y compárelos allí con una descarga nueva de la misma versión.