En resumen: para comprobar los archivos del núcleo del CMS, compare los archivos instalados con un original limpio de la misma versión: en WordPress mediante las sumas de verificación oficiales; en otros sistemas, mediante una descarga nueva o una reconstrucción a partir de composer.lock. Cada diferencia es una tarea de revisión. La comparación encuentra también código malicioso desconocido, pero solo cubre los archivos de los que existe un original.
Por qué la comparación encuentra más que cualquier firma
Los escáneres de malware buscan patrones conocidos. Lo que no conocen, lo pasan por alto. Una comparación con el original funciona al revés: no pregunta si un archivo parece sospechoso, sino si coincide exactamente con lo que entregó el fabricante. Cualquier diferencia llama la atención, siga o no un patrón conocido.
Esto es especialmente valioso tras PHP2Shell. Para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 no hay indicadores de compromiso (IoC) publicados y confirmados. Por tanto, los escáneres no pueden buscar de forma específica rastros de PHP2Shell. En cambio, una comparación con el original encuentra cualquier modificación del núcleo, con independencia de cómo se produjo. Por qué los escáneres por sí solos no bastan lo explica el artículo Escáneres de malware para sitios web: qué encuentran y qué no.
El principio: la misma versión, una fuente limpia
Una comparación vale lo que valga su referencia. Deben cumplirse tres condiciones:
- Exactamente la misma versión: una comparación con una versión más reciente muestra cientos de diferencias inofensivas. Averigüe la versión instalada desde la aplicación o desde
composer.lock. - Fuente oficial: el original procede del fabricante, del directorio oficial de paquetes o de su propio sistema de control de versiones. No de una copia de seguridad antigua del servidor afectado.
- Comparación sobre una copia: trabaje sobre una copia asegurada del directorio web, para que se conserven las marcas de tiempo y los rastros.
| Sistema | Referencia | Herramienta |
|---|---|---|
| Núcleo de WordPress y plugins del directorio | sumas de verificación de WordPress.org | wp core verify-checksums, wp plugin verify-checksums |
| Proyectos Composer (p. ej., Shopware 6, Laravel, Symfony, Drupal, TYPO3 en modo Composer) | reconstrucción a partir de composer.lock |
composer install en un directorio vacío, después diff |
| CMS con paquete de descarga | paquete de la misma versión del fabricante | diff -rq |
| Proyectos propios con Git | último commit conocido | git status, git diff |
| Paquetes del sistema del servidor | base de datos de paquetes de la distribución | dpkg --verify, rpm -Va |
WordPress: más que verify-checksums
Cómo comprobar el núcleo y los plugins con WP-CLI se explica en la guía Encontrar puertas traseras en WordPress. Merece la pena un complemento: según la documentación de WP-CLI, la opción --include-root comprueba todos los archivos y carpetas del directorio principal y avisa de las entradas que no pertenecen a WordPress. Ahí es donde los atacantes suelen dejar archivos cuyos nombres recuerdan a los del núcleo.
# Núcleo frente a las sumas de verificación oficiales, incluidos archivos ajenos en el directorio principal
wp core verify-checksums --include-root
Los plugins y temas comerciales no quedan cubiertos por este camino. Para ellos, descargue del proveedor el paquete original de la misma versión y compare con diff.
Comprobar los archivos del núcleo del CMS en proyectos Composer
Muchas aplicaciones PHP modernas se componen en su mayor parte de paquetes que instala Composer, el gestor de paquetes de PHP. Cómo funciona se explica en la página Composer: el gestor de paquetes de PHP. El archivo composer.lock registra qué versiones exactas están instaladas. Según la documentación de Composer, composer install utiliza esas versiones exactas. Así se puede reconstruir el estado de entrega:
# En un sistema limpio, no en el servidor afectado
mkdir /tmp/referenz && cd /tmp/referenz
cp /pfad/zur/kopie/composer.json /pfad/zur/kopie/composer.lock .
composer install --no-scripts --no-plugins --no-autoloader
# Listar las diferencias en la carpeta vendor
diff -rq /tmp/referenz/vendor /pfad/zur/kopie/vendor
Las opciones --no-scripts y --no-plugins impiden que durante la reconstrucción se ejecuten scripts de los paquetes. Si producción se instaló con --no-dev, utilice también esa opción en la reconstrucción; de lo contrario, los paquetes de desarrollo aparecerán como diferencia. Fíjese en dos tipos de resultado: archivos que difieren y archivos que solo existen en el servidor. El segundo grupo suele ser el más interesante. Cómo revisar además los paquetes instalados en busca de vulnerabilidades conocidas lo describe la guía Revisar las dependencias de Composer en busca de vulnerabilidades.
Comparar también el sistema operativo
Si un atacante tuvo derechos de root, también puede haber sustituido programas del sistema. Los gestores de paquetes incorporan su propia comparación:
# Debian, Ubuntu: archivos cuyo contenido difiere del paquete
sudo dpkg --verify
# RHEL, AlmaLinux, Rocky: comprobar todos los paquetes
sudo rpm -Va
Un 5 en tercera posición de la salida significa que el contenido de un archivo ha cambiado. Según el manual de dpkg, la comparación del contenido es allí actualmente la única comprobación eficaz. Los archivos de configuración modificados son normales y se marcan con c. En cambio, un programa modificado en /usr/bin es una señal de alarma seria. Tenga en cuenta: un atacante con derechos de root también puede manipular la base de datos de paquetes. Ante la sospecha de acceso root, reconstruir el sistema es más fiable que cualquier comparación.
Un sistema de control de versiones para el código de la aplicación convierte las comparaciones futuras en cuestión de segundos. git status muestra entonces cualquier desviación del estado aprobado.
Valorar las diferencias y conocer los límites
No toda diferencia es un ataque. Algunas agencias modificaban antes directamente archivos del núcleo en lugar de usar extensiones. Los paquetes de idioma, los finales de línea tras una transferencia por FTP o las correcciones aplicadas posteriormente también generan diferencias. Lo decisivo es si alguien puede explicar el cambio.
Revise cada diferencia por separado y anote el resultado: conocida y documentada, explicable e inofensiva o poco clara. Los archivos poco claros se abren solo como texto sobre una copia y se sustituyen desde la fuente limpia. En los archivos que solo existen en el servidor la pregunta es más sencilla: si nadie los conoce, conviene asegurarlos y eliminarlos tras comprobar su contenido.
Las subidas, los archivos de configuración como wp-config.php o .env, las adaptaciones propias y las cachés no tienen original. Deben revisarse de forma específica, igual que la base de datos, las tareas cron, las cuentas de usuario y las claves SSH. Una comparación limpia es, por tanto, una pieza importante, pero no una absolución para todo el servidor.
¿Cómo ayuda PHP SOS en concreto?
- Averiguamos las versiones instaladas y montamos una referencia limpia a partir de fuentes oficiales.
- Comparamos el núcleo, las extensiones, los paquetes de Composer y los programas del sistema, y valoramos cada diferencia.
- Revisamos de forma específica las áreas sin original y sustituimos los archivos modificados desde una fuente limpia en el marco de la eliminación de malware.
- Si lo desea, configuramos un estado de versión frente al cual se ejecuten las futuras comprobaciones.
Preguntas frecuentes
¿Cómo compruebo si se han modificado los archivos del núcleo de WordPress?
Con WP-CLI y el comando wp core verify-checksums. Compara los archivos con las sumas de verificación que WordPress.org publica para la versión instalada. Con la opción --include-root, WP-CLI avisa además de los archivos del directorio principal que no pertenecen a WordPress.
¿Qué hago con un CMS sin función de verificación integrada?
Descargue exactamente la misma versión de la fuente oficial del fabricante y compare ambos directorios con diff. En proyectos Composer, reconstruya el estado a partir de composer.lock en un directorio vacío y compare la carpeta vendor.
¿La comparación encuentra también código malicioso en plugins y temas?
Solo si existe un original limpio para ellos, por ejemplo del directorio oficial o del proveedor. Las adaptaciones propias, las subidas y los archivos de configuración no tienen original y deben revisarse por separado.
¿La comparación sustituye a un escáner de malware?
La complementa. La comparación encuentra cualquier cambio en archivos conocidos, incluso código malicioso desconocido. Pero no dice nada sobre archivos sin original, la base de datos, las tareas cron ni los accesos.