Una vulnerabilidad de día cero es una falla de seguridad que se conoce antes de que exista un parche para corregirla, y una empresa en México responde bien a ella cuando ya sabe qué expone a internet, quién decide en las primeras horas y cuánto tarda en aplicar la corrección.
Este artículo es para la dirección general de empresas medianas en México cuyo sitio web, tienda en línea, portal de clientes o sistema interno depende de software de terceros, que es casi cualquier empresa que vende o cobra por internet. Parte de un caso de octubre de 2026, PHP2Shell, y se concentra en lo que importa a quien decide: qué riesgo corre su operación, qué preguntas debe poder contestar hoy y cómo se prepara una empresa para actuar en horas y no en semanas cuando aparezca la siguiente vulnerabilidad de día cero.
En resumen
- En octubre de 2026, dos vulnerabilidades críticas de PHP, conocidas como PHP2Shell, se hicieron públicas un día antes de que existiera la corrección oficial.
- Según el Data Breach Investigations Report 2025 de Verizon, la explotación de vulnerabilidades fue el punto de entrada en 20% de las brechas analizadas.
- El mismo informe encontró que las organizaciones tardaron una mediana de 32 días en corregir por completo las vulnerabilidades de sus dispositivos perimetrales, y solo corrigieron cerca de 54%.
- Una vulnerabilidad de día cero no se previene con una herramienta: se contiene con inventario, con un responsable con autoridad para decidir y con validación técnica después del parche.
Qué pasó con PHP2Shell, la falla que expuso a casi todos los sitios web con PHP
PHP2Shell es el nombre de dos vulnerabilidades críticas en PHP, el lenguaje con el que funcionan 69.1% de los sitios web cuyo lenguaje de servidor se conoce, según W3Techs en noviembre de 2026. Las dos pueden permitir que un tercero sin usuario ni contraseña ejecute código en el servidor que aloja el sitio web.
Los detalles de las fallas se filtraron el 20 de octubre de 2026, antes de la fecha de divulgación coordinada, y el proyecto PHP publicó las versiones corregidas al día siguiente, según su aviso de seguridad del 21 de octubre de 2026. La Agencia de Ciberseguridad y Seguridad de Infraestructura de Estados Unidos (CISA) pidió aplicar el parche de inmediato y el 26 de octubre agregó las dos vulnerabilidades a su catálogo de vulnerabilidades explotadas, que solo incluye fallas con explotación confirmada.
Lo que vuelve a PHP2Shell un caso de estudio para cualquier empresa es dónde vive la falla: en el motor que ejecuta el sitio web, no en el código del sitio web. Una empresa con su sitio web bien programado y actualizado estaba igual de expuesta, porque, como explicó The Hacker News, actualizar una aplicación como WordPress no actualiza la versión de PHP que corre debajo de ella.
Qué es una vulnerabilidad de día cero (zero day)
Una vulnerabilidad de día cero, o zero day, es una falla de seguridad que actores maliciosos conocen o pueden aprovechar antes de que el fabricante publique la corrección. El nombre viene de los días que el fabricante tuvo para corregirla: cero. Mientras no existe el parche, la única defensa de una empresa es lo que ya tenía preparado antes de la alerta.
Estos son los términos que aparecen en cada alerta de seguridad y que la dirección de una empresa necesita leer sin intermediarios:
- Vulnerabilidad de día cero
- Falla de seguridad conocida o explotada antes de que exista una corrección oficial del fabricante.
- Parche
- Actualización del fabricante que corrige la falla. Existe, pero no protege a nadie hasta que alguien la instala.
- CVE (Common Vulnerabilities and Exposures)
- Identificador público de cada vulnerabilidad, como CVE-2026-109618, una de las dos de PHP2Shell. Permite saber con precisión de qué falla habla una alerta.
- CVSS (Common Vulnerability Scoring System)
- Escala de gravedad de 0 a 10. Las dos vulnerabilidades de PHP2Shell recibieron 9.2, calificación crítica.
- Catálogo de vulnerabilidades explotadas de CISA
- Lista pública de fallas con explotación confirmada. Cuando una vulnerabilidad entra a ese catálogo, el riesgo dejó de ser teórico.
Por qué el riesgo no termina cuando sale el parche
El riesgo de una vulnerabilidad de día cero no termina cuando el fabricante publica el parche, porque la mayoría de las empresas tarda semanas en instalarlo. Según el Data Breach Investigations Report 2025 de Verizon, las organizaciones corrigieron por completo solo cerca de 54% de las vulnerabilidades de sus dispositivos perimetrales, y tardaron una mediana de 32 días en hacerlo.
El mismo informe de Verizon encontró que la explotación de vulnerabilidades fue el punto de entrada en 20% de las brechas analizadas, 34% más que en la edición anterior, impulsada en parte por vulnerabilidades de día cero. Para quien busca entrar a una empresa, la ventana entre la alerta y el parche instalado es el momento de mayor oportunidad.
En el caso de PHP2Shell, esa ventana es aún más larga para los sitios web que corren en versiones antiguas. El proyecto PHP dejó de publicar actualizaciones para PHP 8.1 y versiones anteriores, y según W3Techs, uno de cada tres sitios web con PHP todavía funciona en una versión anterior a PHP 8. Una empresa en esa situación no tiene un parche que instalar: tiene una migración pendiente.
Cuánto le cuesta a una empresa mediana enterarse tarde
Una empresa mediana que se entera tarde de una vulnerabilidad de día cero no pierde solo un servidor: pierde la operación que depende de él y la información que pasó por él. En PHP2Shell, el riesgo incluía la lectura de la memoria del servidor, donde pueden estar contraseñas, credenciales de acceso y llaves de otros sistemas, según la descripción técnica publicada por The Hacker News.
Imagine que su tienda en línea o su portal de clientes corre sobre PHP y que nadie en su empresa sabe en qué versión. La alerta sale un martes, su proveedor de hospedaje la aplica dos semanas después y, en ese intervalo, alguien obtiene las credenciales de la base de datos de clientes. El costo ya no es técnico: son días de venta detenida, la notificación a clientes y la conversación con el corporativo que le exige evidencia de control.
Ese costo se puede medir en pesos antes de que ocurra. Lo explicamos con detalle en cuánto cuesta una hora de operación detenida en México. La diferencia entre un incidente de horas y uno de semanas casi nunca está en la herramienta; está en cuánto tiempo pasa entre la alerta y la decisión.
Cinco preguntas que la dirección debe poder contestar hoy
La dirección de una empresa no necesita saber corregir una vulnerabilidad de día cero, pero sí necesita poder contestar estas cinco preguntas antes de la siguiente alerta. Si alguna respuesta es "no sé", ahí está el riesgo:
- ¿Qué tiene su empresa expuesto a internet? El sitio web, la tienda en línea, el portal de clientes, el correo electrónico y los accesos remotos. Sin esa lista, nadie puede saber si una alerta le aplica.
- ¿Sobre qué software corre cada uno y quién lo actualiza? Su equipo, su proveedor de hospedaje o quien construyó el sitio web. Si la respuesta es "creo que el proveedor", no hay responsable.
- ¿Cuánto tardó su empresa en aplicar el último parche crítico? Si nadie lo sabe, el tiempo real se parece más a los 32 días de la mediana de Verizon que a las horas que exige una vulnerabilidad de día cero.
- ¿Quién tiene autoridad para apagar un sistema mientras no hay parche? CISA recomendó desconectar los sistemas con PHP que no pudieran actualizarse. Esa decisión cuesta ventas y alguien con autoridad debe poder tomarla en minutos.
- ¿Cómo comprueba su empresa que el parche funcionó? Instalar una actualización no es lo mismo que cerrar la exposición. Sin una validación posterior, la empresa supone que está protegida.
Cómo ayuda Sentelius a prevenir y responder ante una vulnerabilidad de día cero
Sentelius ayuda a las empresas medianas en México a convertir esas cinco preguntas en respuestas escritas antes de la alerta, y a tener a alguien con criterio técnico y autoridad del lado de la empresa cuando la alerta llega. Sentelius integra arquitectura tecnológica y ciberseguridad en una sola visión, así que la respuesta no se queda en el parche: considera qué pieza de la operación depende del sistema afectado.
Con el programa de vCISO, Sentelius asume la dirección de la ciberseguridad de su empresa bajo ISO 27001 y el NIST Cybersecurity Framework, de modo que las cinco preguntas anteriores tengan una respuesta escrita y un responsable antes de la siguiente alerta. Los programas Manager y Executive incluyen disponibilidad de respuesta urgente fuera del horario habitual, que es justamente cuando suelen publicarse estas alertas.
Con el pentesting de Sentelius, que combina escaneo automatizado con análisis manual bajo PTES, OWASP Testing Guide v4.2 y NIST SP 800-115, su empresa comprueba que la corrección cerró la exposición. Cada hallazgo se valida manualmente antes de reportarse, con su calificación de gravedad, su riesgo financiero y un procedimiento de reescaneo.
Preguntas frecuentes
¿Qué es una vulnerabilidad de día cero?
Una vulnerabilidad de día cero es una falla de seguridad que actores maliciosos conocen o pueden aprovechar antes de que el fabricante publique una corrección. Se llama así porque el fabricante tuvo cero días para corregirla. Mientras no existe el parche, una empresa solo cuenta con lo que preparó antes: inventario, responsables y capacidad de decidir rápido.
¿Qué es zero day en ciberseguridad?
En ciberseguridad, zero day es el término en inglés para una vulnerabilidad de día cero: una falla conocida o explotada antes de que exista su corrección. Un zero day exploit es la técnica que aprovecha esa falla. El término también se usa para el ataque que ocurre en ese periodo sin parche, cuando la empresa todavía no puede actualizar.
¿Mi sitio web está en riesgo por PHP2Shell?
Un sitio web está en riesgo por PHP2Shell si funciona con PHP en una versión anterior a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, que son las corregidas por el proyecto PHP. Las versiones 8.1 y anteriores ya no reciben actualizaciones oficiales. Actualizar WordPress u otra aplicación no actualiza PHP: eso depende del servidor o del proveedor de hospedaje.
¿Cuánto cuesta una vulnerabilidad de día cero en México?
No existe una cifra única de lo que cuesta una vulnerabilidad de día cero a una empresa en México. El costo depende de qué sistema queda expuesto, cuánto tiempo pasa entre la alerta y la corrección y qué información pasa por ese sistema. Incluye la operación detenida, la notificación a clientes y la evidencia que exigen clientes corporativos y aseguradoras.
¿Qué debe hacer una empresa si no puede aplicar el parche de inmediato?
Una empresa que no puede aplicar el parche de inmediato debe reducir la exposición del sistema afectado mientras lo corrige. En el caso de PHP2Shell, CISA recomendó desconectar de internet los sistemas que no pudieran actualizarse. Esa decisión le corresponde a alguien con autoridad, porque detiene ventas u operación y debe tomarse en minutos.
Solicite un programa que responda antes de la siguiente alerta
Si su empresa no puede contestar hoy las cinco preguntas de este artículo, la siguiente vulnerabilidad de día cero la encontrará sin inventario y sin un responsable con autoridad para decidir. Conozca el programa de vCISO de Sentelius y agende una conversación sin costo con un consultor senior para definir el alcance que necesita su operación.
Prepare a su empresa para responder en horas, no en semanas
El programa de vCISO pone dirección de ciberseguridad bajo ISO 27001 y, en sus niveles Manager y Executive, respuesta urgente fuera del horario habitual.
Autor:
Alejandro Tapia
Chief Technology & Security Officer en Sentelius
Cuatro años como director de seguridad de la información de una empresa global y más de una década en arquitectura tecnológica y ciberseguridad. Ingeniero en Tecnologías de la Información, con las certificaciones ISO 27001 Lead Implementer Certification y Certified ISO 27001 Lead Auditor de CertiProf.