Publicado: 21 octubre 2026 | Actualizado en tiempo real | Tiempo de lectura: ~8 min
🚨 ALERTA: Vulnerabilidad activa con exploits circulando. Si tu sitio corre PHP, necesitas actuar hoy. Los parches oficiales ya están disponibles.
El 21 de octubre de 2026, el equipo de PHP lanzó parches de emergencia para dos vulnerabilidades críticas de ejecución remota de código, bautizadas colectivamente como PHP2Shell. Con una puntuación CVSS de 9.2 sobre 10, afectan prácticamente cualquier instalación de PHP que sirva tráfico web — incluyendo el 71.8% de los sitios en internet que usan PHP como base.
En Colombia, donde WordPress, Joomla y Drupal son la base de la mayoría de sitios empresariales, educativos y gubernamentales, el impacto potencial es significativo. Esta guía te explica qué pasó, si estás afectado, y cómo parchear en los próximos 30 minutos.
1. ¿Qué es PHP2Shell y por qué es tan grave?
PHP2Shell es el nombre informal para el par de vulnerabilidades CVE-2026-109618 y CVE-2026-109619, descubiertas en el núcleo del runtime de PHP. Ambas permiten a un atacante ejecutar código arbitrario en el servidor sin necesitar credenciales ni acceso previo — solo enviando una solicitud HTTP especialmente construida.
Lo que las hace especialmente peligrosas:
- No requieren autenticación: el ataque ocurre antes de que corra el código de tu aplicación.
- Afectan el runtime, no un plugin: actualizar WordPress, Drupal o Joomla no te protege. Hay que actualizar PHP.
- Permiten leer memoria del servidor: aunque no lleguen a ejecución de código, pueden exponer contraseñas, tokens y API keys de otras solicitudes activas.
- Explotación activa ya confirmada: Cloudflare detectó intentos de ataque antes del parche. watchTowr confirmó explotación activa.
2. Detalles Técnicos: CVE-2026-109618 y CVE-2026-109619
| Campo | CVE-2026-109618 | CVE-2026-109619 |
| Nombre | PHP2Shell – OOM RCE | PHP2Shell – UAF RCE |
| Tipo | Remote Code Execution (RCE) | Heap Use-After-Free → RCE |
| CVSS v4.0 | 9.2 / 10 (Crítico) | 9.2 / 10 (Crítico) |
| Causa raíz | Manejo deficiente de out-of-memory: datos de solicitud parcialmente inicializados se limpian como si fueran válidos | Estado de sesión retenido tras liberar memoria; siguiente request puede acceder a ese estado antes de ser reseteado |
| Autenticación requerida | No (unauthenticated) | No (unauthenticated) |
| Mayor riesgo en | Apache mod_php (exploit confirmado) | PHP-FPM y mod_php |
| Divulgado | 21 octubre 2026 (anticipado por leak) | 21 octubre 2026 (anticipado por leak) |
| Parche oficial | PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 | PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 |
CVE-2026-109618: El bug del out-of-memory
Cuando PHP se queda sin memoria mientras procesa los datos de una solicitud HTTP (por ejemplo, al subir un archivo grande), los datos quedan parcialmente inicializados. El error está en la rutina de limpieza (shutdown): trata esos datos incompletos como si fueran válidos, creando una condición que un atacante puede explotar para ejecutar código con los privilegios del proceso web.
PHP confirmó ejecución remota de código contra Apache mod_php con configuraciones estándar y sin autenticación.
CVE-2026-109619: El bug de use-after-free en sesiones
PHP retiene estado específico de la solicitud (relacionado con el progreso de subida de sesiones) después de liberar la memoria asociada. Una solicitud posterior en el mismo worker puede acceder a ese estado “muerto” antes de que sea reiniciado. Esto produce un heap use-after-free clásico que puede escalar a ejecución de código o divulgación de memoria.
La divulgación de memoria es particularmente preocupante: Wiz demostró que este vector puede exponer contraseñas, tokens de sesión, API keys y certificados de otras solicitudes HTTP que estén siendo procesadas simultáneamente en el mismo servidor.
Contexto histórico: La PHP Foundation reveló que el bug de out-of-memory (CVE-109618) fue identificado por primera vez en una auditoría de seguridad de 2024. Sin embargo, la corrección quedó estancada por meses. La fundación lo calificó como un ‘fallo estructural’ en su proceso de gestión de vulnerabilidades. La divulgación el 21 de octubre fue anticipada por un leak el 20 de octubre, lo que obligó a acelerar el parche.
3. ¿Está Afectado tu Sitio? Versiones y Configuraciones en Riesgo
Versiones de PHP afectadas
| Versión PHP | Estado | Parche disponible | Recomendación |
| PHP 5.x / 6.x | ⛔ EOL hace años | No | Migrar urgente a 8.x |
| PHP 7.x | ⛔ EOL | Solo backport código fuente | Migrar urgente a 8.x |
| PHP 8.0 | ⛔ EOL | Solo backport código fuente | Migrar urgente a 8.2+ |
| PHP 8.1 | ⛔ EOL dic 2025 | Solo backport código fuente | Migrar urgente a 8.2+ |
| PHP 8.2.x | ✅ Soportada | 8.2.35 ✓ | Actualizar a 8.2.35 hoy |
| PHP 8.3.x | ✅ Soportada | 8.3.36 ✓ | Actualizar a 8.3.36 hoy |
| PHP 8.4.x | ✅ Soportada | 8.4.27 ✓ | Actualizar a 8.4.27 hoy |
| PHP 8.5.x | ✅ Soportada | 8.5.12 ✓ | Actualizar a 8.5.12 hoy |
Modos de ejecución en riesgo
| Modo de ejecución PHP | Riesgo CVE-109618 | Riesgo CVE-109619 | Notas |
| Apache mod_php | CRÍTICO | CRÍTICO | Exploit de RCE confirmado. Mayor prioridad. |
| PHP-FPM (Nginx/Apache) | ALTO | CRÍTICO | CVE-109619 llega a RCE según comportamiento de la app |
| php-cgi | ALTO | ALTO | Afectado según PHP Foundation |
| FrankenPHP | ALTO | ALTO | Afectado. Pendiente confirmación de parche |
| LiteSpeed LSAPI | ALTO | ALTO | Afectado según PHP Foundation |
| PHP CLI (línea de comandos) | BAJO | BAJO | No sirve requests HTTP, riesgo mínimo |
Cómo verificar tu versión de PHP
Desde la terminal del servidor:
php -v
Desde WordPress (si tienes acceso al admin): Herramientas > Salud del sitio > pestaña Info > Servidor.
Desde tu panel de hosting (cPanel, Plesk, etc.): busca la opción ‘PHP Version’ o ‘PHP Selector’.
4. Cómo Parchear: Guía por Entorno
4.1. Servidor Linux con paquetes del sistema (Ubuntu/Debian)
sudo apt update sudo apt upgrade php php-fpm php-cli sudo systemctl restart apache2 # o nginx sudo systemctl restart php8.3-fpm # ajusta la versión
4.2. Servidor Linux (CentOS/RHEL/AlmaLinux)
sudo dnf update php php-fpm sudo systemctl restart httpd sudo systemctl restart php-fpm
4.3. Servidor con phpbrew o versión compilada manualmente
Descarga las fuentes de php.net para tu versión (8.2.35, 8.3.36, 8.4.27 o 8.5.12), recompila con las mismas opciones de configuración de tu instalación actual, y reinicia los servicios web.
4.4. Hosting compartido (cPanel, Plesk, Hostinger, GoDaddy, etc.)
En hosting compartido no controlas directamente la versión de PHP. Los pasos son:
- Revisa el panel de tu hosting: la mayoría ya tienen o tendrán disponible la versión parcheada en las próximas horas/días.
- En cPanel: busca ‘PHP Version’ o ‘MultiPHP Manager’ y selecciona la versión más reciente disponible (8.2.x, 8.3.x o superior).
- Si no hay versión parcheada disponible: contacta a soporte de tu hosting hoy, menciona PHP2Shell y CVE-2026-109618/109619, y solicita actualización urgente.
- Si el hosting no responde en 24-48h: considera aplicar las mitigaciones temporales de la sección siguiente o evalúa cambiar de proveedor.
4.5. Docker / contenedores
# Actualizar imagen base docker pull php:8.3-apache # o 8.2-fpm, 8.4-fpm, etc. # Reconstruir tu imagen docker build -t mi-app:latest . # Reemplazar contenedores en producción docker-compose up -d –force-recreate
Verificar que el parche está aplicado
php -v # Debe mostrar: PHP 8.3.36 (o 8.2.35, 8.4.27, 8.5.12)
Importante: Actualizar el plugin de WordPress o el core de Drupal/Joomla NO actualiza PHP. Son capas separadas. El parche debe aplicarse a nivel del runtime de PHP en el servidor o en el panel de hosting.
5. Mitigaciones Temporales (Si No Puedes Parchear Aún)
La única solución real es parchear. Las mitigaciones son stopgaps para ganar tiempo — no eliminan el riesgo completamente:
| Mitigación temporal | Cómo aplicar | Efectividad | Impacto operativo |
| Deshabilitar session upload progress | php.ini: session.upload_progress.enabled = 0 Reiniciar Apache/FPM | Parcial (CVE-109619) | Bajo si no usas upload progress |
| Deshabilitar fatal_error_backtraces | php.ini: fatal_error_backtraces = 0 (solo PHP 8.5) | Parcial (CVE-109619) | Mínimo |
| Bloquear multipart/form-data | Regla WAF o nginx: deny si Content-Type contiene multipart/form-data | Parcial (ambas CVE) | ALTO: rompe todos los formularios con archivos |
| Activar WAF rules Cloudflare | Automático para todos los clientes Cloudflare (incluso free) | Parcial | Ninguno si ya usas Cloudflare |
| memory_limit=-1 + límites en proxy | php.ini: memory_limit=-1 Limitar tamaño de request en Nginx/Apache | Parcial (CVE-109618) | Revisar que la app no dependa de memory_limit |
| ⭐ PARCHE OFICIAL | apt/yum upgrade php + reiniciar servicios | COMPLETA | Reinicio de servicios web (~segundos) |
Para aplicar los cambios de php.ini:
; En tu php.ini o en un archivo en /etc/php/8.x/conf.d/ session.upload_progress.enabled = 0 ; Solo PHP 8.5: fatal_error_backtraces = 0 ; Luego reiniciar: sudo systemctl restart php8.3-fpm sudo systemctl restart apache2
6. ¿Ya Fui Comprometido? Indicadores de Ataque
Si tu sitio estuvo expuesto antes del parche (o aún está sin parchear), estos son los indicadores a revisar:
| Indicador de compromiso | Dónde buscar | Qué significa |
| Requests multipart/form-data seguidas de errores 500 | Logs de Apache/Nginx access.log | Posible intento de explotación CVE-109618 |
| PHPSESSID cookies inusualmente grandes | Logs de acceso + headers de request | Posible vector de CVE-109619 |
| Procesos PHP spawneando shells (sh, bash, cmd) | ps aux / process monitor / SIEM | Compromiso activo — acción inmediata |
| Reinicios inexplicables de workers FPM | /var/log/php-fpm/error.log | Posible crash por explotación |
| Descarga de herramientas (wget, curl) desde proceso PHP | Logs de red / SIEM / auditd | Compromiso activo — aislamiento inmediato |
| Errores de memory_limit en logs PHP combinados con 500s repetidos | /var/log/php/error.log o error_log de PHP | Posible trigger de CVE-109618 |
Cómo revisar logs rápidamente
# Buscar solicitudes multipart seguidas de errores en Apache grep ‘multipart/form-data’ /var/log/apache2/access.log | grep ‘500’ # Buscar reinicios de FPM grep ‘child .* exited\|WARNING’ /var/log/php8.3-fpm.log | tail -50 # Revisar procesos PHP actuales ps aux | grep php
Si encuentras indicadores de compromiso activo, aísla el servidor inmediatamente (retíralo del balanceador o bloquea el tráfico entrante) antes de investigar. Los logs y la memoria son evidencia forense — no apagues el servidor hasta hacer un dump de memoria si puedes.
7. Impacto Específico en WordPress, Drupal y Joomla
WordPress
WordPress es el CMS más usado en Colombia y corre sobre PHP en prácticamente todas las instalaciones. Wiz demostró RCE unauthenticado contra WordPress en su investigación. La atacante no necesita conocer ninguna credencial, ruta de administración ni plugin instalado — solo la URL pública del sitio.
Prioridad de acción:
✓ Verificar versión de PHP desde Panel Hosting o WP-Admin > Salud del sitio.
✓ Actualizar PHP desde el panel de hosting (no desde WordPress).
✓ Revisar logs de acceso por patrones sospechosos.
✗ Actualizar solo plugins o el core de WordPress NO te protege.
Drupal y Joomla
Ambos CMS también fueron confirmados como vectores de ataque en las pruebas de Wiz. El procedimiento de mitigación es idéntico: actualizar PHP en el servidor, no el CMS.
Aplicaciones PHP personalizadas (Laravel, Symfony, CodeIgniter)
Cualquier aplicación PHP que sirva tráfico HTTP está en riesgo. Si tu empresa tiene desarrollos propios en PHP (ERP, portales de clientes, APIs), la misma actualización aplica. Después de actualizar PHP, verifica que la aplicación funcione correctamente: el parche añade un límite de memoria más estricto que puede afectar el comportamiento de `memory_limit` y `post_max_size` en algunas configuraciones.
8. Cómo Detectar una Explotación en Progreso con SIEMPQR
Para empresas que tienen múltiples servidores o aplicaciones PHP en producción, la detección manual de indicadores de compromiso es inviable. SIEMPQR, la plataforma SIEM de SilverIT, puede correlacionar automáticamente los patrones asociados a PHP2Shell:
- Spike de errores HTTP 500 en ventanas de tiempo cortas desde una misma IP.
- Procesos PHP hijo con comportamiento anómalo (spawning de shells, conexiones de red salientes inesperadas).
- Picos de uso de memoria en workers PHP fuera del umbral normal.
- Reinicios repetidos de PHP-FPM o Apache en intervalos cortos.
- Accesos a archivos sensibles (wp-config.php, .env, config.php) inmediatamente después de una solicitud multipart.
Si tu empresa gestiona varios sitios PHP o tiene aplicaciones críticas expuestas a internet, este es el momento de evaluar una solución de monitoreo de seguridad en tiempo real. Escríbenos en silverit.co para una demo de SIEMPQR sin costo.
9. Contexto para Empresas Colombianas
En Colombia, el impacto potencial de PHP2Shell es amplio por varias razones:
- Alta adopción de WordPress: la mayoría de sitios corporativos, pymes, medios y entidades educativas usan WordPress sobre PHP.
- Hosting compartido predominante: muchas pymes usan planes de hosting compartido donde no controlan directamente la versión de PHP, dependiendo de que el proveedor actualice. La presión al proveedor es urgente.
- Aplicaciones PHP legacy: en el sector público y financiero colombiano existen sistemas desarrollados en PHP 5.x o 7.x que ya no tienen soporte oficial y para los que no hay parche disponible.
Desde la perspectiva de la Ley 1581 (protección de datos) y la Ley 1273 (delitos informáticos), una brecha derivada de no aplicar un parche disponible puede generar responsabilidades legales para los responsables del tratamiento de datos. Las entidades reguladas (sector financiero, salud) tienen obligaciones adicionales bajo la Circular SFC 007.
10. Línea de Tiempo del Incidente
- 2024: Auditoría de seguridad de PHP Foundation identifica el bug de out-of-memory (CVE-109618). El fix queda estancado.
- 20 oct 2026: Leak en Hacker News expone detalles de ambas CVE antes de la fecha de divulgación planificada (22 oct).
- 20 oct 2026 (noche): Chainguard publica imágenes Docker parcheadas antes del anuncio oficial.
- 21 oct 2026 ~02:00 UTC: BleepingComputer reporta que PHP advierte a admins sobre dos fallas críticas con parches para el día siguiente.
- 21 oct 2026 ~14:00 UTC: PHP lanza oficialmente los parches (8.2.35, 8.3.36, 8.4.27, 8.5.12).
- 21 oct 2026: Cloudflare despliega reglas WAF de emergencia para todos los clientes. Los atacantes cambian payloads para evadir las reglas.
- 21 oct 2026: watchTowr confirma explotación activa. Wiz demuestra RCE contra WordPress, Drupal y Joomla.
- 21 oct 2026: CERT-EU, NCSC UK y Google Cloud publican avisos de seguridad.
Qué Hacer Ahora Mismo
Esta es la lista de acciones en orden de prioridad:
✓ Verificar la versión de PHP en todos tus servidores y sitios (php -v o panel de hosting).
✓ Si tienes PHP 8.2, 8.3, 8.4 o 8.5: actualizar a la versión parcheada hoy.
✓ Si tienes PHP 8.1 o anterior: aplicar mitigaciones temporales Y planificar migración urgente.
✓ Si usas hosting compartido: contactar al proveedor hoy y exigir actualización.
✓ Revisar logs de acceso en busca de indicadores de compromiso.
✓ Si tienes múltiples servidores PHP: considerar un SIEM para detección automatizada.
🚨 ALERTA: PHP 5.x, 6.x, 7.x y 8.0/8.1 no recibirán parche oficial. Si tu empresa opera sitios críticos sobre versiones EOL, esta vulnerabilidad es una razón de peso para planificar la migración ahora.
En SilverIT ayudamos a empresas colombianas a gestionar actualizaciones de seguridad urgentes, auditar configuraciones PHP y configurar monitoreo continuo. Si necesitas apoyo para evaluar el impacto en tu infraestructura, escríbenos en silverit.co.
Fuentes
- Huntress: PHP2Shell – Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619) — huntress.com
- The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws — thehackernews.com
- BleepingComputer: PHP warns admins of two critical flaws, emergency patches coming tomorrow — bleepingcomputer.com
- Tenable: php2shell FAQ — tenable.com
- Google Cloud: Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 — cloud.google.com
- CERT-EU: Critical Vulnerabilities in PHP — cert.europa.eu
- NCSC UK: Critical security issue affecting PHP — ncsc.gov.uk
W3Techs: PHP usage statistics October 2026 — w3techs.com