PHP2Shell: las fallas críticas de PHP explicadas y qué debe hacer su empresa ahora
Dos fallas críticas de PHP (CVE-2026-109618 y CVE-2026-109619) permiten ejecutar código de forma remota en servidores web. Versiones corregidas, a quién afecta y una lista práctica.
Si su empresa usa cualquier sistema hecho en PHP, como WordPress, WooCommerce, Magento, un portal de clientes o un sitio en cPanel, actualice PHP ahora. El 21 de octubre de 2026 el proyecto PHP publicó parches de emergencia para dos fallas críticas conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619), que permiten a un atacante ejecutar código en un servidor web sin iniciar sesión. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Los servidores con PHP 8.1 o anterior no reciben un parche oficial y necesitan actualizarse o usar un paquete con el parche aplicado por su proveedor.
A continuación explicamos qué pasó, a quién afecta y una lista breve que puede entregar a quien administre su sitio web o sus servidores.
Qué es PHP2Shell
PHP2Shell son dos errores de seguridad de memoria en el propio motor de PHP, no en un plugin ni en un framework. Por eso el alcance es tan amplio: cualquier instalación de PHP que atienda solicitudes web está afectada.
- CVE-2026-109618 se produce cuando PHP se queda sin memoria mientras todavía está preparando una solicitud. La limpieza posterior puede tratar datos a medio inicializar como válidos, lo que provoca corrupción de memoria.
- CVE-2026-109619 es un error de uso después de liberar (use-after-free): restos de una solicitud pueden apuntar a memoria ya liberada, y una solicitud posterior en el mismo proceso puede usarla. PHP también menciona la divulgación de memoria como impacto.
Ambas tienen una calificación de 9.2 (crítica) en CVSS v4.0 y pueden explotarse de forma remota sin autenticación. Los detalles se filtraron el 20 de octubre, antes de que los parches estuvieran listos, por eso las correcciones salieron como versión de emergencia al día siguiente.
A quién afecta
Según CISA y el aviso de PHP, todas las formas habituales de ejecutar PHP en la web están afectadas:
- Apache con mod_php (PHP lo considera el de mayor riesgo, porque una sola solicitud puede activar el ataque antes de que se ejecute el código de la aplicación)
- PHP-FPM (la configuración habitual detrás de Nginx y muy común en servidores cPanel)
- php-cgi, FrankenPHP y LiteSpeed
En la práctica, para una pequeña o mediana empresa eso incluye:
- El sitio web de la empresa si usa WordPress u otro CMS en PHP
- Tiendas en línea con WooCommerce, Magento o PrestaShop
- Portales de clientes y empleados, intranets y sistemas de reservas escritos en PHP
- Hosting compartido o de revendedor, VPS y servidores dedicados con cPanel, Plesk u otros paneles
Unit 42, de Palo Alto Networks, informó de más de 22 millones de instancias expuestas a internet que podrían ser vulnerables, así que no es un problema menor.
¿Se está explotando?
Los informes difieren, así que conviene actuar como si así fuera. Amazon Threat Intelligence detectó un intento de explotación en sus honeypots el 17 de octubre, cuatro días antes de la divulgación, y reportó más intentos de varios actores después del 21 de octubre. Cloudflare y watchTowr también informaron de intentos tempranos. CISA indicó el 21 de octubre que aún no había observado explotación exitosa y, al 23 de octubre, ninguna de las dos CVE figuraba en su catálogo de vulnerabilidades explotadas conocidas (KEV).
La lectura prudente: los atacantes ya lo están intentando, así que cualquier servidor PHP sin parchear y expuesto a internet debe considerarse en riesgo, y las revisiones deben abarcar desde el 17 de octubre.
Qué hacer ahora: lista de verificación
1. Identifique dónde se ejecuta PHP
Haga una lista de todos los sitios, servidores y aplicaciones que usan PHP, incluidos los que configuró un proveedor o un desarrollador anterior. Tenga en cuenta que PHP suele venir integrado en otro software y que un mismo servidor cPanel puede ejecutar varias versiones de PHP a la vez.
2. Actualice a una versión corregida
| Su rama de PHP | Qué hacer |
|---|---|
| 8.5 | Actualizar a 8.5.12 o posterior |
| 8.4 | Actualizar a 8.4.27 o posterior |
| 8.3 | Actualizar a 8.3.36 o posterior |
| 8.2 | Actualizar a 8.2.35 o posterior |
| 7.4 a 8.1 | Sin versión oficial. Use el paquete parcheado de su distribución Linux o proveedor LTS, o actualice a 8.2+ |
| 7.3 y anteriores | Fin de vida, sin parche. Actualice o desconecte el sitio |
En servidores cPanel, actualice los paquetes de PHP mediante EasyApache o el gestor de paquetes del sistema operativo, y revise todas las versiones habilitadas en MultiPHP, no solo la predeterminada. Si su sitio está en un hosting compartido, pida a su proveedor que confirme por escrito que aplicó el parche.
3. Reinicie PHP
Los paquetes actualizados solo lo protegen cuando se reemplazan los procesos en ejecución. Reinicie los pools de PHP-FPM y Apache (en el caso de mod_php) y confirme que la nueva versión es la que realmente atiende las solicitudes.
4. Si no puede actualizar hoy
La recomendación de CISA es directa: si un sistema no puede actualizarse de inmediato o usa PHP 8.1 o anterior, desconéctelo hasta poder hacerlo. PHP indica ajustes provisionales que reducen la exposición, pero no hacen seguro el servidor: establecer memory_limit=-1 de forma que las aplicaciones no puedan cambiarlo (para CVE-2026-109618), session.upload_progress.enabled=0 (para CVE-2026-109619) y, en PHP 8.5, fatal_error_backtraces=0, y luego reiniciar todos los procesos de PHP. Un firewall de aplicaciones web, como las reglas administradas de Cloudflare, puede bloquear patrones de ataque conocidos, pero solo para el tráfico que pasa por él.
5. Busque señales de compromiso
Como los intentos empezaron antes de la divulgación, revise la actividad desde el 17 de octubre:
- Procesos de PHP o del servidor web que abren shells, descargas con
curl/wgetu otros programas inesperados - Archivos PHP nuevos o modificados en carpetas de subida, caché y otros directorios con permisos de escritura (los típicos web shells)
- Cuentas de administrador nuevas en WordPress o en su CMS, y tareas programadas o cron jobs inesperados
- Conexiones salientes inusuales desde el servidor web
Si encuentra algo sospechoso, asuma que las credenciales guardadas en ese servidor están expuestas: cambie contraseñas de bases de datos, claves de API y accesos de administrador después de limpiar o reconstruir el sistema.
Un segundo aviso, de menor riesgo
El 23 de octubre el proyecto PHP publicó otro aviso, CVE-2026-115560, sobre un riesgo adicional de ejecución remota de código que solo afecta a aplicaciones configuradas de forma poco habitual. PHP considera poco probable que afecte a la mayoría de los sitios y recomienda desactivar el progreso de carga de sesiones hasta que se publique una corrección ordinaria. Siga los avisos de seguridad oficiales de PHP para conocer las novedades.
La lección de fondo
PHP2Shell recuerda que el software sobre el que funciona su sitio web necesita la misma disciplina de actualizaciones que sus computadoras. Las versiones antiguas de PHP siguen funcionando en silencio durante años en servidores olvidados, y son justamente lo que buscan los atacantes. Un inventario sencillo, una ventana mensual de actualizaciones y alertas para avisos críticos convierten una emergencia como esta en una actualización de rutina.
Si no está seguro de qué versiones de PHP usan sus sitios o de quién es responsable de actualizarlos, solicite una evaluación de TI gratuita. Administramos servidores cPanel/WHM, Linux y Windows para empresas de Miami-Dade y todo el Sur de Florida, y podemos revisar, actualizar y verificar sus sistemas con rapidez.
Fuentes
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 de octubre de 2026, revisado el 23 de octubre)
- Tenable: preguntas frecuentes sobre php2shell
- Unit 42: informe de amenaza
- Datadog Security Labs: análisis
- The Hacker News: PHP advierte de otro riesgo de RCE
