PHP prepara una actualización crítica y conviene tener listo el despliegue antes de que llegue. Esta guía explica qué se sabe de PHP2Shell, qué sigue pendiente de confirmar y cómo revisar el PHP que realmente ejecuta tu web.
Estado verificado: 21 de octubre de 2026, 02:49 UTC. Es una evaluación previa al lanzamiento, no una confirmación de que tu servidor esté afectado o protegido.
Qué ha confirmado PHP y cuándo está previsto el parche
El aviso oficial de PHP anuncia dos vulnerabilidades críticas, ambas con CVSS 4.0 de 9.2. La actualización está prevista para el 21 de octubre de 2026 a las 14:00 UTC, con posibilidad de adelanto. PHP publicará los detalles y las versiones afectadas y corregidas junto con el lanzamiento.
En la revisión del registro oficial de cambios todavía no encontramos una versión publicada que confirme la corrección de estos dos CVE. No conviene convertir un número de versión esperado en un parche disponible.
PHP2Shell, CVE-2026-109618 y CVE-2026-109619: qué falta por conocer
La FAQ de watchTowr recoge los identificadores CVE-2026-109618 y CVE-2026-109619 como fallos reportados de ejecución remota de código, o RCE. La propia fuente aclara que el alcance desde PHP 5 en adelante procede de información todavía no confirmada por el fabricante. No tomamos ese reporte como una lista definitiva de instalaciones explotables.
Si se confirma una vía de RCE en una configuración concreta, un atacante podría ejecutar código dentro del contexto permitido al proceso vulnerable. Eso puede ser grave sin implicar acceso root. Por ahora, no atribuimos una causa técnica, una configuración vulnerable concreta ni un método de explotación a estos fallos.
Una demostración pública tampoco establece que todas las webs con PHP sean atacables de la misma manera. Para decidir el alcance de tu entorno hacen falta la versión, la configuración y las condiciones del aviso definitivo. Tampoco presentamos este artículo como evidencia de ataques contra clientes de TERAMONT.
Qué revisar ahora en tu hosting o VPS
La siguiente lista es una propuesta operativa de preparación. No es un detector de PHP2Shell ni una mitigación específica validada para estos CVE.
1. Haz inventario por aplicación, no solo por servidor
Anota dominios, subdominios, API, paneles internos, entornos de pruebas accesibles desde Internet y procesos en segundo plano. Para cada uno registra quién lo administra, de dónde proviene PHP y cómo se actualiza. Incluye contenedores e instalaciones antiguas que todavía reciban tráfico.
En una terminal con PHP disponible puedes empezar con estas consultas:
Tu aplicación PHP, con un plan de mantenimiento claro
Compara recursos para tu proyecto y define quién actualizará el sistema, PHP y sus aplicaciones. Contratar un VPS no sustituye ese mantenimiento.
php --ini
php -v muestra la versión del binario invocado y php --ini identifica sus archivos de configuración. La versión de consola puede ser distinta de la usada por la web. Comprueba también el runtime asignado a cada dominio, pool o contenedor desde la administración de tu entorno. Referencia oficial de las opciones de PHP.
No dejes un archivo público con phpinfo() para hacer esta comprobación: su salida puede revelar rutas, configuración y variables de entorno. Usa información del panel o un diagnóstico restringido y retíralo al terminar. Qué información muestra phpinfo().
2. Identifica quién entrega y aplica la actualización
- Hosting compartido o administrado: pregunta al proveedor qué runtime sirve tus dominios y cómo confirmará el despliegue. Cambiar la versión en un selector no demuestra por sí solo que incluya el arreglo.
- VPS autoadministrado: corresponde a quien administra el sistema actualizar el PHP instalado en él. Una actualización del hipervisor del proveedor no reemplaza esta tarea.
- Paneles como Plesk o cPanel: revisa los paquetes y runtimes gestionados por el panel; pueden coexistir con el PHP del sistema. Sigue el canal de actualización soportado para cada instalación.
- Docker: prepara la reconstrucción con una base que incluya la corrección y el reemplazo de los contenedores. Reiniciar el mismo contenedor no incorpora una imagen nueva. Buenas prácticas de actualización de imágenes de Docker.
3. Comprueba si tu rama tiene soporte
PHP 8.1 terminó su soporte oficial el 31 de diciembre de 2025. PHP 8.0 y las ramas 7.x también están fuera de soporte. No des por hecho que recibirán un nuevo parche upstream. Si dependes de ellas, prepara una migración compatible o exige confirmación concreta de cobertura a tu proveedor de soporte extendido. Ramas sin soporte de PHP.
A la fecha de esta revisión, las ramas estables con soporte oficial son 8.2, 8.3, 8.4 y 8.5. Estar en una rama mantenida no significa tener instalado un parche aún pendiente. Calendario oficial de soporte.
Cómo desplegar el parche cuando esté confirmado
- Lee el aviso definitivo. Identifica los mínimos corregidos o el paquete específico de tu proveedor. No instales archivos de enlaces desconocidos ni versiones de prueba como sustituto de una actualización estable.
- Prepara recuperación y pruebas. Verifica copias recuperables de archivos y base de datos, acceso de administración y un procedimiento de mantenimiento. Prueba cuanto antes las funciones críticas sin alargar innecesariamente la exposición.
- Actualiza el componente correcto. Utiliza el repositorio, panel o imagen correspondiente a cada instalación. Actualizar WordPress, Laravel o Composer no sustituye actualizar el intérprete PHP que los ejecuta.
- Activa el nuevo runtime. Sigue las instrucciones del proveedor para reiniciar o reemplazar los procesos necesarios. No basta con que el paquete figure instalado si los servicios siguen ejecutando el binario anterior.
- Verifica todas las instancias. Comprueba el runtime efectivo de la web y de los workers, y ejecuta pruebas funcionales de acceso, sesiones, formularios y operaciones esenciales. Registra paquete, hora y resultado por instancia.
Atención a los backports: un proveedor puede incorporar una corrección a un paquete sin adoptar la numeración más reciente de PHP upstream. Compara la revisión completa del paquete con su aviso de seguridad, no solo el número principal. Eso no confirma que ya exista un backport para estos CVE. Cómo funcionan los backports de seguridad.
Qué hacer mientras esperas y qué no confundir con protección
Revisa la exposición de servicios que no necesitan ser públicos y prepara una ventana de cambio. Si tu evaluación de riesgo justifica restringir temporalmente una aplicación, documenta el impacto sobre usuarios e integraciones. Estas son medidas generales de reducción de exposición, no una garantía contra una vulnerabilidad cuyos requisitos siguen pendientes.
No apliques cambios de configuración o reglas WAF copiados de rumores como si fueran una solución confirmada. Un firewall, HTTPS, cambiar contraseñas o actualizar plugins no acreditan que el intérprete esté corregido. Si un proveedor publica una mitigación, verifica su alcance, compatibilidad y limitaciones.
Si observas actividad anómala, conserva los registros y sigue tu procedimiento de respuesta a incidentes. Instalar un parche no elimina por sí solo una intrusión previa, y no encontrar alertas tampoco demuestra que nunca hubo compromiso.
Preguntas frecuentes
¿Debo apagar todas mis webs con PHP?
No hay base en las fuentes revisadas para recomendarlo de forma universal. Prioriza inventario, preparación y una decisión de contención acorde con la exposición y el impacto de cada servicio.
¿Actualizar WordPress o Laravel resuelve PHP2Shell?
No sustituye una actualización del runtime. Mantén también la aplicación al día, pero verifica por separado qué PHP ejecuta sus peticiones.
¿Cómo sé que mi proveedor terminó?
Pide el aviso aplicable, la versión o revisión del paquete y confirmación de que ya está activa en los runtimes de tus dominios. “Actualización programada” no es lo mismo que “desplegada y comprobada”.
¿Cambiar de hosting elimina el problema?
Solo si el nuevo entorno cumple los requisitos de corrección y la migración no conserva un runtime vulnerable. El nombre del proveedor o tener un VPS no prueban protección.
El siguiente paso para tu proyecto
Deja hoy una lista breve: aplicaciones, runtime real, responsable, canal de actualización y prueba de aceptación. Esa información permite actuar con rapidez cuando el arreglo esté confirmado y evita olvidar instalaciones secundarias.
Si estás evaluando alojamiento, consulta los planes de VPS de TERAMONT. La elección de recursos debe ir acompañada de responsabilidades claras de mantenimiento. Para entender esa separación, lee qué es un VPS y para qué sirve.
Esta guía se basa en las fuentes enlazadas y en recomendaciones operativas generales. No hemos ejecutado un exploit ni auditado servidores de clientes. El estado del parche debe contrastarse con las fuentes oficiales antes de actuar.
