ALERTA CRÍTICA – APLICACIONES WEB / PHP
El 21 de octubre, PHP publicó parches de emergencia para dos vulnerabilidades de ejecución remota de código sin autenticación. La solución existe; lo que marca la diferencia es qué tan rápido sepa dónde corre PHP en su organización.
1. El incidente
El 20 de octubre se filtraron los detalles de CVE-2026-109618 y CVE-2026-109619, antes de la divulgación coordinada. Al día siguiente, el equipo de PHP lanzó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Ambas fallas puntúan 9,2 en CVSS v4.0 (watchTowr las califica 10,0), permiten ejecutar código sin autenticación y afectan desde PHP 5.4 a cualquier instalación que atienda solicitudes web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Wiz Research las halló con herramientas de investigación asistidas por IA y las confirmó contra Drupal y WordPress. Unit 42 estima más de 22,6 millones de instancias expuestas potencialmente vulnerables.
Sobre la explotación, los reportes difieren: watchTowr y Recorded Future hablan de intentos activos; otras fuentes indican que no hay intrusiones exitosas confirmadas ni inclusión en el catálogo KEV de CISA al 22 de octubre, y JFrog advierte de pruebas de concepto falsas.
2. Por qué importa para su operación
La falla no está en un plugin ni en un tema: está en el intérprete. Cualquier CMS, portal de clientes o aplicación escrita en PHP hereda el riesgo. El parche existe, pero aplicarlo en decenas o cientos de servidores toma días. En ese intervalo la pregunta ejecutiva cambia: ya no es “¿hay parche?”, sino “¿sabemos dónde corre PHP, qué está expuesto y quién nos avisaría si alguien lo intenta?”.
Lectura de ITELCA: en Colombia, portales institucionales, comercio electrónico y sitios corporativos suelen correr sobre PHP; el primer obstáculo suele ser el inventario, no el parche.
3. Cómo respondería el portafolio de ITELCA en estos casos
- Antes – Saber y cerrar: Descubre dónde corre software vulnerable, prioriza por riesgo real y automatiza el parcheo. Según el fabricante, suma protección sin parche y scripts de mitigación mientras llega la actualización, y revalida que la exposición desapareció.
- Durante – Reducir superficie: Prevención de intrusiones en el perímetro, con inspección TLS para no dejar tráfico cifrado fuera, y bloqueo de infraestructura maliciosa con inteligencia de amenazas en línea. Reducen el riesgo mientras se parchea; no sustituyen el parche.
- Siempre – Ver y responder. CIA – Centro de Inteligencia Avanzada: El SOC 24/7 de ITELCA correlaciona con Exabeam señales como un servidor web que lanza shells o descarga archivos, y con eG Innovations picos de memoria y reinicios anómalos de procesos PHP. Si algo ocurre, contiene, investiga y reporta en lenguaje ejecutivo.
4. Qué hacer esta semana
- Inventariar dónde corre PHP: servidores, contenedores, CMS y activos expuestos a internet.
- Parchear a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de la distribución o proveedor.
- Si no puede parchear hoy, aplicar mitigaciones temporales documentadas por los proveedores, como memory_limit=-1 y session.upload_progress.enabled=0, con reinicio de procesos. Estas medidas son un puente, no la solución.
- Vigilar procesos del servidor web, como php-fpm y httpd, que lancen sh, bash, curl o wget, además de tráfico de salida inesperado.
5. Nota
Información pública con corte al 22 de octubre de 2026. El estado de explotación y las mitigaciones pueden cambiar en horas. Las capacidades de los productos se describen a nivel de categoría; debe confirmarse con cada fabricante la cobertura específica frente a PHP2Shell. Análisis ilustrativo elaborado por ITELCA.
6. Siguiente paso
¿Sabe hoy dónde corre PHP en su organización? Reciba un Threat Intelligence Briefing de 30 minutos y un mapa inicial de su exposición.
Agendar sesión: mercadeo@itelca.com.co
Escrito por: Hernán Alonso Miranda | Ejecutivo de Ventas
ITELCA S.A.S. – Bogotá – Medellín – Lima – www.itelca.com.co
