Si administras servidores o sitios web, seguramente ya viste las noticias sobre las nuevas vulnerabilidades en PHP.
Entiendo que quieras saber si tu servidor está en riesgo, qué hacer hoy mismo y si necesitas revisar algo más allá de tu código. En esta guía te explicamos qué es PHP2Shell, por qué afecta a casi cualquier instalación y qué pasos seguir para proteger tu infraestructura.
Lo que pasó con PHP2Shell este 21 de octubre
El 21 de octubre de 2026 se hicieron públicas dos vulnerabilidades en PHP, identificadas como CVE-2026-109618 y CVE-2026-109619. Ambas tienen una calificación CVSS de 9.2 sobre 10, lo que las coloca en el rango de severidad muy alta.
Lo que hace especial a este caso es el origen del hallazgo. Investigadores de Wiz y de Calif, según su publicación, encontraron los fallos casi al mismo tiempo, con ayuda de modelos de IA de frontera, principalmente Gemini 4 Argon y Sol 5.6.
Por qué el problema es PHP, no tu código
Aquí está la parte que más confunde. Estas vulnerabilidades están en el propio lenguaje, no en las aplicaciones que se escriben con él. Eso significa que la calidad de tu código no te protege: cualquier instalación de PHP de los últimos 15 años puede verse afectada. Incluso un simple “hola mundo” expuesto a internet es vulnerable.
Qué puede hacer un atacante
Las fallas permiten ejecutar código sin autenticarse en cualquier servidor que atienda peticiones web con PHP. Desde ahí, un atacante puede tumbar el servicio con ataques de denegación de servicio o extraer información.
Lo más delicado es que el código malicioso corre con los mismos permisos que el proceso de PHP. En la práctica, eso da acceso a la base de datos, a las API keys, a los archivos de configuración y a cualquier secreto que el proceso pueda leer.
Actualiza PHP: es la única protección completa
La solución de fondo es actualizar PHP a las versiones más recientes, que ya fueron publicadas. Puedes revisar el aviso oficial en php.net. Ningún parche parcial reemplaza esta acción.
Si no puedes actualizar de inmediato, existen dos medidas temporales. La primera es el WAF que Cloudflare desplegó para sus clientes gratuitos y de pago. Ayuda, pero no ofrece una garantía total. La segunda, más drástica, es dar de baja el sitio para que las peticiones no lleguen a tu servidor mientras actualizas.
Rota contraseñas, API keys y secretos
Si tu servidor tenía PHP expuesto, conviene asumir que alguien pudo haber leído sus secretos. Rota contraseñas de bases de datos, API keys, tokens y cualquier credencial que el servidor utilice.
Presta atención a las contraseñas que reutilizas en varios sitios. Si una de ellas estuvo en un servidor comprometido, cámbiala en todos los lugares donde la uses.
Revisa si PHP sigue activo en tu servidor
Aunque tus sitios no usen PHP, vale la pena verificar si el lenguaje está instalado o si algún componente lo ejecuta. Tener PHP instalado sin necesidad es un riesgo innecesario, así que si nada lo requiere, desinstálalo.
Apache
Apache puede ejecutar PHP de dos formas: cargando mod_php dentro del propio servidor o enviando las peticiones a php-fpm mediante proxy_fcgi. Revisa ambas. Desactivar solo una no alcanza.
nginx
nginx nunca ejecuta PHP por sí mismo. Siempre delega ese trabajo a un proceso externo, normalmente php-fpm, a través de la directiva fastcgi_pass. Busca esa directiva en la configuración que está cargando realmente el servidor, no solo en los archivos que tienes a la vista.
SEO estratega y redactor de contenidos especializado en temas de tecnología. Experto en crear estrategias de contenido que comunican complejidad técnica de forma clara y accesible.
