El 21 de octubre de 2026 el proyecto PHP publicó actualizaciones de seguridad de emergencia para las ramas 8.2, 8.3, 8.4 y 8.5. Las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, a las que los investigadores han llamado PHP2Shell. Ambos fallos tienen una puntuación CVSS v4.0 de 9.2 y pueden permitir a un atacante ejecutar código en un servidor web sin necesidad de credenciales.
Los fallos están en el núcleo del lenguaje, no en aplicaciones concretas. Afectan a instalaciones que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo es especialmente alto en configuraciones con mod_php, donde se ha demostrado un exploit que actúa antes de que se ejecute cualquier código de la aplicación.
Qué son las vulnerabilidades PHP2Shell
Según el aviso oficial del proyecto PHP, CVE-2026-109618 permite la ejecución remota de código mediante corrupción por agotamiento de memoria (OOM). Cuando PHP se queda sin memoria mientras inicializa parcialmente los datos de una petición, el proceso de limpieza puede tratar esa memoria inválida como válida. Un atacante puede forzar esta situación con peticiones multipart cuidadosamente construidas que permanecen dentro de los límites configurados de post_max_size y memory_limit.
CVE-2026-109619 se basa en estado global obsoleto. Datos propiedad de una petición pueden sobrevivir después de que se haya liberado la memoria que los respaldaba. Una petición posterior manejada por el mismo worker puede reutilizar ese estado antes de que la inicialización normal lo reinicie. El mecanismo de session.upload_progress, activado por defecto, es uno de los caminos confirmados.
El proyecto PHP señala que no existen mitigaciones completas y que la única solución segura es actualizar. Las ramas 8.1 y anteriores ya no reciben actualizaciones oficiales, aunque el equipo de seguridad proporcionó backports mínimos de código fuente para 7.4, 8.0 y 8.1.
Versiones afectadas y cómo actualizar
Las versiones afectadas incluyen todas las de las ramas 8.2 a 8.5 anteriores a los parches mencionados, así como versiones más antiguas desde PHP 5.4. Los administradores deben actualizar a:
- PHP 8.5.12 o superior
- PHP 8.4.27 o superior
- PHP 8.3.36 o superior
- PHP 8.2.35 o superior
Las distribuciones Linux y proveedores de hosting recibieron los parches con antelación. En muchos casos basta con aplicar las actualizaciones del sistema y reiniciar los workers de PHP (PHP-FPM o Apache). Si el sitio está en un hosting compartido, el usuario debe preguntar al proveedor si ya ha aplicado el parche o cuándo lo hará.
Impacto en WordPress y otros CMS
WordPress, Drupal, Joomla, Magento, Laravel y la mayoría de aplicaciones PHP corren sobre el intérprete. Actualizar el CMS, el tema o los plugins no soluciona el problema. Investigadores de Wiz y Calif demostraron ejecución remota de código preautenticada contra contenedores de WordPress, Drupal y Joomla.
Amazon reportó intentos de explotación ya el 17 de octubre, cuatro días antes de la publicación pública. Posteriormente se han observado escaneos masivos y intentos contra organizaciones gubernamentales. Wordfence, que protege millones de sitios WordPress, ha registrado actividad de ataque pero no ha confirmado compromisos exitosos a gran escala hasta el momento, lo que sugiere que la explotación fiable requiere condiciones específicas.
En España y la UE muchos sitios corporativos, tiendas y blogs personales usan WordPress sobre hosting compartido o VPS. Los propietarios deben verificar la versión de PHP (en WordPress, Herramientas > Salud del sitio > Información > Servidor) y confirmar con el proveedor que se ha aplicado el parche.
Mitigaciones temporales y recomendaciones
El aviso de PHP ofrece medidas parciales para quienes no puedan actualizar de inmediato. Para CVE-2026-109618 se recomienda establecer memory_limit=-1 de forma administrativa (php_admin_value) y reiniciar los workers, aunque esto elimina la protección de recursos. Para CVE-2026-109619, desactivar session.upload_progress.enabled=0 y reiniciar. En PHP 8.5 también se puede poner fatal_error_backtraces=0.
Estas medidas no hacen segura la instalación. El 23 de octubre el proyecto publicó un aviso informativo adicional sobre un vector residual relacionado con session.upload_progress en configuraciones poco habituales (cambio del serialize_handler en tiempo de ejecución), para el que recomienda mantener desactivado el progreso de subida hasta el siguiente ciclo de parches.
Recomendaciones prácticas:
- Actualizar PHP y reiniciar todos los workers.
- Comprobar la versión con php -v o desde el panel del hosting.
- Si no controlas el servidor, contactar al proveedor y pedir confirmación escrita.
- Revisar logs en busca de peticiones multipart anómalas o errores de memoria en el arranque de petición.
- Considerar un WAF o reglas que limiten el número de partes multipart y el tamaño de peticiones, como capa adicional.
Qué puede pasar ahora
Los parches están disponibles y la mayoría de proveedores responsables ya los han aplicado o lo están haciendo. El riesgo residual se concentra en instalaciones desatendidas, hosting barato que tarda en parchear y sitios que siguen en ramas EOL. Los investigadores señalan que la complejidad del exploit reduce la probabilidad de compromisos masivos automáticos, pero no la elimina para atacantes dirigidos.
El descubrimiento contó con ayuda de modelos de IA (OpenAI y Gemini, entre otros), lo que subraya cómo las herramientas automatizadas aceleran tanto la búsqueda de fallos como la de parches. Para los usuarios españoles el mensaje es claro: si tu web, tienda o blog usa PHP, confirma hoy que el servidor está en una versión parcheada. La actualización es la única medida que cierra ambos CVE de forma fiable.
Fuentes primarias: aviso de seguridad de PHP, GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.
Guías relacionadas para administradores
Si gestionas un sitio WordPress y todavía no puedes aplicar el parche, consulta nuestra guía de respuesta ante PHP2Shell y detección de intrusiones. Para planificar la actualización del entorno, también puedes revisar la guía de migración de PHP 8.2 para WordPress.
Deja una respuesta