# PHP2Shell: el fallo grave de PHP que puede afectar a la web de tu empresa y cómo protegerla

Por Agustín Valles Moreno (CoFundador y CTO) en Nadia Solutions · El diario de Nadia · Tecnología y empresa

Publicado el 2026-10-22 · Actualizado el 2026-10-22 · https://nadiasolutions.com/blog/php2shell-vulnerabilidades-php-cve-2026-109618

**En corto.** PHP2Shell es el nombre que los investigadores de Wiz dieron a dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecutar código en el servidor sin autenticación. Afectan a PHP 8.2 a 8.5 sin parchear. La única solución completa es actualizar a 8.2.35, 8.3.36, 8.4.27 o 8.5.12.

El 21 de octubre de 2026 el equipo de PHP [publicó un aviso de seguridad](https://www.php.net/archive/2026.php#2026-10-21-5) en el que pide a todos los usuarios que actualicen de inmediato. Corrige dos vulnerabilidades críticas que pueden permitir a un atacante ejecutar código en un servidor sin necesidad de usuario ni contraseña. Si tu empresa tiene una web, una tienda online, una intranet o una aplicación de gestión hecha en PHP, este aviso te afecta directamente o, como mínimo, merece una comprobación.

La noticia ha tenido eco también en medios generalistas: [RTVE informó el 22 de octubre de 2026](https://amp.rtve.es/noticias/20261022/fallos-criticos-php2shell-vulnerabilidades-servidores-alerta-ciberseguridad/17277748.shtml) de la alerta internacional por estos fallos. Los datos técnicos de este artículo proceden de las fuentes oficiales que enlazamos en cada apartado.

En este artículo te explicamos, sin tecnicismos innecesarios, qué se sabe con certeza, qué no se sabe todavía y qué pasos concretos puedes dar esta misma semana.

## ¿Qué son PHP2Shell, CVE-2026-109618 y CVE-2026-109619?

PHP es el lenguaje de programación con el que funcionan muchos gestores de contenidos, tiendas online y aplicaciones a medida. Lo que se ha descubierto no es un fallo de una web concreta, sino del propio motor de PHP, es decir, de la pieza que ejecuta el código de la aplicación en el servidor.

Los identificadores oficiales son dos. El primero, [CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618), se titula en el aviso de PHP «ejecución remota de código por corrupción en falta de memoria»: cuando una petición agota la memoria que tiene asignada, PHP interrumpe el proceso de forma brusca y puede dejar datos internos a medio preparar, que después se tratan como si fueran válidos. El segundo, [CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619), es la «ejecución remota de código por estado global obsoleto»: cierta información interna de una petición sobrevive después de liberarse su memoria, y una petición posterior atendida por el mismo proceso puede llegar a usarla. El detalle técnico está en los avisos oficiales de PHP en GitHub ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) y [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)).

«Ejecución remota de código» significa, en la práctica, que alguien desde fuera podría conseguir que tu servidor ejecute las órdenes que él quiera, con los permisos del proceso web. Según el [aviso de PHP para CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), el impacto confirmado es la ejecución remota de código sin autenticación, validada a través de HTTP contra Apache con mod_php usando los límites de memoria y de entrada que PHP trae por defecto.

El nombre «PHP2Shell» no aparece en los avisos del equipo de PHP. Lo utilizan los investigadores que participaron en el descubrimiento, de la empresa Wiz, en su [propio análisis publicado el 21 de octubre de 2026](https://www.wiz.io/blog/php2shell-php-rce), y ese texto figura como referencia en los registros oficiales de [CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) y del NIST. Es, por tanto, un apodo de los investigadores, no una denominación oficial de PHP.

## ¿A quién afectan y qué versiones están corregidas?

Según los registros publicados por PHP como autoridad que asigna estos CVE ([registro de CVE-2026-109618 en CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) y [registro de CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619)), las ramas afectadas y las versiones que corrigen el problema son estas:

| Rama de PHP | Versiones afectadas | Versión corregida | Fuente |
| --- | --- | --- | --- |
| 8.2 | anteriores a 8.2.35 | 8.2.35 | [CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) |
| 8.3 | anteriores a 8.3.36 | 8.3.36 | [CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) |
| 8.4 | anteriores a 8.4.27 | 8.4.27 | [CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) |
| 8.5 | anteriores a 8.5.12 | 8.5.12 | [CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618) |

Las mismas versiones corregidas aparecen en el [anuncio oficial de php.net](https://www.php.net/archive/2026.php#2026-10-21-5) y en el [aviso de INCIBE-CERT](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php). Las dos vulnerabilidades afectan exactamente a los mismos rangos de versiones.

¿Y si tu servidor usa una versión anterior a PHP 8.2? Todas las versiones anteriores a PHP 8.2 deben considerarse afectadas: no tienen soporte, y PHP ha tenido que publicar parches de urgencia para 7.4, 8.0 y 8.1, según su [anuncio de php.net](https://www.php.net/archive/2026.php#2026-10-21-5). La solución es migrar a una versión mantenida, PHP 8.2 o superior. Si necesitas ayuda con esa migración, te lo contamos al final del artículo.

En cuanto al tipo de instalación, PHP indica en su [anuncio](https://www.php.net/archive/2026.php#2026-10-21-5) que están en riesgo todas las instalaciones que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y que considera mayor el riesgo en mod_php. Las vulnerabilidades están en PHP, no en tu aplicación: un código bien escrito no te protege si la versión de PHP es vulnerable.

## ¿Qué gravedad tienen?

Las dos vulnerabilidades tienen la misma puntuación en cada fuente, pero conviene saber que hay dos cifras distintas en circulación y por qué:

- PHP, como organización que asigna estos CVE, les da una puntuación CVSS 4.0 de 9,2, severidad crítica, con el vector `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` ([registro en CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618); la misma cifra figura en el [aviso de GitHub](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)).
- El NIST, en su base de datos NVD, ha publicado su propia valoración con CVSS 3.1: 9,8, severidad crítica, con el vector `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` ([NVD, CVE-2026-109618](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) y [NVD, CVE-2026-109619](https://nvd.nist.gov/vuln/detail/CVE-2026-109619)).

CVSS es una escala de 0 a 10 que resume lo grave que es un fallo; según la [especificación oficial de CVSS publicada por FIRST](https://www.first.org/cvss/v4-0/specification-document), las puntuaciones de 9,0 a 10,0 se califican como críticas. La diferencia entre ambas cifras se debe a que son versiones distintas del sistema de puntuación y a que valoran de forma distinta la dificultad del ataque: PHP la califica como alta y con requisitos previos, mientras que NVD la califica como baja. En lo esencial coinciden: el ataque se puede hacer por red, sin credenciales y sin que nadie de tu empresa tenga que hacer clic en nada.

## ¿Se están explotando ya?

Aquí la respuesta honesta es que la información oficial no es concluyente, y conviene leerla con calma.

El [catálogo de vulnerabilidades explotadas de CISA](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) (la agencia de ciberseguridad de Estados Unidos, que mantiene la lista de referencia de fallos con explotación confirmada) no incluía ninguno de los dos CVE en su versión del 21 de octubre de 2026, consultada el 22 de octubre. Además, la valoración que CISA añadió el 21 de octubre a los [registros de CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109619) marca la explotación como «ninguna» en ese momento.

Por otro lado, el [aviso de INCIBE-CERT del 21 de octubre de 2026](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php) clasifica la importancia como crítica (5 sobre 5) y, aunque su tabla indica «Explotación: No», su descripción señala que se han comunicado ataques contra servidores PHP antes de la publicación de las actualizaciones, sin precisar cuál de los dos CVE se usó. El [CERT de las instituciones europeas (CERT-EU)](https://www.cert.europa.eu/publications/security-advisories/2026-018/) añade que ya circulan pruebas de concepto, lo que aumenta la probabilidad de ataques.

Nuestra lectura: no hay una confirmación oficial y consolidada de explotación masiva, pero los detalles técnicos ya son públicos. Lo razonable es actuar como si el riesgo fuera real y no esperar a que se confirme.

## ¿Cómo sé si mi empresa está afectada?

No necesitas ser técnico para hacer una primera comprobación. Estas son las vías más directas:

1. **Si tienes acceso al servidor**, la persona responsable puede ejecutar `php -v` en la terminal. El resultado muestra la versión, por ejemplo «PHP 8.3.x». Compárala con la tabla de arriba, basada en el [registro oficial de CVE.org](https://www.cve.org/CVERecord?id=CVE-2026-109618). Ojo: la versión de la línea de comandos puede no coincidir con la que usa la web, por lo que conviene revisar también la configuración del servidor web.
2. **Si tienes un alojamiento compartido o gestionado**, entra en el panel de tu proveedor de hosting y busca el apartado de configuración o versión de PHP. Muchos paneles muestran la versión activa de cada dominio.
3. **Si usas paquetes de una distribución Linux**, el número de versión puede no coincidir con el oficial, porque algunas distribuciones aplican las correcciones sin cambiar la numeración. El [anuncio de php.net](https://www.php.net/archive/2026.php#2026-10-21-5) indica que las distribuciones recibieron los parches por adelantado: consulta el boletín de seguridad de tu distribución.
4. **Si no gestionas tú el servidor**, escribe a tu proveedor de hosting o a la empresa que mantiene tu aplicación y pregúntale de forma concreta: «¿Qué versión de PHP usamos y está ya corregida frente a CVE-2026-109618 y CVE-2026-109619?». Puedes enlazarle el [aviso de INCIBE-CERT](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php).

Recuerda que PHP no siempre está a la vista: hay programas y equipos que lo incluyen por dentro. El [NCSC de Países Bajos mantiene un inventario público](https://github.com/NCSC-NL/php2shell) de productos de terceros con PHP que pueden verse afectados, y el [CERT-EU recomienda consultarlo](https://www.cert.europa.eu/publications/security-advisories/2026-018/).

![Esquema en cuatro pasos frente a PHP2Shell: comprobar la versión de PHP, compararla con las versiones corregidas 8.2.35, 8.3.36, 8.4.27 y 8.5.12, actualizar y, si no es posible todavía, aplicar medidas temporales, aislar el sistema y revisar los registros](https://nadiasolutions.com/blog/img/cmvjkiamx000ip407vcf2hkb2)

## ¿Qué debo hacer ahora?

La recomendación oficial es clara: actualizar. El [anuncio de php.net](https://www.php.net/archive/2026.php#2026-10-21-5) pide actualizar a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 según tu rama, y los avisos de GitHub insisten en que la actualización es la única mitigación completa ([GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)). Si estás en PHP 8.1 o anterior, el mismo anuncio aconseja contactar con tu proveedor de soporte o migrar a una versión mantenida.

Antes de actualizar en producción, lo sensato es probar la aplicación en un entorno de pruebas si lo tienes, hacer una copia de seguridad y, tras el cambio, reiniciar todos los procesos de PHP para que la nueva versión entre en uso.

Si no puedes actualizar de inmediato, el [equipo de PHP](https://www.php.net/archive/2026.php#2026-10-21-5) describe medidas temporales que reducen la exposición a rutas de ataque concretas, aunque advierte expresamente de que no dejan la instalación segura. Son ajustes técnicos que debe aplicar quien administra el servidor:

- Para CVE-2026-109618: fijar `memory_limit=-1` de forma que las aplicaciones no puedan cambiarlo, mantener bajo `post_max_size` (8M si no se suben archivos, 32M si es necesario), limitar en el servidor web o proxy el tamaño y la complejidad de las peticiones y no usar `RLIMIT_AS` ni `RLIMIT_DATA`. INCIBE advierte en su [aviso](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php) de que el valor -1 puede aumentar el consumo de memoria del servidor.
- Para CVE-2026-109619: desactivar `session.upload_progress.enabled` y, en PHP 8.5, `fatal_error_backtraces`, reiniciando todos los procesos; eliminar ajustes obsoletos o inválidos que se apliquen en cada petición y corregir errores fatales que un atacante pueda provocar ([aviso de GitHub](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)).

Si tienes un sistema expuesto a internet que no puedes actualizar, tanto [INCIBE-CERT](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php) como [CERT-EU](https://www.cert.europa.eu/publications/security-advisories/2026-018/) recomiendan aislarlo de las redes públicas hasta aplicar una versión corregida.

Por último, revisa los registros del servidor. Los propios investigadores de [Wiz](https://www.wiz.io/blog/php2shell-php-rce) señalan como señales a vigilar las peticiones con formularios multiparte inusuales seguidas de errores de memoria, errores 500 repetidos o reinicios inexplicados de los procesos de PHP. La ausencia de errores no prueba que no haya habido un ataque, pero su presencia es motivo para investigar.

## ¿Tu empresa está afectada? Te ayudamos a corregirlo

Actualizar PHP es el primer paso, pero no siempre es inmediato: aplicaciones antiguas, versiones sin soporte o integraciones poco documentadas pueden complicar el cambio.

Si tu empresa está afectada y quieres arreglarlo, en NADIA Solutions podemos hacerlo contigo: revisar qué sistemas están expuestos, actualizar PHP a una versión corregida o migrar desde una versión anterior a 8.2, que ya no tiene soporte, adaptar la aplicación si la actualización rompe algo y aplicar las medidas temporales mientras tanto. Desarrollamos [software a medida en Valencia](https://nadiasolutions.com/software-a-medida-valencia), así que el trabajo no se queda en el diagnóstico.

Escríbenos a [hola@nadiasolutions.com](mailto:hola@nadiasolutions.com) o desde el [formulario de contacto de la web](https://nadiasolutions.com/#contacto) y cuéntanos qué tienes. Lo revisamos contigo y te decimos qué pasos tienen sentido en tu caso.

## Fuentes
- [Security advisory: Critical remote code execution vulnerabilities, update now](https://www.php.net/archive/2026.php#2026-10-21-5) — The PHP Group (php.net)
- [PHP 8 ChangeLog (8.5.12, 8.4.27, 8.3.36, 8.2.35)](https://www.php.net/ChangeLog-8.php) — The PHP Group (php.net)
- [RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) — PHP Security Team (GitHub)
- [RCE via stale global state (GHSA-6wmf-4rv5-p3rp)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) — PHP Security Team (GitHub)
- [CVE-2026-109618](https://www.cve.org/CVERecord?id=CVE-2026-109618) — CVE Program (CVE.org)
- [CVE-2026-109619](https://www.cve.org/CVERecord?id=CVE-2026-109619) — CVE Program (CVE.org)
- [CVE-2026-109618 Detail](https://nvd.nist.gov/vuln/detail/CVE-2026-109618) — NIST National Vulnerability Database
- [CVE-2026-109619 Detail](https://nvd.nist.gov/vuln/detail/CVE-2026-109619) — NIST National Vulnerability Database
- [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — CISA
- [[Actualización 21/10/2026] Múltiples vulnerabilidades en PHP](https://www.incibe.es/incibe-cert/alerta-temprana/avisos/multiples-vulnerabilidades-en-php) — INCIBE-CERT
- [Critical Vulnerabilities in PHP (Security Advisory 2026-018)](https://www.cert.europa.eu/publications/security-advisories/2026-018/) — CERT-EU
- [PHP2Shell: AI uncovers critical RCE vulnerabilities](https://www.wiz.io/blog/php2shell-php-rce) — Wiz Research
- [NCSC-NL php2shell (inventario de software afectado)](https://github.com/NCSC-NL/php2shell) — NCSC-NL
- [CVSS v4.0 Specification Document](https://www.first.org/cvss/v4-0/specification-document) — FIRST
- [Alerta mundial por dos fallos críticos en PHP: qué riesgos afrontan millones de servidores web (22/10/2026)](https://amp.rtve.es/noticias/20261022/fallos-criticos-php2shell-vulnerabilidades-servidores-alerta-ciberseguridad/17277748.shtml) — RTVE

## Preguntas frecuentes

### ¿Es PHP2Shell el nombre oficial de estas vulnerabilidades?

No. Los avisos oficiales de PHP solo usan los identificadores CVE-2026-109618 y CVE-2026-109619. «PHP2Shell» es el nombre que les dieron los investigadores de Wiz en su propio análisis.

### ¿A qué versión de PHP tengo que actualizar?

A la versión corregida de tu rama: 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Si usas paquetes de una distribución Linux, comprueba en su boletín de seguridad que el paquete incluye la corrección.

### Mi web usa una versión de PHP anterior a la 8.2, ¿estoy afectado?

Debes considerarla afectada. Las versiones anteriores a PHP 8.2 no tienen soporte, y PHP ha tenido que publicar parches de urgencia para 7.4, 8.0 y 8.1. La solución es migrar a una versión mantenida, PHP 8.2 o superior, y en NADIA Solutions podemos ayudarte a hacerlo.

### ¿Basta con cambiar la configuración de PHP?

No. El equipo de PHP indica que las medidas de configuración solo reducen la exposición a ataques concretos y que la actualización es la única solución completa.

### ¿Se están explotando ya estas vulnerabilidades?

No hay una confirmación oficial consolidada: CISA no las incluía en su catálogo de vulnerabilidades explotadas al consultarlo, mientras que INCIBE-CERT menciona ataques comunicados antes del parche. Lo prudente es actualizar cuanto antes.

Contacto: hola@nadiasolutions.com · https://nadiasolutions.com/