PHP2Shell: Vulnerabilidad crítica de PHP (CVE-2026-109618 y CVE-2026-109619)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Resumen

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de seguridad para dos vulnerabilidades críticas en el núcleo de PHP: CVE-2026-109618 y CVE-2026-109619, conocidas conjuntamente como PHP2Shell. Ambas fueron calificadas como críticas, cada una con 9,2 sobre 10 según CVSS v4.0, y pueden permitir que un atacante ejecute código en tu servidor sin credenciales: una ejecución remota de código PHP no autenticada, o RCE para abreviar. La vulnerabilidad PHP de 2026 se cuenta entre las fallas más graves de la historia del lenguaje.

Están afectadas todas las versiones de PHP desde PHP 5.4 hasta 8.5.11 inclusive – es decir, prácticamente cualquier instalación de PHP que procese peticiones web, ya sea WordPress, Joomla, Drupal, TYPO3 o una pequeña aplicación propia. La falla está en el núcleo de PHP, no en un CMS ni en un plugin.

Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las ramas más antiguas (8.1 e inferiores, incluido PHP 7.x) ya no reciben releases oficiales. La Oficina Federal Alemana para la Seguridad de la Información (BSI) publicó una advertencia de ciberseguridad sobre la vulnerabilidad de PHP exigiendo actuación inmediata; el NCSC británico, CERT-EU y el Cyber Centre canadiense publicaron alertas equivalentes.

Versiones de PHP afectadas y corregidas

¿Qué es PHP2Shell?

La vulnerabilidad PHP2Shell tiene dos partes: PHP2Shell es el nombre colectivo de dos fallos en el núcleo de PHP. Ambas son errores de memoria del tipo use-after-free (CWE-416): PHP sigue usando estado interno aunque la memoria correspondiente ya haya sido liberada. El nombre remite deliberadamente a Log4Shell, la falla crítica de Java de 2021 – y como allí, el problema no está en una aplicación concreta, sino en un componente sobre el que se construye casi todo.

Primero los términos clave:

• Remote Code Execution (RCE): PHP termina ejecutando en tu servidor código controlado por el atacante – sin login, sin interacción de un usuario.
• Out-of-Memory (OOM): PHP aborta una petición cuando alcanza el límite de memoria configurado (memory_limit).
• Corrupción de memoria: una clase de error en la que el contenido de la memoria se vuelve inválido y el programa lo interpreta después de forma incorrecta – la base técnica de muchos exploits RCE.

CVE-2026-109618: RCE por corrupción out-of-memory

PHP aborta una petición mediante longjmp() cuando se alcanza el límite de memoria. Esto puede interrumpir a PHP en pleno procesamiento – por ejemplo mientras analiza una petición multipart/form-data (el formato que usan los navegadores para formularios con subida de archivos). Los datos de la petición, todavía parcialmente inicializados, son tratados erróneamente como válidos durante la limpieza. La memoria subyacente puede contener todavía datos de asignaciones anteriores controladas por el atacante.

El resultado: una única petición HTTP especialmente construida puede comprometer al worker de PHP durante el procesamiento de la petición – antes de que se ejecute una sola línea de tu código de aplicación. En Apache con mod_php se demostró ejecución remota de código completa con la configuración por defecto; en PHP-FPM se confirmó RCE a través de rutas de código a nivel de aplicación.

CVE-2026-109619: RCE por estado global obsoleto

Los workers de PHP (procesos mod_php, workers FPM) procesan muchas peticiones una tras otra. Entre dos peticiones, el estado interno debe reiniciarse limpiamente. Con esta falla, un error fatal – por ejemplo por agotamiento de memoria – puede abortar una petición de forma que el estado global siga apuntando a memoria de la petición anterior, liberada hace tiempo. Una petición posterior del mismo worker consume ese estado obsoleto antes de que la inicialización normal lo reemplace.

Las rutas confirmadas incluyen diagnósticos INI tempranos (mod_php evalúa la configuración .htaccess y php_value antes del inicio real de la petición), la función de progreso de subida de sesión (session.upload_progress.enabled está activa por defecto) y, en PHP 8.5, la opción fatal_error_backtraces. Se demostró una prueba de concepto contra una aplicación real en Apache con mod_php.

Divulgación de memoria al estilo Heartbleed

Además de la ejecución de código, los investigadores demostraron que las fallas también permiten leer partes de la memoria del proceso PHP – comparable con Heartbleed en OpenSSL. Esa memoria puede contener tokens de sesión, contraseñas, claves API o certificados de otras peticiones. Esta forma de ataque no necesita ejecución de código previa y, en consecuencia, es más difícil de detectar.

¿Quién está afectado?

Toda instalación de PHP que procese peticiones web:

• PHP-FPM (normalmente detrás de Nginx o Apache)
• Apache con mod_php
• php-cgi (configuraciones CGI/FastCGI)
• FrankenPHP
• LiteSpeed (LSAPI)

Apache mod_php fue calificado como el caso más crítico, por dos razones: el exploit demostrado dispara la vulnerabilidad antes de que se ejecute el código de la aplicación, y mod_php comparte directamente el espacio de proceso con el servidor web.

Crucial: esta vulnerabilidad del servidor PHP está en el núcleo de PHP. WordPress, Joomla, Drupal, TYPO3, Magento, Shopware o tu propio script no son la causa – pero cualquier aplicación sobre un runtime PHP vulnerable es atacable en principio, hasta un script trivial que solo genera una salida. Wiz Research demostró RCE no autenticado contra las imágenes de contenedor oficiales de WordPress, Drupal y Joomla.

¿Cómo se descubrió PHP2Shell?

La historia es notable porque, por primera vez, los modelos de IA frontera desempeñaron un papel decisivo en la divulgación coordinada de una vulnerabilidad de esta magnitud:

• Ya en 2024, un desarrollador del núcleo de PHP encontró los primeros indicios del problema OOM trabajando en hallazgos de la primera auditoría de seguridad externa (OSTIF/Quarkslab, financiada por la Sovereign Tech Agency) – pero una vía de exploit concreta seguía siendo teórica.
• El 11 de agosto de 2026, la firma de seguridad Calif (el investigador Ryan A, conocido como lcfr_hax, dentro del programa «Patch the Planet») reportó al proyecto PHP una ejecución remota de código incondicional. OpenAI reportó de forma independiente la misma causa raíz; Wiz Research lo hizo el 24 de agosto, y OpenAI aportó vectores de ataque adicionales el 18 de septiembre.
• Los errores subyacentes llevaban más de una década en el código. La cadena de explotación se consideraba tan compleja que rozaba lo que investigadores humanos pueden lograr en la práctica – los modelos frontera redujeron esa barrera. OpenAI describe los detalles en su artículo sobre la publicación coordinada.
• El 20 de octubre los IDs de CVE se filtraron antes de tiempo – con un CVSS erróneo de 10,0 y una fecha de release equivocada. Un vídeo PoC publicado por error por Calif y una ruptura del embargo por parte de Chainguard aceleraron la publicación; PHP adelantó el release un día.

¿Ya se está explotando PHP2Shell?

Las fuentes difieren ligeramente, así que con fecha explícita (22 de octubre de 2026):

• AWS observó intentos de explotación ya el 17 de octubre – cuatro días antes de la divulgación pública (Datadog Security Labs).
• Cloudflare vio tráfico de ataque contra clientes en la ventana de la filtración, incluidos payloads mutados que intentaban evadir sus reglas WAF.
• Bitdefender y el Cyber Centre canadiense reportaron al momento de redacción ninguna explotación masiva confirmada, pero subrayan que esto puede cambiar rápido – circula un PoC funcional.

¿Estoy afectado por PHP2Shell? – la comprobación PHP2Shell

Antes de cambiar nada, comprueba PHP2Shell – en concreto: averigua qué versión de PHP usa realmente tu web. No siempre es tan trivial como parece.

Paso 1: comprobar la versión de PHP (CLI)

En un servidor con acceso SSH:

php -v

o alternativamente:

php -r 'echo PHP_VERSION, PHP_EOL;'

La salida muestra la versión CLI de PHP, p. ej. PHP 8.3.35 (cli). Si está por debajo de las versiones corregidas (8.2.35, 8.3.36, 8.4.27, 8.5.12), hay que actuar.

Paso 2: identificar la versión realmente en uso

Importante: la versión CLI no tiene por qué ser la misma que usa Apache o PHP-FPM para tu web. En un servidor pueden coexistir varias versiones de PHP.

Para PHP-FPM, comprueba primero qué servicios FPM están corriendo:

systemctl list-units --type=service | grep -i fpm

Los servicios típicos se llaman php8.3-fpm, php8.4-fpm o php-fpm. Obtén la versión correspondiente vía el binario:

php-fpm8.4 -v

Qué pool sirve a qué web se define en la configuración del pool (Debian/Ubuntu: /etc/php/*/fpm/pool.d/) y en la configuración del servidor web (en Nginx el socket fastcgi_pass, en Apache las líneas proxy:fcgi: o SetHandler del vhost).

Para Apache con mod_php:

apache2ctl -M | grep php    # Debian/Ubuntu
apachectl -M | grep php     # Fedora/RHEL

Si la salida muestra php8_module (o php_module), mod_php está en uso – el paquete suele llamarse libapache2-mod-php8.x:

dpkg -l | grep libapache2-mod-php   # Debian/Ubuntu
rpm -q php                          # Fedora/RHEL y similares

Paso 3: más indicios – y sus límites

• Cabeceras HTTP: algunos servidores envían X-Powered-By: PHP/8.3.5. Puedes verlo con curl -I https://tu-dominio.tld o las herramientas de desarrollo del navegador. Ojo: la cabecera suele estar desactivada o la sobrescribe el servidor web/proxy – su ausencia no significa «seguro», y su contenido no tiene por qué coincidir con la versión CGI/FPM. Es una pista, no una prueba.
• phpinfo(): un archivo info.php con <?php phpinfo(); en el webroot muestra la versión y configuración exactas. Pero: phpinfo() revela mucha información sobre tu sistema a los atacantes. Crea ese archivo solo brevemente para el diagnóstico y bórralo inmediatamente después o bloquea el acceso – un phpinfo() público no es una solución permanente.
• Docker: docker exec <contenedor> php -v muestra la versión dentro del contenedor en ejecución – la versión del host no dice nada sobre la imagen.

Cuidado con la trampa de los backports

Las distribuciones de Linux a menudo retroportan los parches de seguridad a sus versiones de paquetes existentes. php -v puede mostrar 8.3.10 aunque el paquete ya contenga el parche de PHP2Shell. A la inversa, una versión upstream sin cambios no significa automáticamente «sin parchear» – y un número upstream nuevo procedente de un repositorio de terceros no significa automáticamente «completamente parcheado».

Por eso comprueba adicionalmente el changelog del paquete o el aviso de seguridad de tu distribuidor:

apt changelog php8.4-fpm        # Debian/Ubuntu
apt policy php8.4-fpm           # versión instalada vs. disponible
rpm -q --changelog php | less   # Fedora/RHEL

Fuentes relevantes son, por ejemplo, los Debian Security Advisories (DSA), los Ubuntu Security Notices (USN) o las erratas de tu distribuidor empresarial.

Instalar la actualización de seguridad de PHP: el fix de PHP2Shell

No existe una alternativa completa a la actualización de PHP2Shell – tal como lo formula el propio proyecto PHP («no complete mitigations, updating is the only safe choice»). Después, lee la sección correspondiente a tu configuración y no olvides: reinicia PHP-FPM o el servidor web, o los workers antiguos seguirán corriendo. La vulnerabilidad PHP en corto – qué hacer: comprobar la versión, aplicar el parche, reiniciar los servicios y revisar los logs en busca de rastros de ataque.

Debian / Ubuntu

sudo apt update
sudo apt upgrade

Después comprueba la versión del paquete instalado (apt policy php8.4-fpm, ajusta el nombre según corresponda) y echa un vistazo al changelog (ver la nota sobre backports arriba). Los paquetes PHP en Debian/Ubuntu suelen venir del repositorio de seguridad o – para versiones más nuevas – del conocido repositorio Sury (packages.sury.org), que publica los builds parcheados con rapidez.

Fedora / sistemas tipo RHEL

sudo dnf upgrade php\*
sudo dnf list php --showduplicates   # comprobar versiones disponibles

Aquí también aplica: verifica la versión del paquete y el changelog (rpm -q --changelog php) contra la errata del distribuidor. Si usas Remi’s Repo o module streams, controla la fuente utilizada.

Reiniciar PHP-FPM

Tras la actualización el reinicio es obligatorio, o los procesos worker antiguos seguirán activos:

sudo systemctl restart php8.4-fpm   # ajusta el nombre a tu versión

Después verifica que el servicio corre la nueva versión:

systemctl status php8.4-fpm
php-fpm8.4 -v

Apache mod_php

Con mod_php, PHP corre dentro del proceso Apache – no sirve de nada actualizar PHP si Apache sigue trabajando con la biblioteca antigua:

sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # Fedora/RHEL

Después prueba la web y revisa los logs (journalctl -u apache2, /var/log/apache2/error.log).

Hosting gestionado (Plesk, cPanel, paneles de proveedores)

En hosting compartido o servidores gestionados normalmente no tienes acceso root – y tampoco lo necesitas:

1. Comprueba qué versión de PHP está asignada por dominio (Plesk: «PHP Settings», cPanel: «MultiPHP Manager», muchos hosters lo muestran en el panel de cliente).
2. Cambia a una versión parcheada si está disponible (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 o superior).
3. Contacta con tu proveedor si solo se ofrecen versiones vulnerables – los proveedores serios parchean sus plataformas de forma centralizada y lo comunican; en caso de duda, pregunta por el estado de PHP2Shell.
4. Para WordPress además en el backend: Herramientas → Salud del sitio → Información → Servidor muestra la versión de PHP que WordPress ve realmente.

PHP2Shell y Docker: contenedores, imágenes, plataformas

IRC-Security.de

Cybersecurity Artikel und Tutorials

Docker no cambia la cuestión central: lo que importa es la versión de PHP dentro de la imagen, no la del host. Los contenedores añaden sin embargo dos trampas: tus propias imágenes contienen su propio PHP, y los contenedores en ejecución nunca se actualizan por sí solos.

¿Qué tan expuesto estoy con Docker?

Respuesta corta: igual de expuesto que sin Docker, en lo que respecta a la falla inicial. Si el PHP dentro de la imagen es vulnerable, una petición HTTP puede comprometer al worker PHP dentro del contenedor – la red es precisamente la razón de ser de ese contenedor.

El aislamiento solo ayuda en el segundo paso: el código corre de entrada «solo» dentro del contenedor, con el usuario del contenedor, los volúmenes montados y los secretos en las variables de entorno. Eso limita el daño – pero un contenedor con acceso a base de datos, directorio de uploads y claves API sigue siendo muy jugoso para los atacantes. PHP2Shell dentro de un contenedor es un evento crítico, no «la mitad de grave».

¿Qué imágenes están afectadas?

Todo lo que contenga PHP. Candidatos típicos:

• imágenes base php:* (php:8.3-fpm, php:8.4-apache, php:8.5-cli, …) y todo lo construido sobre ellas (FROM php:… en tu Dockerfile)
• imágenes con PHP integrado: wordpress:*, nextcloud:*, drupal:*, joomla:*, matomo:*, mediawiki:* y muchas más
• imágenes de FrankenPHP (dunglas/frankenphp:*)
• builds propios, incluidos multi-stage con COPY --from=php…

Encontrar las bases PHP en tu proyecto:

grep -rnE '^\s*FROM\s+\S*(php|frankenphp)' . --include='Dockerfile*'
grep -rnE 'image:\s*\S*(php|wordpress|nextcloud|drupal|joomla|frankenphp)' . --include='*compose*.y*ml'

¿Qué tengo que hacer concretamente?

1. Cambiar a tags parcheados. Las imágenes oficiales de PHP en Docker Hub ya fueron actualizadas (tags como php:8.3.36-fpm-bookworm, php:8.4.27-apache, php:8.5.12-fpm-alpine; los tags flotantes php:8.3, php:8.4 etc. también apuntan a los builds corregidos). En el Dockerfile, idealmente fija php:8.3.36-fpm-bookworm en lugar de php:8.3-fpm.
2. Reconstruir las imágenes propias – con --pull. Sin --pull, la caché de build puede reutilizar la imagen base antigua y vulnerable:

docker compose build --pull
docker compose up -d --force-recreate

3. Imágenes del Hub sin build propio – simplemente volver a descargarlas y recrear los contenedores:

docker compose pull
docker compose up -d --force-recreate

4. No olvides más que el contenedor web: workers de cola, contenedores cron, schedulers – todo lo que use la misma imagen PHP.
5. Verificar dentro del contenedor en ejecución:

docker exec <nombre_contenedor> php -v

6. Cuidado con los digest pins: quien fija imágenes vía @sha256:… debe actualizar el digest manualmente al build parcheado – los pins no traen actualizaciones de seguridad automáticamente.
7. Elimina después las imágenes antiguas y vulnerables, para que nada arranque accidentalmente desde ellas.

¿Los proveedores se encargan de la actualización?

En parte – y justo aquí nacen la mayoría de las falsas suposiciones:

• Docker Official Images y Docker Hardened Images ya fueron actualizadas por Docker Inc. a las versiones PHP parcheadas. Pero eso solo significa: la imagen en el registry es nueva – tu contenedor en ejecución sigue en el build antiguo hasta que lo recrees.
• Imágenes de apps (wordpress, nextcloud y demás) son reconstruidas por sus equipos mantenedores con el nuevo PHP – el pull y el recreate corren por tu cuenta.
• Plataformas gestionadas / PaaS suelen parchear su propio runtime de forma centralizada. Si y cuándo ocurrió solo te lo dice el aviso o la página de estado del proveedor – tus propias imágenes de contenedor desplegadas allí siguen siendo tu responsabilidad.
• Auto-updaters (p. ej. Watchtower) pueden volver a descargar imágenes del Hub y recrear contenedores – pero no pueden reparar imágenes construidas localmente. Para Dockerfiles con FROM php:… necesitas un rebuild, idealmente automatizado vía CI o Dependabot/Renovate.

Coolify en concreto

Coolify es un caso especial porque el propio Coolify está escrito en PHP (Laravel) – la plataforma era vulnerable en todas las líneas v4, independientemente de las apps que despliegues con ella:

• Actualizar desde v4.4: en el dashboard vía Settings → Update → Check now → Update.
• Líneas v4 más antiguas: por SSH con el script oficial de parcheo (curl -fsSL https://cdn.coollabs.io/coolify/patch.sh | sudo bash), que instala la security release correspondiente a tu línea y solo recrea el contenedor de Coolify.
• Coolify Cloud ya está parcheado – ahí no hay nada que hacer.
• Coolify ha desactivado preventivamente 58 plantillas de servicios basadas en PHP hasta verificar qué imágenes contienen el fix.
• Importante: la actualización de Coolify solo parchea Coolify mismo. Tus contenedores de aplicación desplegados siguen vulnerables hasta que los reconstruyas/repliegues – así que dispara en Coolify un redeploy con build fresco por aplicación.

Los detalles están en la documentación oficial de Coolify y en el issue de GitHub enlazado.

Dokploy, CapRover, Easypanel, Dokku, Portainer y demás

El mismo principio que con Coolify, dividido en dos:

1. Comprobar la herramienta misma: ¿la plataforma o alguno de sus contenedores principales corre PHP? Entonces lee el aviso del proyecto y aplica la actualización de la herramienta.
2. Las apps desplegadas con ella: siguen siendo tu tarea – reconstruir o volver a descargar las imágenes y redesplegar las aplicaciones.

En Kubernetes aplica lo equivalente: construir la imagen con PHP parcheado, luego reiniciar el rollout (kubectl rollout restart) para que todos los pods traigan la nueva versión, y verificar si es necesario el digest de los pods en ejecución. Si buscas más contexto sobre imágenes, contenedores y Docker Compose, lo encontrarás en el artículo sobre los fundamentos de Docker.

Medidas transitorias si no puedes parchear de inmediato

Si una actualización es temporalmente imposible, según los advisories oficiales las siguientes medidas reducen la superficie de ataque – pero no protegen por completo y no sustituyen la actualización de seguridad de PHP:

• fijar memory_limit=-1 de forma que las aplicaciones no puedan sobrescribirlo (p. ej. php_admin_value en el pool FPM o en la configuración de Apache) – elimina el disparador OOM controlable, pero no todas las vías
• post_max_size bajo (p. ej. 8M cuando no haya subidas), mantener upload_max_filesize por debajo
• session.upload_progress.enabled=0 – cierra la vía upload-progress de CVE-2026-109619, no toda la falla
• límites de petición en el reverse proxy/servidor web (tamaño del body, número de cabeceras y partes multipart)

PHP 7.x, 8.0 y 8.1: ¿qué hacer con versiones end-of-life?

Las versiones antiguas de PHP no son «seguras por viejas» – al contrario: las fallas se remontan a PHP 5.4, y PHP 8.1 y anteriores ya no reciben releases oficiales del proyecto PHP.

Tus opciones realistas:

1. Comprobar backports de la distribución/vendor: el equipo de seguridad de PHP proporcionó backports fuente para 7.4, 8.0 y 8.1, y los proveedores LTS (Debian LTS, Ubuntu con Extended Security Maintenance, RHEL, proveedores PHP-LTS especializados) construyen paquetes a partir de ellos. Lo que cuenta es la versión del paquete en el changelog, no el número upstream.
2. Migrar a una versión soportada (8.2+). Esa es la respuesta correcta a largo plazo: quien opera PHP 7.x en producción ya navega sin actualizaciones de seguridad – PHP2Shell solo lo hace especialmente visible.
3. Mientras tanto, aplicar las mitigaciones de arriba – conscientemente como parche provisional, no como solución.

¿Puede mi servidor estar ya comprometido?

Una actualización de PHP instalada con éxito no demuestra que antes nadie haya entrado. Los intentos de explotación se observaron, según informes, ya antes de la publicación. Esta lista de verificación es defensiva y pensada para tus propios sistemas:

En los logs del servidor web/PHP (access.log, error.log, log de FPM, syslog/journald):

• peticiones HTTP POST inusuales o inusualmente grandes, especialmente con multipart/form-data
• errores PHP out-of-memory frecuentes («Allowed memory size exhausted») en torno a la inicialización de la petición
• un aumento llamativo de errores HTTP 500
• workers de PHP-FPM o Apache que fallan o se reinician constantemente (segfaults, «child exited»)

En el sistema:

• archivos PHP nuevos o modificados inesperadamente en el webroot y en directorios de uploads (wp-content/uploads y similares) – archivos PHP en carpetas de uploads son casi siempre una señal de alarma
• webshells: archivos que pasan parámetros de petición a system, shell_exec, passthru, eval y similares
• cron jobs desconocidos (crontab -l para todos los usuarios, /etc/cron.*) y cuentas de usuario desconocidas (/etc/passwd, last, auth.log)
• procesos PHP/de servidor web que lanzan inesperadamente shells, intérpretes (bash, python) o herramientas de descarga (curl, wget) – visible p. ej. en la lista de procesos, logs de auditoría o EDR
• en WordPress: cambios inusuales en plugins, temas, wp-config.php, nuevas cuentas de administrador

Si encuentras evidencias concretas: aísla el sistema (desconecta la red, no borres ni reinstales directamente), preserva datos volátiles e imágenes y realiza una investigación forense – tú mismo o mediante un proveedor de servicios. Una buena entrada a la mentalidad y la metodología es el artículo sobre pentesting en Linux y forense informática en IRC-Security.de (en alemán); para la higiene de actualizaciones en general, el texto sobre gestión de parches en Linux (en alemán).

¿Está WordPress afectado por PHP2Shell? (y Joomla, Drupal, TYPO3)

Sí y no. Tanto si buscas PHP2Shell WordPress, PHP2Shell Joomla, PHP2Shell Drupal o TYPO3 – la respuesta es la misma y necesita una precisión:

• El CMS no es la causa. La falla está en el núcleo de PHP, no en el núcleo de WordPress, ni en plugins ni en el tema.
• Pero: WordPress corre sobre PHP. Si tu WordPress corre sobre una versión PHP vulnerable, la vulnerabilidad PHP de WordPress es real – Wiz demostró RCE no autenticado contra las imágenes oficiales de WordPress, Drupal y Joomla.
• Una actualización de WordPress no ayuda. Las actualizaciones del núcleo, temas o plugins no parchean el runtime PHP. Solo la actualización de seguridad de PHP (o un backport de la distribución) cierra el agujero.

Cómo comprobar la versión como operador de WordPress:

• En el backend: Herramientas → Salud del sitio → Información → Servidor → versión de PHP
• En el panel de hosting del proveedor (Plesk «PHP Settings», cPanel «MultiPHP Manager» o similar)
• Preguntar al soporte del hoster si solo se ofrecen versiones antiguas
• Quien opera WordPress vía la imagen Docker wordpress:*: PHP viene integrado ahí → descargar la imagen actualizada y recrear el contenedor (ver la sección Docker)

Los patrones de ataque más generales detrás de esto – por ejemplo cómo se clasifican las vulnerabilidades de aplicaciones web – los trata el artículo sobre el OWASP Top 10; una comparación con inyecciones clásicas como SQL injection muestra por qué PHP2Shell juega en otra liga: aquí la aplicación no puede servir de capa protectora porque el ataque golpea antes de que se ejecute.

¿Puede un firewall o WAF impedir PHP2Shell?

Un web application firewall puede ayudar, pero no sustituye la actualización:

• Cloudflare activó reglas PHP2Shell para todos los clientes (incluido el plan gratuito) y empleó para ello su nueva «Full Transaction Detection» – reglas que evalúan petición y respuesta de una transacción conjuntamente, porque la petición por sí sola no siempre distingue un exploit del tráfico legítimo. Otros proveedores (Azure WAF, Google Cloud Armor, AWS WAF, Imunify360, Sucuri entre otros) siguieron con reglas propias.
• Bloquear las peticiones en una frontera previa (WAF, reverse proxy) detiene el ataque antes de que llegue al parser vulnerable – una ganancia de protección real mientras las reglas cubran las variantes del payload.
• Pero: los exploits mutan (Cloudflare observó exactamente eso), quedan vías de ataque internas y canales no-HTTP(S), y la divulgación de memoria ni siquiera tiene necesariamente una forma de petición bloqueable.

Conclusión: WAF sí – como capa adicional (defensa en profundidad), no como fix. Quien quiera profundizar en reverse proxies y gateways: fundamentos de API Gateway con Kong y Nginx.

FAQ: PHP2Shell

Fuentes y enlaces útiles

Fuentes oficiales y advisories:

• Anuncio de los releases de seguridad de PHP (php.net)
• GHSA-w8hw-w9fx-j79w – RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp – RCE via stale global state (CVE-2026-109619)
• The PHP Foundation: Today’s PHP Security Release
• php2shell.com – página de resumen de los investigadores

Autoridades:

• Advertencia de ciberseguridad del BSI: PHP – vulnerabilidades críticas amenazan aplicaciones web en todo el mundo (alemán)
• CERT-EU Advisory 2026-018: Critical Vulnerabilities in PHP
• NCSC (Reino Unido): Critical security issue affecting PHP
• Canadian Centre for Cyber Security: AL26-026
• NCSC-NL: información operativa sobre el incidente PHP2Shell (GitHub)

Investigación y detección:

• Wiz Research: PHP2Shell – AI uncovers critical RCE vulnerabilities
• OpenAI: Patch the Planet – global response coordination
• Datadog Security Labs: PHP2Shell – detection, analysis, and remediation
• Cloudflare: Deploying protections against php2shell

Docker y plataformas:

• Docker: Security Update on PHP2Shell – Impact for Docker Customers
• Coolify Docs: PHP Security Advisory 2026 (PHP2Shell)
• Coolify GitHub Issue #12266: Update Coolify now for PHP2Shell

Profundización en IRC-Coding.de e IRC-Security.de:

• OWASP Top 10: riesgos de seguridad en aplicaciones web
• SQL Injection: riesgos, protección y mejores prácticas
• Docker Container: fundamentos, imágenes, Dockerfile y Compose
• Tutorial de Bash en Linux para principiantes
• Guía de lenguajes de programación (incl. PHP)
• IRC-Security.de: gestión de parches y actualizaciones automáticas en Linux (alemán)
• IRC-Security.de: Kali Linux, pentesting y forense informática (alemán)

Artículo similar sobre PHP2Shell en IRC-Mania.de (alemán):

• PHP2Shell: WordPress, Docker, Coolify y servidores domésticos – compruébalos y protégelos ahora

PHP2Shell desde la perspectiva de la IA en BotServ.de:

• Español: PHP2Shell – Vulnerabilidad crítica y el rol de la IA
• Deutsch: PHP2Shell – Kritische PHP-Sicherheitslücke und die neue Rolle der KI
• English: PHP2Shell – Critical PHP Vulnerability and AI’s Role
• Русский: PHP2Shell – критическая уязвимость PHP и роль ИИ

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert