Vulnerabilidad crítica en PHP (php2shell): si expones PHP por túnel, actualiza

Qué se divulgó

El 21 de octubre de 2026 el proyecto PHP publicó un aviso de seguridad sobre dos vulnerabilidades en el núcleo del lenguaje: CVE-2026-109618 y CVE-2026-109619, ambas con puntuación 9,2 (CVSS v4.0). Los proveedores apodaron al par php2shell.

Las dos permiten ejecución remota de código sin autenticación, con los privilegios del proceso del servidor web. Dicho de otro modo: el atacante no necesita usuario, contraseña ni sesión válida — alcanzar tu PHP ya es suficiente.

Toda versión de 5.4 hasta 8.5.11 está afectada. Las correcciones son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. PHP 8.1 y anteriores no reciben corrección del proyecto.

Por qué esto importa si usas SuperDMZ

Seamos directos, porque es la parte que nos corresponde. El túnel no crea la vulnerabilidad — ya estaba en tu PHP. Lo que hace el túnel es acabar con la oscuridad que protegía esa máquina. Una aplicación que antes solo respondía en tu red local pasa a responder en una dirección pública, y el escaneo automatizado encuentra direcciones públicas en minutos.

Hoy 141 de los 165 túneles activos de la plataforma están en modo público — 55 de 67 túneles HTTP y 86 de 98 TCP. Es una elección legítima y mucha gente quiere exactamente eso. También es la razón de que exista este aviso.

Cómo comprobar lo que ejecutas

php -v

Una advertencia importante que la mayoría de los avisos omite: en Debian, Ubuntu y derivados, el número de versión no cambia cuando la distribución aplica el parche. Nuestro propio servidor web informa PHP 8.5.4 y ya está corregido, porque la corrección llegó en la revisión del paquete (8.5.4-0ubuntu1.5), no en una versión nueva de PHP. Así que en esos sistemas no juzgues por php -v. Pregúntale al gestor de paquetes:

apt list --upgradable | grep php
apt-get changelog php8.3-common | head

Si el changelog menciona CVE-2026-109618, ese paquete es la corrección. En Windows, macOS, imagen Docker o PHP compilado desde el código fuente, ahí el número de versión sí es la señal correcta — compáralo con las cuatro versiones corregidas de arriba.

Si no puedes actualizar hoy

Esto podemos ofrecerlo nosotros y un aviso genérico no: cambia tu túnel a modo autenticado. En el panel, en el túnel, cambia el modo de acceso de público a autenticado. La dirección pasa a exigir una clave antes de que cualquier tráfico llegue a tu máquina, lo que saca tu PHP del alcance del escaneo no dirigido mientras programas la actualización.

Es una medida temporal, no una corrección. El fallo sigue en tu máquina, y quien tenga la clave sigue alcanzándola. Pero te da la ventana.

Qué hicimos de nuestro lado

Nuestra propia infraestructura estaba afectada y ya fue actualizada:

• Panel de SuperDMZ — PHP actualizado y servicio reiniciado el 21 de octubre.
• Servidor web (sitios y herramientas) — actualizado el mismo día.
• Nodos de los túneles — no afectados: ejecutan Go, sin PHP.
• Servidor de correo — imagen del contenedor reemplazada por la versión con el PHP corregido.

También creamos una comprobación diaria en nuestra monitorización de operación que lee el registro oficial de vulnerabilidades y el canal de seguridad de cada distribución que usamos, para que el próximo caso no dependa de que alguien note un correo. Este lo aprendimos en la práctica: supimos de php2shell porque un proveedor nos escribió.

Fuentes oficiales

No nos creas en los detalles técnicos — y no hagas clic en enlaces de correos sobre seguridad. Escribe la dirección tú mismo:

• php.net/archive/2026.php — el aviso del propio proyecto y los anuncios de las versiones.
• nvd.nist.gov — busca CVE-2026-109618 y CVE-2026-109619.

Si tienes dudas sobre tu caso concreto, responde por el canal de soporte del panel. No pedimos contraseñas ni enviamos enlaces para hacer clic.