# Vulnerabilidad de PHP en WordPress (PHP2Shell): qué deben hacer los operadores

> PHP2Shell afecta a WordPress a través de PHP, no del núcleo. Compruebe la versión de PHP, uploads, mu-plugins y administradores y proteja su sitio web.

Fuente: https://phpsos.de/es/plattformen/wordpress/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**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?](https://phpsos.de/es/php2shell/was-ist-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](https://phpsos.de/es/php2shell/php-version-pruefen/). 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 en `wp_options` o en las entradas.

Primeras comprobaciones inofensivas con WP-CLI y recursos del propio sistema:

```bash
# 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](https://phpsos.de/es/ratgeber/backdoor-wordpress-finden/) encontrará más detalles.

> **Importante:**
> 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:

```php
define( 'DISALLOW_FILE_EDIT', true );
```

## Qué debería hacer ahora como operador de WordPress

1. 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.
2. Hacer que se conserven los registros del servidor a partir del 20/10/2026.
3. Realizar, o encargar, las comprobaciones anteriores.
4. Actualizar WordPress, los plugins y los temas. Es lo correcto, pero no sustituye al paso 1.
5. 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, `.htaccess` y las cuentas de usuario en busca de puertas traseras.
- Si hay hallazgos, nuestra [eliminación de malware](https://phpsos.de/es/leistungen/malware-entfernung/) 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](https://phpsos.de/es/leistungen/php2shell-soforthilfe/).


## 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.

## Fuentes

- [php.net: avisos de seguridad](https://www.php.net/)
- [Registro de cambios de PHP 8](https://www.php.net/ChangeLog-8.php)
- [WordPress.org](https://wordpress.org/)
- [BSI](https://www.bsi.bund.de/)