Lo que pasó
El 21 de octubre de 2026 el equipo de PHP publicó parches de emergencia para dos fallas críticas en el propio motor del lenguaje: CVE-2026-109618 y CVE-2026-109619, conocidas como PHP2Shell. Ambas permiten que un atacante sin credenciales ejecute código en el servidor con una petición HTTP manipulada.
La diferencia con las vulnerabilidades habituales es dónde viven. No están en un plugin, un CMS o un framework: están en PHP. Por eso afectan por igual a WordPress, Magento, WooCommerce, Laravel o una aplicación desarrollada a medida, y el ataque ocurre antes de que se ejecute una sola línea del código de la aplicación. Un login, un captcha o una validación en la app no frenan este ataque.
Si su organización tiene sitios, portales, APIs o sistemas internos en PHP, la recomendación es actualizar hoy, fuera del ciclo normal de parches. Si su organización tiene sitios, portales, APIs o sistemas internos en PHP, la recomendación es actualizar hoy, fuera del ciclo normal de parches.
Cronología de Fecha (2026) y Evento
22 oct: Reportes de explotación amplia; CISA insta a actualizar de inmediato
21 oct, 14:00 UTC: PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35 con ambas correcciones
20 oct: Se filtran los detalles; PHP anuncia en php.net el parche para el día siguiente
17 oct: Primeros intentos de explotación observados, antes del parche
Agosto 2026: Investigadores de Calif y Wiz Research reportan las fallas a PHP bajo embargo
Las dos fallas, sin jerga
Ambas son errores de manejo de memoria del tipo use-after-free (CWE-416): PHP termina usando memoria que ya no debería considerar válida, y un atacante puede aprovecharlo para tomar control del proceso.
CVE-2026-109618 – corrupción al quedarse sin memoria. Cuando PHP agota la memoria mientras procesa una petición, abandona la operación a mitad de camino. Los datos internos quedan a medio construir y la rutina de limpieza los trata como si fueran válidos. Un formulario multipart (el formato que se usa para subir archivos) diseñado para agotar la memoria, aun respetando los límites configurados, basta para dispararlo. Sansec señala además que esta falla puede filtrar memoria del servidor hacia el atacante, al estilo de Heartbleed.
CVE-2026-109619 – restos de una petición anterior. Un mismo proceso de PHP atiende muchas peticiones seguidas. Si un error fatal (falta de memoria, un timeout) interrumpe la limpieza, quedan referencias a memoria ya liberada. La siguiente petición que llega a ese proceso puede tocar esos restos antes de que se reinicialicen. El seguimiento de progreso de subida de sesiones (session upload progress), activo por defecto, es una de las vías confirmadas, y no requiere que la aplicación use sesiones.
El resultado en ambos casos es el mismo: ejecución remota de código con los privilegios del usuario con el que corre PHP, lo que abre la puerta a robo de datos, webshells, ransomware o movimiento lateral.
¿Es realmente "10 de 10"?
No exactamente, aunque eso no la hace menos urgente. El "CVSS 10.0" proviene de la filtración inicial en Hacker News que circuló antes del anuncio oficial, y así lo recogieron varios medios. El equipo de seguridad de PHP asignó a cada falla 9.2 (Crítica) en CVSS v4.0.
El puntaje no llega a 10 porque la explotación exige condiciones técnicas (complejidad de ataque alta y requisitos previos). En la práctica, el riesgo sigue siendo máximo: no requiere autenticación ni interacción del usuario, y el impacto sobre confidencialidad, integridad y disponibilidad es total.
Vector oficial: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Quién está afectado
Prácticamente cualquier servidor que ejecute PHP para atender peticiones web. Según Sansec, el código vulnerable existe desde PHP 5.4 (2012).
Rama de PHP - Estado - Qué hacer
8.5 - Vulnerable antes de 8.5.12 - Actualizar a 8.5.12
8.4 - Vulnerable antes de 8.4.27 - Actualizar a 8.4.27
8.3 - Vulnerable antes de 8.3.36 - Actualizar a 8.3.36
8.2 - Vulnerable antes de 8.2.35 - Actualizar a 8.2.35
7.4, 8.0, 8.1 - Fin de vida, sin versión oficial - Paquete parcheado del proveedor/distribución, backport de código fuente publicado por PHP, o migrar a 8.2+
7.3 o anterior, 5.x - Fin de vida, sin parche - Migrar o aislar de inmediato
Están expuestos todos los modos de ejecución: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. PHP considera a mod_php el de mayor riesgo, porque allí el ataque se demostró con configuración por defecto. Palo Alto Networks estima más de 22,6 millones de instancias expuestas en Internet potencialmente vulnerables.
Muchas empresas no saben cuántos PHP tienen: contenedores con imágenes viejas, servidores de proveedores, paneles de hosting, intranets olvidadas. El inventario es el primer paso.
¿Se está explotando?
Sí. SecurityWeek reporta que los primeros intentos se vieron el 17 de octubre, cuatro días antes del parche, y que la actividad masiva arrancó apenas se publicó la corrección. Amazon, watchTowr, Cloudflare, Patchstack y Hadrian reportaron intentos de explotación.
Hay matices: watchTowr indica que ninguna de las pruebas de concepto públicas que circulan logra aún ejecución remota completa, y Expel advierte que parte del código que se comparte como "exploit" podría ser malicioso. Al 21 de octubre ninguno de los dos CVE figuraba en el catálogo KEV de CISA, aunque la agencia ya recomendó actualizar de inmediato.
El antecedente es claro: fallas críticas anteriores de PHP, como CVE-2024-4577, recibieron intentos de explotación en menos de un día y terminaron usadas en campañas de ransomware.
Qué hacer ahora
La única solución completa es instalar una versión que incluya ambas correcciones. Las medidas de configuración reducen la exposición mientras se parchea, pero no la eliminan.
Inventariar todos los servidores, contenedores y servicios con PHP, incluidos los de terceros y hosting.
Priorizar lo expuesto a Internet y lo que corre con Apache mod_php.
Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de su distribución o panel de hosting.
Reiniciar todos los procesos de PHP (PHP-FPM, Apache) y verificar que la versión nueva es la que realmente atiende el tráfico.
Mitigar temporalmente lo que no se pueda parchear hoy: desactivar
session.upload_progress.enabled, limitar el tamaño de las peticiones en el proxy o WAF y bloquear peticiones multipart donde no se usan.Buscar señales de compromiso: procesos de shell lanzados por PHP, errores de memoria agotada al inicio de peticiones, archivos PHP nuevos en directorios web.
Planificar la migración de cualquier PHP 8.1 o anterior: seguirá expuesto a la próxima falla.
Preparamos una guía técnica paso a paso con comandos para Debian/Ubuntu, RHEL, Windows, Docker y cPanel/CloudLinux. Está disponible para descarga junto a este artículo.
Cómo podemos ayudarle
En InteliCorp Technologies activamos un servicio de respuesta rápida para PHP2Shell a traves del servicio gestionado de iGAP:
Evaluación de exposición: identificamos todos los activos con PHP, internos y expuestos a Internet, y su versión real en ejecución.
Remediación acompañada: planificamos y aplicamos la actualización con su equipo, con plan de reversión y pruebas de funcionamiento.
Mitigación temporal: reglas de WAF y ajustes de configuración para los sistemas que no se pueden actualizar hoy.
Búsqueda de compromiso: revisamos registros y procesos para descartar que el servidor haya sido atacado antes del parche.
Plan de migración para versiones fuera de soporte.
Escríbanos a Comercial@intelicorps.com o al teléfono/WhatsApp +50766304130 (Panamá) +584129656000 (Venezuela) para agendar una evaluación.a agendar una evaluación.
