Web en PHP o WordPress: ¿qué revisar después de PHP2Shell?

Lo primero es comprobar qué versión de PHP sirve de verdad tu web en producción y actualizarla a una corregida: 8.5.12, 8.4.27, 8.3.36, 8.2.35 o posterior, o a un paquete parcheado de tu distribución o tu hosting. Después, repasa lo básico que PHP2Shell ha vuelto a poner sobre la mesa: actualizaciones de WordPress y plugins, cuentas de administrador, copias de seguridad y quién responde de cada web.

Abajo tienes solo hechos verificados con fechas, una checklist práctica y una tabla de responsables que conviene rellenar esta semana.

En resumen

• El 21 de octubre de 2026 el proyecto PHP publicó correcciones para dos vulnerabilidades críticas conocidas juntas como PHP2Shell. ^[1]
• Afectan a las instalaciones de PHP que atienden peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed. ^[1]
• Se vieron intentos de ataque antes de que salieran las correcciones. ^{[5] [6]}
• No hay una solución alternativa completa. Un filtro de peticiones web (WAF) da tiempo, pero no sustituye la actualización. ^{[1] [4]}
• La versión de la documentación no garantiza nada. Mira lo que corre en el servidor y quién responde de cada web.

Qué pasó: hechos con fechas

El 20 de octubre de 2026 el proyecto PHP anunció una versión de seguridad crítica, y el 21 de octubre publicó las versiones corregidas y un aviso. Las dos vulnerabilidades permiten ejecutar código ajeno en el servidor (RCE, ejecución remota de código), y el equipo de PHP las valoró con 9,2 sobre 10 en CVSS v4. ^[1]

Qué más se sabe a 23 de octubre de 2026:

• Quién lo encontró. Wiz Research y Calif, con participación de OpenAI. Wiz escribe que las versiones afectadas llegan hasta PHP 5.4 y que en sus pruebas ejecutaron código sin iniciar sesión en WordPress, Drupal y Joomla. ^[4]
• Ramas antiguas. No hay versiones oficiales para PHP 8.1 y anteriores; el equipo de PHP publicó solo parches de código fuente para 7.4, 8.0 y 8.1. ^[1] Distribuciones como Ubuntu y Debian publican parches con los números de versión antiguos. ^[5]
• Ataques. Según Sansec, Cloudflare informó de los primeros ataques el 21 de octubre a las 07:43 UTC, antes de las correcciones. El 22 de octubre Sansec añadió que la explotación masiva parece menos probable de lo que se pensaba y que los exploits públicos no funcionan contra una instalación por defecto. ^[5] Tenable escribe que Amazon vio intentos de ataque ya el 17 de octubre y que, a 22 de octubre, estas vulnerabilidades no estaban en el catálogo CISA KEV (la lista de vulnerabilidades que se sabe que se explotan). ^[6]
• Medidas temporales. El equipo de PHP recomienda desactivar session.upload_progress.enabled y limitar post_max_size, pero dice claramente que sin actualizar no hay protección completa. El 23 de octubre un aviso adicional repitió el consejo sobre session.upload_progress.enabled. ^[1]

Qué versión de PHP corre de verdad en la web

La documentación, el contrato con el proveedor y la memoria del administrador no sirven aquí. Comprueba el servidor:

• WordPress. En el panel: Herramientas, Salud del sitio, Información, sección Servidor. Ahí aparece la versión de PHP que sirve esa web concreta.
• Hosting. El panel de control muestra la versión de cada web por separado. En una misma cuenta, distintas webs suelen usar versiones distintas.
• Servidor propio. El comando php -v muestra la versión de la línea de comandos, mientras que la web puede ir por PHP-FPM con otra versión. Mira el paquete que realmente atiende el servidor web.
• Número de versión y parche. En Ubuntu, Debian o sistemas parecidos el número puede seguir siendo antiguo aunque el parche esté instalado. Revisa el registro de cambios del paquete o pide al hosting que confirme la corrección por escrito.

Fíjate aparte en PHP 8.2: el soporte de seguridad de esa rama termina el 31 de diciembre de 2026. ^[7] WordPress recomienda PHP 8.3 o superior. ^[8]

Por qué un WAF no sustituye la actualización

Un WAF (un filtro que descarta peticiones web sospechosas) puede bloquear variantes conocidas del ataque. Sansec describe una regla temporal que bloquea cierto tipo de peticiones y avisa de que rompe la subida de archivos. ^[5] Wiz dice claramente que actualizar PHP sigue siendo la única corrección completa. ^[4] El filtro te da unos días para actualizar, pero no te libra de hacerlo.

WordPress: qué revisar además de PHP

PHP2Shell está en el propio PHP, pero a las webs se entra normalmente por el punto más débil, justo lo que busca un pentest. Repasa lo básico:

• Núcleo, plugins, temas. Actualiza todo lo que tenga actualización. Antes, haz una copia de seguridad. ^[9]
• Plugins y temas sin uso. Un plugin desactivado sigue siendo archivos en el servidor. Si no lo necesitas, bórralo.
• Administradores. Revisa la lista de usuarios con permisos de administrador. Antiguos empleados, proveedores de un proyecto pasado, cuentas compartidas como «admin»: quita todo lo que sobre.
• Acceso en dos pasos. En WordPress se añade con un plugin, y la documentación de WordPress enumera opciones. ^[10] Actívalo al menos para todos los administradores.
• Copias de seguridad. No compruebes que la copia existe, sino que se puede restaurar la web desde ella. Pruébalo en un servidor aparte.

Quién responde de cada web

El PHP antiguo suele vivir no en la web principal, sino en una landing de una campaña de hace tres años, una copia de pruebas o un blog que hizo un antiguo proveedor. Haz una tabla con todas las webs de la empresa y rellénala con hechos, no con suposiciones:

Las filas con «nadie» y «desconocida» son tu riesgo. Esa web o recibe un responsable o se apaga.

Checklist para dueños e IT

• Todas las webs y subdominios de la empresa están en una lista.
• Cada web tiene un responsable con nombre.
• La versión de PHP se ha comprobado en el servidor, no en la documentación.
• PHP está actualizado a 8.5.12, 8.4.27, 8.3.36, 8.2.35 o posterior, o el hosting ha confirmado el parche por escrito.
• Las webs con PHP 8.1 o anterior tienen un plan de migración.
• El núcleo de WordPress, los plugins y los temas están actualizados.
• Los plugins y temas sin uso están borrados.
• La lista de administradores está revisada y las cuentas sobrantes eliminadas.
• El acceso en dos pasos está activo para todos los administradores.
• La restauración desde copia de seguridad está probada.
• Las medidas temporales (WAF, ajustes de PHP) están anotadas como temporales, con fecha de actualización.

Descargar la lista de preparación (PDF)PDF · A4

Cuándo hace falta una revisión externa

Si tienes muchas webs y nadie sabe con seguridad qué está expuesto a internet, empieza por una revisión externa de seguridad: muestra qué webs y servicios tuyos se ven desde fuera. Para encontrar de forma sistemática versiones antiguas y vulnerabilidades conocidas en un perímetro acordado, encaja un Vulnerability Assessment. Si la web tiene área de clientes, pagos o datos personales, un pentest llega más hondo. Cualquier prueba activa la hacemos solo después de acordar el alcance y firmar la autorización por escrito.

Preguntas frecuentes

Mi web es WordPress. ¿Basta con actualizar WordPress?

No. PHP2Shell está en el propio PHP, no en WordPress. La actualización de WordPress hace falta, pero PHP lo actualiza aparte tu hosting o tu administrador.

El hosting dice que todo está actualizado, pero el panel muestra una versión antigua. ¿Es un problema?

No necesariamente. Las distribuciones suelen aplicar el parche sin cambiar el número de versión. Pide al hosting que confirme por escrito que están instaladas las correcciones de las dos vulnerabilidades PHP2Shell del aviso del 21 de octubre.

Tenemos PHP 7.4. ¿Qué hacemos?

No hay versiones oficiales para esa rama. Un paquete parcheado de tu distribución ayuda de momento, pero la solución real es pasar a una versión con soporte. Planifícalo ya.

¿Nos protege Cloudflare u otro WAF?

Puede descartar variantes conocidas del ataque y darte tiempo. Pero sin actualizar PHP no hay protección completa; lo dicen tanto el equipo de PHP como los investigadores.

¿Cómo saber si ya han atacado la web?

Wiz aconseja vigilar peticiones raras de subida de archivos seguidas de errores de límite de memoria, errores 500 repetidos y reinicios sin explicación de procesos de PHP. Si ves algo así, busca a un especialista para investigarlo, no te limites a actualizar.

Referencias

1. PHP News Archive 2026: Security advisory, critical remote code execution vulnerabilities php.net
2. PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) github.com
3. PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) github.com
4. Wiz Research: PHP2Shell wiz.io
5. Sansec: PHP2Shell: PHP RCE (CVE-2026-109618, CVE-2026-109619) sansec.io
6. Tenable: php2shell FAQ tenable.com
7. PHP: Supported Versions php.net
8. WordPress: Requirements wordpress.org
9. WordPress: Updating WordPress wordpress.org
10. WordPress: Two Step Authentication developer.wordpress.org