El 21 de octubre de 2026, PHP publicó correcciones urgentes para CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. La prioridad es actualizar. Después, conviene revisar por qué una aplicación interna sigue siendo accesible directamente desde Internet.

Patch first. Reduce exposure permanently. Primero, aplicar los parches. Después, reducir la exposición de forma permanente.

Qué ha confirmado el proyecto PHP

El aviso oficial de PHP identifica dos problemas en el runtime, no en el código de una aplicación concreta:

Vulnerabilidad	Problema descrito por PHP	Impacto potencial
CVE-2026-109618	La gestión de una condición de falta de memoria puede dejar datos internos de la petición parcialmente inicializados, que la limpieza posterior trata como válidos.	Ejecución remota de código sin autenticación.
CVE-2026-109619	Un estado interno asociado a una petición puede sobrevivir a la liberación de su memoria y reutilizarse en una petición posterior del mismo worker.	Ejecución remota de código sin autenticación.

El preaviso del 20 de octubre asigna a ambas una puntuación CVSS v4.0 de 9,2: críticas. El riesgo afecta a instalaciones que sirven peticiones web, incluyendo PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

PHP considera mod_php la configuración de mayor riesgo: se ha demostrado una explotación mediante una petición no autenticada antes de que se ejecute el código de la aplicación. Esa demostración específica no debe extrapolarse como una vía idéntica para todos los runtimes. Tampoco implica, por sí sola, que se hayan confirmado ataques en producción.

Versiones corregidas: actualizar y verificar

Rama	Versión corregida publicada el 21 de octubre
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Instala esas versiones o una actualización posterior que incluya las correcciones. Si utilizas paquetes de una distribución o un proveedor LTS, comprueba su aviso: puede incorporar un parche sin adoptar exactamente la numeración del proyecto PHP.

PHP 8.1 y anteriores ya no reciben mantenimiento ordinario del proyecto. El equipo ha facilitado backports mínimos de emergencia para 7.4, 8.0 y 8.1; esto no equivale a recuperar el soporte de esas ramas. Confirma el parche con tu proveedor o migra a una rama soportada.

Después de actualizar, reinicia los procesos que corresponda y verifica el runtime que realmente atiende las peticiones web. La versión de la consola puede ser distinta de la usada por PHP-FPM, Apache o un contenedor.

Un formulario de login no siempre protege el runtime

Un ERP, CRM, intranet, plataforma de documentación o panel interno puede estar publicado mediante un puerto 443 abierto. Aunque tenga un buen login, primero debe procesar la petición el servidor web y, en determinados despliegues, PHP.

Internet → servidor web público → PHP → login de la aplicación

Si el fallo se alcanza antes del código de la aplicación, ese login no es la barrera que esperamos. Esto no significa que todas las aplicaciones PHP sean explotables de la misma manera: significa que la exposición del runtime merece atención independiente de la autenticación propia de la aplicación.

Qué cambia con ConnectaSec Access

Para una aplicación destinada únicamente a empleados o proveedores autorizados, el modelo puede ser diferente: mantener el origen en una red privada y controlar el acceso antes de llegar a él.

Usuario → identidad y política de acceso
        → conexión segura → conector → aplicación privada

Con ConnectaSec Access, un despliegue correctamente configurado puede usar conectividad saliente sin publicar puertos entrantes en el servidor de la aplicación. La identidad y las políticas determinan quién puede acceder al recurso; la integración con Microsoft 365 ayuda a gestionar usuarios y grupos. Las capacidades concretas de autenticación y MFA dependen de la configuración y de los servicios de identidad utilizados.

La condición importante es cerrar también los accesos directos al origen: DNS alternativos, direcciones públicas antiguas, reglas de firewall y otros caminos de acceso. Poner una capa delante sin retirar el acceso directo deja abierta la vía original.

Access no corrige la vulnerabilidad

No sustituye el parcheado. El servidor sigue siendo vulnerable hasta que se actualiza. Un usuario autorizado malicioso, un dispositivo comprometido o un acceso alternativo mal configurado pueden seguir representando un riesgo.

Lo que cambia es la posibilidad de que un atacante anónimo de Internet contacte directamente con el backend privado. Esto reduce la superficie de ataque y resulta especialmente útil mientras se organiza una actualización urgente, pero no convierte la instalación vulnerable en segura.

PHP publica medidas temporales que reducen determinadas vías de explotación y advierte expresamente que solo la actualización es una solución completa. No apliques cambios de memoria o de procesamiento de peticiones a ciegas: tienen implicaciones de disponibilidad y deben revisarse con el equipo responsable.

Cinco acciones para empresas y MSPs

Inventariar servidores, contenedores y aplicaciones que ejecutan PHP y comprobar cuáles están expuestos.
Actualizar el runtime o instalar el parche confirmado por el proveedor, sin esperar a implantar otra capa de seguridad.
Verificar los procesos web activos y revisar registros ante indicios de compromiso; actualizar no elimina una intrusión previa.
Retirar la exposición innecesaria de aplicaciones internas, comprobando que no queden accesos directos al origen.
Limitar y revisar los permisos de empleados y proveedores, con acceso únicamente a los recursos necesarios.

Una web pública necesita seguir siendo pública. Un ERP interno o un panel de administración no necesariamente. Consulta la arquitectura de ConnectaSec y el enfoque de acceso remoto seguro para evaluar esta separación.

Las aplicaciones privadas deberían seguir siendo privadas

Este incidente recuerda que una vulnerabilidad en una capa inferior puede comprometer una aplicación aunque su login esté bien diseñado. Actualizar es imprescindible; reducir la exposición es una defensa adicional y permanente.

Solicita una demo para revisar el acceso a tus aplicaciones internas. No se trata de sustituir los parches, sino de decidir quién puede llegar al servidor.

Fuentes oficiales

Información revisada el 22 de octubre de 2026. Se utiliza el identificador de las CVE: «PHP2Shell» no figura como denominación oficial en los avisos citados.