En resumen: la vulnerabilidad de PHP en WordPress sobre la que se informa actualmente no está en WordPress, sino en PHP, en el servidor que hay debajo. Por eso una actualización de WordPress no cierra PHP2Shell. Lo decisivo son el nivel de parcheo de PHP, el reinicio de todos los procesos de PHP y una revisión de los escondites habituales, como wp-content/uploads y mu-plugins.
Por qué una actualización de WordPress no corrige PHP2Shell
WordPress es una aplicación escrita en PHP. Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 están un nivel más abajo, en el propio intérprete de PHP. Según el equipo de PHP, permiten ejecutar código malicioso de forma remota y sin autenticación. En Apache con mod_php se demostró un exploit antes de que se ejecute siquiera código de WordPress.
Un sitio web con el núcleo actualizado, plugins actualizados y contraseñas robustas puede seguir siendo vulnerable si el PHP que hay debajo es antiguo. A la inversa, un PHP ya parcheado no demuestra que antes no haya ocurrido nada. Explicamos el contexto en ¿Qué es PHP2Shell?.
| Nivel | Quién actualiza | ¿Cierra PHP2Shell? |
|---|---|---|
| Núcleo de WordPress | Usted o su agencia | No |
| Plugins y temas | Usted o su agencia | No |
| PHP en el servidor | Proveedor de hosting o administrador del servidor | Sí, junto con el reinicio de todos los procesos de PHP |
Vulnerabilidad de PHP en WordPress: comprobar la versión de PHP
En el escritorio, en Herramientas > Salud del sitio > Información, en la sección «Servidor», encontrará la versión de PHP con la que su sitio web se ejecuta realmente. Es más fiable que php -v en la línea de comandos, porque la línea de comandos suele usar una instalación de PHP distinta de la del servidor web.
Aun así, el número mostrado no basta. Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Sin embargo, muchos proveedores de hosting incorporan las correcciones como backport; entonces sigue apareciendo un número más antiguo aunque ya esté parcheado. Cómo averiguar el estado real se explica en Cómo comprobar correctamente la versión de PHP y el nivel de parcheo. Qué versiones de PHP admite su versión de WordPress puede consultarlo, según los requisitos del sistema, en wordpress.org.
Dónde suele esconderse el código malicioso en WordPress
Tras un ataque exitoso, los atacantes suelen dejar una puerta trasera para volver incluso después del parche. WordPress tiene lugares conocidos para ello:
- wp-content/uploads/: pensada para imágenes y PDF, no para archivos PHP.
- wp-content/mu-plugins/: los plugins «must-use» se cargan automáticamente y no se pueden desactivar desde el escritorio.
- wp-config.php: contiene el acceso a la base de datos y las claves de seguridad; una línea añadida aquí apenas se nota.
- .htaccess en el directorio principal y en subcarpetas: redirecciones solo para buscadores o la ejecución de extensiones de archivo inusuales.
- Temas, sobre todo
functions.php, así como plugins desactivados y olvidados. - Base de datos: nuevos administradores en
wp_users, JavaScript ajeno enwp_optionso en las entradas.
Primeras comprobaciones inofensivas con WP-CLI y recursos del propio sistema:
# Comparar los archivos del núcleo con las sumas de verificación oficiales
wp core verify-checksums
# Comprobar los plugins del directorio de wordpress.org
wp plugin verify-checksums --all
# Listar los archivos PHP de la carpeta de subidas
find wp-content/uploads -type f -name "*.php"
# Mostrar todos los administradores
wp user list --role=administrator
Un resultado es un motivo para investigar con detalle, aún no una prueba. Los plugins comerciales no se pueden comprobar así. En la guía Cómo encontrar puertas traseras en WordPress encontrará más detalles.
No borre archivos sospechosos con precipitación. Guarde primero los archivos, la base de datos y los registros del servidor a partir del 20/10/2026. Sin esos rastros no se podrá aclarar después si se han filtrado datos.
Plugins, temas y accesos de administrador como riesgo adicional
PHP2Shell no necesita una vulnerabilidad en un plugin. Aun así, en el día a día los plugins y temas siguen siendo la puerta de entrada más frecuente a los sitios WordPress. Cada plugin aporta código propio, funciones de subida propias y ciclos de actualización propios. Los plugins que no use conviene borrarlos en lugar de solo desactivarlos, porque los archivos desactivados siguen en el servidor.
Para wp-login.php y wp-admin se aplica lo siguiente: pocos administradores, cuentas personales en lugar de accesos compartidos y autenticación en dos pasos. Si no necesita XML-RPC, se puede bloquear. Ante una sospecha, deberían renovarse todas las contraseñas y las claves de seguridad de wp-config.php. También allí se desactiva el editor de archivos del escritorio:
define( 'DISALLOW_FILE_EDIT', true );
Qué debería hacer ahora como operador de WordPress
- Pedir a su proveedor de hosting que confirme por escrito el nivel de parcheo de PHP y el reinicio de todos los procesos de PHP.
- Hacer que se conserven los registros del servidor a partir del 20/10/2026.
- Realizar, o encargar, las comprobaciones anteriores.
- Actualizar WordPress, los plugins y los temas. Es lo correcto, pero no sustituye al paso 1.
- Si hay indicios anómalos, no seguir explotando el sitio web sin más, sino hacerlo limpiar.
Una actualización de la plataforma puede cerrar vulnerabilidades conocidas en WordPress y en los plugins. No puede reparar PHP ni eliminar archivos introducidos que no forman parte del núcleo.
¿Cómo ayuda PHP SOS en concreto?
- Aclaramos con usted o con su proveedor de hosting el estado real de PHP de su sitio WordPress, incluidos los backports y el reinicio.
- Guardamos registros, archivos y base de datos antes de modificar nada.
- Revisamos el núcleo, los plugins, las subidas, mu-plugins,
.htaccessy las cuentas de usuario en busca de puertas traseras. - Si hay hallazgos, nuestra eliminación de malware se encarga de la limpieza hasta que el incidente quede cerrado y documentado; si no los hay, reforzamos la instalación dentro de la ayuda inmediata ante PHP2Shell.
Preguntas frecuentes
¿Debo actualizar WordPress por PHP2Shell?
Tener WordPress actualizado siempre es recomendable, pero no cierra PHP2Shell. La vulnerabilidad está en el intérprete de PHP del servidor. Para corregirla hace falta una actualización de PHP o un backport confirmado de su proveedor de hosting, y un reinicio de todos los procesos de PHP.
¿Protege un plugin de seguridad frente a PHP2Shell?
Solo de forma muy limitada. Un plugin es en sí mismo código PHP que se ejecuta dentro de WordPress. En mod_php se ha demostrado un exploit antes de que arranque siquiera el código de la aplicación; es posible que un plugin ni se entere de un ataque así.
¿Por qué WordPress sigue mostrando una versión antigua de PHP aunque el proveedor de hosting haya aplicado el parche?
Muchos proveedores de hosting y distribuciones de Linux incorporan las correcciones como backport en la versión existente. El número de versión entonces no cambia. Pida a su proveedor que le confirme por escrito el nivel de parcheo.
¿Puede haber un archivo PHP en wp-content/uploads?
Por lo general, no. La carpeta de subidas está pensada para archivos multimedia. Un archivo PHP allí es una señal de alerta clara y conviene guardarlo y hacerlo examinar por especialistas antes de borrarlo.