Una vulnerabilidad crítica en PHP no avisa con tiempo, y lo que decide si pierdes un fin de semana es tener el proceso listo antes. El caso de PHP2Shell, asociado a dos vulnerabilidades críticas de ejecución remota de código anunciadas en octubre de 2026, sirve para entender qué ocurre durante esas primeras horas y cómo preparar una respuesta eficaz.
En este artículo repasamos el alcance de PHP en la web, las dificultades de identificar las versiones afectadas antes de que se publiquen los parches y un plan de respuesta reutilizable. Este análisis refleja la información disponible antes de la publicación prevista de las correcciones. Consulta siempre el aviso oficial del equipo de PHP para confirmar las versiones afectadas y corregidas.
El caso PHP2Shell (octubre de 2026)
El 20 de octubre de 2026, el equipo de PHP anunció una publicación de seguridad urgente prevista para el día siguiente. El aviso oficial indicaba dos vulnerabilidades críticas, ambas con puntuación CVSS v4.0 de 9,2, pero reservaba los detalles técnicos, las versiones afectadas y las versiones corregidas para el anuncio de la release.
- 20 de octubre de 2026: PHP anunció la publicación de seguridad para el día siguiente y recomendó prepararse para actualizar en cuanto estuviera disponible.
- La misma jornada: comenzaron a circular informaciones sobre los posibles fallos y sus identificadores. Algunas fuentes técnicas indicaron que podrían permitir ejecución remota de código; estos detalles debían tratarse como información preliminar hasta la confirmación oficial.
- 21 de octubre de 2026, 14:00 UTC: hora prevista para la publicación de las correcciones. El equipo de PHP se reservó la posibilidad de adelantar la release si se hacían públicos los detalles o aparecían evidencias de explotación activa. En España peninsular, esa hora corresponde a las 16:00 CEST.
CERT-EU publicó también un aviso de seguridad sobre las vulnerabilidades de PHP. La lección principal es que una vulnerabilidad del intérprete no se resuelve necesariamente actualizando WordPress, un plugin o una aplicación Laravel: la corrección debe aplicarse a la versión de PHP que realmente ejecuta la aplicación.
Qué suele pasar en las primeras horas
Durante las primeras horas de una divulgación crítica, las versiones afectadas pueden no estar confirmadas y las fuentes pueden ofrecer información contradictoria. En el caso PHP2Shell circularon distintas estimaciones sobre el alcance, desde ramas antiguas hasta versiones recientes. Estas afirmaciones no deben interpretarse como una lista oficial de versiones vulnerables.
Para tomar decisiones en producción, contrasta las versiones afectadas y corregidas con el aviso oficial y con las comunicaciones del proveedor de hosting o de la distribución utilizada. Las ramas que han llegado al final de su ciclo de soporte plantean un problema adicional: pueden no recibir una corrección oficial. Eso no significa que estén a salvo, sino que podrían seguir expuestas sin una actualización disponible para esa rama.
Mientras no exista información técnica suficiente, lo prudente es inventariar todos los sistemas PHP y priorizar los servicios expuestos a Internet, especialmente los que utilizan versiones antiguas o cuyo mantenimiento depende de terceros.
Si gestionas varias webs, esta preparación debería formar parte de tu rutina de administración. En nuestro artículo sobre la importancia del soporte experto en hosting explicamos por qué conocer el entorno real de ejecución es tan importante como disponer de un alojamiento adecuado.
Los números: cuánto PHP hay en el mundo
Según los datos de W3Techs citados para agosto de 2026, PHP estaba presente en el 70,3 % de los sitios web cuyo lenguaje de servidor podía identificarse. En octubre de 2025, la proporción era del 73,2 %. Ruby, uno de los siguientes lenguajes de servidor en la clasificación, se situaba alrededor del 6,7 %.
Por versiones, el mismo recuento mostraba:
- PHP 8: el 63,1 % de los sitios que utilizaban PHP, frente al 52,3 % de octubre de 2025.
- PHP 7 y anteriores: aproximadamente el 37 % del parque contabilizado.
- PHP 8.0 y 8.1: ramas que ya habían llegado al final de su soporte de seguridad ordinario y seguían presentes en las estadísticas de 2026.
Otra estimación publicada por Mallory en octubre de 2026 contabilizaba unas 884.000 máquinas expuestas en Internet con PHP 8.1 o anterior, aproximadamente el 59 % de las que mostraban una versión identificable. Estas cifras no son un censo completo: dependen de la metodología, de la visibilidad de las versiones y de los criterios utilizados.
Puedes consultar los datos de W3Techs sobre el uso de PHP y su histórico de versiones de PHP 8.
Plan de respuesta ante una vulnerabilidad crítica
Lo primero es saber qué tienes y dónde. No se puede actualizar de forma fiable lo que no está inventariado. Este es el orden de actuación que recomiendo:
- Inventario. Identifica servidores, cuentas de hosting, contenedores y aplicaciones. Comprueba la versión mediante
php -v, los paquetes instalados y las herramientas de administración. La versión de PHP CLI puede ser distinta de la que utiliza PHP-FPM o el servidor web. - Prioriza la exposición. Marca los sistemas accesibles desde Internet, las aplicaciones críticas y las instalaciones que utilizan ramas antiguas o sin soporte. No dependas únicamente de las cabeceras HTTP para determinar si un servidor está actualizado.
- Prepara la intervención. Avisa a los clientes cuando sea necesario, verifica las copias de seguridad y prepara un entorno de pruebas. Define quién puede aplicar la actualización y cómo se comprobará que ha funcionado.
- Actualiza en cuanto exista una corrección aplicable. Utiliza las versiones corregidas que indique el aviso oficial o el proveedor de tu distribución. En un hosting gestionado, confirma qué paquetes se han actualizado y qué versión utiliza cada sitio.
- Comprueba las aplicaciones. En WordPress, revisa plugins, temas e integraciones que puedan presentar incompatibilidades. En Laravel, valida las dependencias y ejecuta las pruebas de la aplicación después del cambio de runtime.
composer auditayuda a detectar dependencias vulnerables conocidas, pero no sustituye la actualización del intérprete. - Migra las ramas sin soporte. Si no existe una corrección adecuada para la versión instalada, planifica el traslado a una rama mantenida. El destino debe elegirse según la compatibilidad del proyecto y el calendario oficial de soporte.
- Vigila después de actualizar. Revisa registros de acceso y errores, busca archivos inesperados o modificados en directorios de subida y comprueba la integridad de la aplicación. Si hay indicios de explotación, activa el procedimiento de respuesta a incidentes: actualizar no demuestra por sí solo que el sistema no haya sido comprometido.
Para ampliar este procedimiento, consulta nuestra guía sobre cómo actuar cuando los bots atacan WordPress, donde abordamos la revisión de registros, la protección temporal y la recuperación de una web sometida a actividad maliciosa.
El problema de las ramas sin soporte
Muchas aplicaciones siguen ejecutándose sobre versiones de PHP que ya no reciben actualizaciones de seguridad ordinarias. Cuando se publica una vulnerabilidad crítica, las instalaciones que utilizan ramas antiguas pueden quedarse sin una corrección oficial.
Un firewall de aplicaciones web (WAF), las restricciones de acceso y otras medidas de protección pueden reducir la exposición en determinadas circunstancias, pero no equivalen a corregir el intérprete. Tampoco conviene confiar en un ajuste de php.ini como solución definitiva sin una recomendación técnica específica del proveedor.
La salida a largo plazo es migrar a una versión mantenida y compatible con la aplicación. Puede requerir revisar dependencias, código antiguo e integraciones, pero permite recuperar una base de mantenimiento sostenible.
Si tu aplicación utiliza Laravel, revisa también la gestión de secretos y la configuración del entorno. En nuestro artículo sobre la seguridad del archivo .env de Laravel explicamos por qué una configuración incorrecta puede añadir riesgos independientes a los de una vulnerabilidad del intérprete.
Una web que lleva años funcionando sobre una versión antigua de PHP no es necesariamente estable por el mero hecho de que no falle. Puede acumular deuda técnica, dependencias incompatibles y riesgos de seguridad que se hacen visibles cuando aparece una incidencia crítica.
Prepárate antes de la próxima vulnerabilidad
- Mantén un inventario actualizado. Registra cada servidor, aplicación, versión de PHP y responsable de mantenimiento. Actualízalo cuando cambie el entorno.
- Utiliza versiones con soporte. Comprueba periódicamente el calendario de mantenimiento y prepara las migraciones antes de que una rama llegue al final de su vida útil.
- Automatiza las comprobaciones. Ejecuta auditorías de dependencias con herramientas como
composer audity establece alertas para los avisos relevantes. Estas comprobaciones complementan, pero no sustituyen, la vigilancia de las actualizaciones de PHP. - Ten copias verificadas. No basta con que el sistema informe de que se ha creado una copia: comprueba que puede restaurarse y que incluye los datos necesarios.
- Prepara un entorno de pruebas. Una actualización urgente debe poder validarse sin poner innecesariamente en riesgo la producción.
- Define responsabilidades. Deja claro quién gestiona PHP, quién administra el servidor y quién debe autorizar o ejecutar una intervención urgente.
En WordPress, mantener el core, los temas y los plugins al día es igualmente importante. Puedes complementar esta revisión con nuestra guía sobre cómo recuperar el tráfico perdido en WordPress, que incluye comprobaciones técnicas relacionadas con errores, rendimiento y configuración del sitio.
Conclusión: la seguridad empieza antes del aviso
Una vulnerabilidad crítica en PHP se gestiona mejor cuando la infraestructura ya está inventariada, las copias de seguridad están verificadas y las actualizaciones se pueden aplicar con rapidez.
El caso PHP2Shell vuelve a poner de manifiesto la importancia de mantener las versiones con soporte, comprobar qué runtime ejecuta realmente cada aplicación y no confundir las medidas de mitigación con una corrección definitiva.
Si gestionas webs de clientes y necesitas revisar las versiones instaladas, planificar una migración o preparar una intervención de mantenimiento, puedes consultar nuestro servicio de programación y soporte mediante paquetes de horas.
La mejor respuesta ante una vulnerabilidad crítica no empieza cuando se publica el parche. Empieza mucho antes, con una infraestructura que conoces y que puedes actualizar sin improvisar.