Que su página web funcione normalmente no significa que su servidor esté protegido. Dos vulnerabilidades críticas en PHP han puesto en alerta a los equipos de tecnología por la posibilidad de que un atacante ejecute código sin iniciar sesión.
El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones para corregir CVE-2026-109618 y CVE-2026-109619, conocidas conjuntamente como PHP2Shell. Ambas recibieron una calificación de gravedad de 9,2 sobre 10 en CVSS 4.0.
Para las empresas, la prioridad es identificar qué servicios utilizan PHP, comprobar su estado y actuar antes de que una vulnerabilidad técnica se convierta en un incidente operativo.
¿Qué es PHP y por qué esta alerta tiene tanto alcance?
PHP es un lenguaje que permite ejecutar aplicaciones web en el servidor. Forma parte de plataformas como WordPress, Drupal y MediaWiki, además de desarrollos empresariales personalizados.
El problema está en el propio motor de PHP. Por eso, una aplicación con código seguro también puede quedar expuesta si funciona sobre una versión vulnerable. Actualizar únicamente el gestor de contenidos o sus complementos no actualiza necesariamente el PHP que utiliza el servidor.
La dimensión potencial es considerable: Unit 42 identificó, mediante su telemetría, más de 22,6 millones de instancias expuestas potencialmente vulnerables. Esta cifra describe exposición posible; no equivale a millones de ataques exitosos ni de empresas comprometidas.
¿Qué podría ocurrir si un atacante aprovecha estos fallos?
Las investigaciones demostraron posibilidades de ejecución de código y lectura de información sensible en memoria. Dependiendo del entorno, esto podría permitir:
Acceder a contraseñas, tokens o claves de integración.
Alterar contenidos y ejecutar acciones con los permisos del proceso PHP.
Utilizar el servidor comprometido para intentar alcanzar otros sistemas.
También se demostró que ciertos ataques pueden extraer información de memoria sin ejecutar previamente código malicioso. Por ello, una vigilancia centrada exclusivamente en detectar programas sospechosos puede resultar insuficiente.
El impacto empresarial dependerá de los datos accesibles, los permisos y las conexiones del servidor: un portal de clientes, una tienda virtual o una aplicación interna pueden representar riesgos distintos.
¿Qué instalaciones deben revisarse?
El aviso de PHP incluye instalaciones que atienden solicitudes web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Destaca un riesgo especialmente elevado para mod_php, donde se demostró un ataque que actúa antes de ejecutar el código de la aplicación.
Esto explica por qué disponer de una pantalla de acceso o autenticación dentro de la aplicación no basta para bloquear determinadas vías de ataque. Datadog reprodujo una de ellas sin que la solicitud llegara al código de la aplicación.
Qué deberían hacer las empresas
1. Identificar los servicios afectados.
Revise sitios públicos, aplicaciones internas, subdominios, contenedores y servicios contratados. Asigne un responsable a cada entorno y confirme qué versión de PHP utiliza realmente.
2. Aplicar la corrección correspondiente.
Estas son las primeras versiones corregidas de las ramas indicadas:
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Para paquetes mantenidos por distribuciones o proveedores, compruebe su aviso de seguridad: pueden incorporar correcciones mediante backports. PHP 8.1 y anteriores están fuera del soporte ordinario del proyecto; requieren revisar las opciones del proveedor o migrar a una rama soportada.
3. Verificar que la actualización quedó activa.
Actualizar archivos no completa por sí solo el trabajo. Reinicie los servicios y procesos PHP correspondientes y compruebe el funcionamiento de las aplicaciones. Las reglas de WAF y otras mitigaciones temporales no sustituyen el parche.
4. Investigar señales de actividad sospechosa.
Revise envíos de formularios inusualmente grandes, errores de agotamiento de memoria y procesos de consola inesperados asociados al servicio web. Son señales para investigar, no pruebas concluyentes por sí mismas.
Si el hosting lo administra un tercero, solicite evidencia de la corrección y de su aplicación en todos los servicios afectados.
La inteligencia artificial también cambia el escenario
Los investigadores utilizaron herramientas de IA durante el descubrimiento, el desarrollo de pruebas y la validación de correcciones. El caso muestra cómo estas herramientas pueden ayudar a analizar fallos complejos y demostrar su impacto.
Para quienes administran tecnología, esto refuerza la necesidad de reducir el tiempo entre una alerta y una respuesta verificable.
La perspectiva de Sciotec: actualizar y comprobar
Desde Sciotec, el mensaje para los responsables de TI es concreto: conocer la infraestructura, corregir la exposición y verificar el resultado.
La gestión de vulnerabilidades, el monitoreo y la respuesta a incidentes deben trabajar juntos. Aplicar un parche corrige una debilidad; investigar permite determinar si alguien pudo aprovecharla antes.
La pregunta que cada empresa debería poder responder hoy es: ¿sabemos qué servicios utilizan PHP y tenemos evidencia de que están corregidos?
