Qué importa primero: WP-CLI compara archivos de núcleo instalados con hashes conocidos para la versión seleccionada y localización. Las diferencias pueden venir de actualizaciones incompletas, ediciones manuales, archivos de versiones incorrectas o compromiso.
Qué indica realmente este síntoma
No todas las advertencias son malware, y no todos los archivos maliciosos están cubiertos por números de verificación del núcleo. La ruta del archivo, el tiempo de modificación y la diferencia determinan la respuesta.
Recopila pruebas antes de cambiar nada
- Registra la versión WordPress, la localización y cada ruta de núcleo no emparejada o inesperada.
- Preservar copias y hashes antes de sobrescribir archivos sospechosos.
- Compara los archivos modificados con el paquete exacto de la versión oficial.
- Comprueba wp-content, usuarios, cron y servidor logs porque la verificación del núcleo cubre solo el núcleo.
Causas más habituales
- Actualización interrumpida: Queda una mezcla de archivos de núcleo antiguos y nuevos.
- Edición manual del núcleo: Un desarrollador cambió un archivo WordPress directamente.
- Paquete equivocado: Los archivos provenían de otra versión o localización.
- Compromiso: Un atacante modificó o añadió archivos ejecutablas en directorios centrales.
Secuencia segura de diagnóstico y reparación
- Tome una instantánea de archivo y base de datos antes de limpiar.
- Reemplace el núcleo con la versión exacta de confianza mientras conserva wp-config.php y wp-content.
- Investigar las modificaciones inesperadas y la ruta de entrada si es posible el compromiso.
- Volver a ejecutar las sumas de verificación después de purgar caché y verificar a los usuarios, cron y directorios escribibles.
Cómo distinguir entre las causas probables
No trates Actualización interrumpida y Edición manual del núcleo como causas equivalentes. Queda una mezcla de archivos de núcleo antiguos y nuevos. En cambio, un desarrollador cambió un archivo WordPress directamente. Para distinguirlas, usa estas dos comprobaciones: Registra la versión WordPress, la localización y cada ruta de núcleo no emparejada o inesperada; y preservar copias y hashes antes de sobrescribir archivos sospechosos. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Tome una instantánea de archivo y base de datos antes de limpiar— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No elimine archivos sospechosos antes de preservar hashes, fecha y horas y una copia cuando el incidente puede implicar datos del cliente o compromiso repetido.
Cómo verificar la reparación
- Las sumas de verificación principales pasan por la versión exacta y la localización.
- Ningún archivo ejecutabla inexplicable permanece en los directorios núcleo o wordable.
- El sitio permanece establa y el monitoreo de integridad no muestra recurrencia.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.