PHP2Shell: qué es PHP, qué ha pasado y cómo proteger tu web y tu NAS

El 21 de octubre, a media tarde, medio Internet estaba actualizando servidores a toda prisa. Ese día salieron los parches de PHP2Shell, el nombre con el que se conoce a dos fallos muy graves en PHP. Durante unas horas, gobiernos de media Europa apagaron webs oficiales por precaución, y los fabricantes de NAS se pusieron a revisar sus sistemas uno por uno.

Ha pasado casi un mes y el tema ya no sale en los telediarios, pero no está cerrado. Hay servidores sin actualizar, hay ataques confirmados y queda un tercer fallo pendiente de parche. Así que vamos a contarlo con calma: qué es PHP, dónde se usa (seguramente en más sitios de los que crees), qué ha pasado exactamente y qué tienes que revisar en tu web, en tu NAS y en tus contenedores.

¿Qué es PHP?

PHP es un lenguaje de programación que nació a mediados de los años noventa para hacer páginas web «vivas». Una web estática envía siempre la misma página a todo el mundo. Una web hecha con PHP, en cambio, consulta una base de datos, comprueba si has iniciado sesión y monta la página para ti en el momento. Cuando entras en una tienda online y ves tu carrito, o cuando un blog te muestra sus últimas entradas, lo más probable es que detrás haya PHP trabajando.

Su gran baza siempre ha sido la sencillez: es fácil de aprender, funciona en casi cualquier alojamiento y tiene una comunidad enorme. Por eso, según los datos que recogió la agencia AFP, mueve aproximadamente el 70 % de las páginas web del mundo.

¿Qué aparatos y servicios usan PHP?

Aquí está la clave de por qué este fallo ha sido tan sonado. PHP no está solo en «las webs». Está en un montón de sitios que usamos a diario sin saberlo:

  • Gestores de contenidos: WordPress, Joomla y Drupal están hechos en PHP. Solo WordPress mueve una parte enorme de las webs de empresas, autónomos y blogs. Esta misma web, sin ir más lejos.
  • Tiendas online: PrestaShop, WooCommerce o Magento.
  • Herramientas de trabajo: Moodle para formación, Nextcloud para compartir archivos, phpMyAdmin para gestionar bases de datos, muchos CRM y ERP, y la propia Wikipedia, que funciona con MediaWiki.
  • El panel de tu NAS: varias marcas usan PHP en la interfaz web desde la que configuras el equipo. QNAP, por ejemplo, lo reconoce abiertamente en su aviso de seguridad.
  • Routers y cortafuegos: algunos sistemas muy populares en pymes, como pfSense u OPNsense, tienen su panel de administración escrito en PHP.
  • Contenedores Docker: si tienes un WordPress, un Nextcloud o cualquier aplicación PHP en un contenedor, ese contenedor lleva su propio PHP dentro, independiente del de tu sistema.

Este último punto es importante y volveremos a él, porque es justo el que más gente se deja por el camino.

¿Qué es PHP2Shell y por qué es tan grave?

PHP2Shell es el nombre que se dio a dos vulnerabilidades del propio motor de PHP, registradas como CVE-2026-109618 y CVE-2026-109619. Las dos tienen una puntuación de gravedad de 9,2 sobre 10 y permiten algo que en seguridad informática es lo peor que puede pasar: que un atacante ejecute código en tu servidor sin necesidad de usuario ni contraseña.

Explicado sin tecnicismos, las dos tienen que ver con cómo PHP gestiona la memoria. Según el aviso oficial de PHP, en la primera, si PHP se queda sin memoria en un momento concreto, puede dejar datos a medio preparar que luego trata como válidos. En la segunda, restos de una petición anterior sobreviven en memoria cuando ya deberían haberse borrado, y la siguiente petición puede tropezar con ellos. Un atacante que sepa provocar esas situaciones puede acabar dando órdenes al servidor.

¿Por qué ha asustado tanto? Por tres motivos:

  • El fallo está en el motor, no en la aplicación. Da igual que tu WordPress esté impecable y con todos los plugins al día: si el PHP que hay debajo es vulnerable, la web también lo es. Por eso, como explica Escudo Digital, ni los plugins de seguridad ni el modo mantenimiento de WordPress sirven para frenarlo.
  • Afecta a muchísimas versiones. Según Wiz, una de las empresas que lo descubrieron, están afectadas prácticamente todas las versiones publicadas en la última década, desde PHP 5.4.
  • Además de ejecutar código, permite leer memoria. Como explica WWWhat’s new, incluso sin llegar a tomar el control, un atacante puede leer trozos de la memoria de PHP, y ahí pueden quedar contraseñas, claves de API o sesiones de usuario.

Para hacerse una idea del tamaño del problema: el buscador Censys contabilizó, el 22 de octubre, unos 36,7 millones de servicios en Internet que mostraban versiones de PHP potencialmente afectadas.

Cómo se descubrió: la inteligencia artificial entra en escena

Lo curioso de este caso es quién lo encontró. La empresa de ciberseguridad Calif y OpenAI comunicaron al equipo de PHP el mismo problema por separado, el mismo día, el 11 de agosto. Dos semanas después, el equipo de investigación de Wiz llegó por su cuenta a resultados parecidos usando modelos de inteligencia artificial de OpenAI y Google, tal como recoge Forbes Argentina. Durante unos dos meses se trabajó en silencio en el arreglo, como cuenta la propia OpenAI.

El plan se torció en el último momento. El 20 de octubre, PHP avisó de que al día siguiente publicaría un parche crítico, pero parte de los detalles ya se habían filtrado. Amazon detectó intentos de ataque desde el 17 de octubre, cuatro días antes de que existiera el arreglo. Y el 26 de octubre, la agencia estadounidense CISA lo incluyó en su lista de fallos que ya se están explotando en ataques reales.

Cronología de PHP2Shell: del aviso de agosto a los parches del 21 de octubre y los ataques confirmados por CISA
Los momentos clave de PHP2Shell.

Es una buena noticia y una mala a la vez. La buena: la IA ayuda a encontrar fallos que llevaban años escondidos. La mala: esa misma ayuda la tienen los atacantes, y el tiempo entre que se publica un fallo y alguien lo aprovecha es cada vez más corto.

Gobiernos que apagaron sus webs (y su «Cl@ve»)

La reacción más llamativa llegó de las administraciones públicas. Ante la duda, muchas prefirieron desconectar servicios durante unas horas antes que arriesgarse.

El caso más parecido a lo que sería en España tocar Cl@ve ocurrió en los Países Bajos. Allí, el Gobierno desconectó la web de DigiD, el sistema de identificación digital con el que los ciudadanos hacen sus trámites con la Administración, y no volvió a estar disponible hasta la noche del 21 de octubre, según la agencia de noticias neerlandesa ANP. También cayeron el portal central del Gobierno, la web de la Cámara de Representantes y hasta la página del propio centro nacional de ciberseguridad.

No fueron los únicos. La República Checa apagó la web de su Gobierno esa misma noche, Finlandia y Dinamarca hicieron lo propio con varios servicios públicos, y en Alemania y Francia se desconectaron webs federales y de prefecturas, según recogen Escudo Digital y Delfino. En el Reino Unido llegaron a estar caídos, total o parcialmente, varias decenas de servicios del Gobierno, y en Canadá se retiraron algunas webs federales, como detalla Hard2bit.

¿Y España? Aquí no hubo un apagón de los grandes portales de los ministerios. El INCIBE publicó su aviso con nivel crítico el mismo día 21 y recomendó aislar de Internet lo que no se pudiera actualizar, y el CCN-CERT pidió actualizar con urgencia. Algunas administraciones locales, universidades y centros de investigación sí abrieron ventanas de mantenimiento nocturnas para parchear.

Un matiz importante para que nadie se asuste de más: que una web pública estuviera apagada no significa que la hubieran atacado. Fue una medida preventiva, el equivalente a echar el cierre mientras se cambia la cerradura.

Qué han hecho QNAP y Synology

Como contábamos antes, los NAS también usan PHP, así que los fabricantes tuvieron que mover ficha. Y no todos estaban en la misma situación.

QNAP

QNAP lo tenía más complicado, porque usa PHP en las funciones web del propio sistema operativo y en varias aplicaciones. Publicó el aviso QSA-26-18 el 22 de octubre y, dos días después, ya tenía corregidos sus tres sistemas. Estas son las versiones que tienes que tener como mínimo:

  • QTS 5.2: 5.2.11.3661 build 20261023.
  • QTS 6.1: 6.1.0.3656 build 20261023.
  • QuTS hero: h5.2.11.3661, h6.0.2.3656 o h6.1.0.3656, según tu rama, todas del 23 de octubre.
  • QuTScloud: c5.2.9.3661 build 20261023.
  • Aplicaciones: Notes Station 3 se corrigió en la 3.9.15, y también hay arreglos para QVR Surveillance.

Mientras tanto, QNAP recomendaba quitar el NAS de Internet: cerrar las redirecciones de puertos y el UPnP del router, desactivar myQNAPcloud Link, entrar solo por VPN y parar las aplicaciones que no se usen. Y hay un detalle que nos interesa especialmente a los que usamos Docker: QNAP aclara que su actualización no cubre el PHP que va dentro de los contenedores de Container Station. Eso es cosa tuya, como veremos ahora.

Synology

Synology lo tuvo algo más fácil. Según su comunicado oficial, el problema solo afecta a quienes tienen instalados paquetes que dependen de PHP, como Web Station, WordPress, phpMyAdmin, MediaWiki, Joomla, Calendar o MailStation. El PHP interno de DSM no tiene partes accesibles desde fuera, así que lo consideran de riesgo mínimo.

La solución es actualizar PHP desde el Centro de paquetes, y lo han hecho incluso para versiones de DSM que ya no tienen soporte, desde la 6.2 hasta la 7.4. Ojo con MailStation, que hay que actualizar a mano. Y un aviso que conviene leer: revisando el impacto de PHP2Shell, Synology detectó una campaña de ransomware contra equipos con versiones antiguas de DSM, aprovechando un fallo que ya se había corregido en diciembre de 2024. Moraleja: un NAS sin actualizar es un NAS en riesgo, haya o no noticias en la tele.

Cómo saber si estás afectado y cómo solucionarlo

Vamos a lo práctico. Esto es lo que tienes que revisar, por orden de importancia.

1. Tu web o tu tienda online

Si tu web está en un alojamiento compartido, lo más probable es que tu proveedor ya haya actualizado. Pero compruébalo. En WordPress, entra en Herramientas > Salud del sitio > Información > Servidor y mira la versión de PHP. Tienes que tener como mínimo una de estas:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Por si te sirve de referencia, esta misma web ya funciona con PHP 8.3.36. Si tienes PHP 8.1 o anterior, tenemos un problema más serio: esas versiones ya no reciben actualizaciones del proyecto PHP. Existen algunos parches mínimos para 7.4, 8.0 y 8.1, pero lo sensato es pedir a tu proveedor que te pase a una versión con soporte. Y ve pensando en el siguiente salto, porque PHP 8.2 deja de recibir parches el 31 de diciembre de este año.

2. Si gestionas tu propio servidor

Actualiza los paquetes de PHP de tu sistema y reinicia todos los procesos de PHP (PHP-FPM, Apache, LiteSpeed…). Según el aviso oficial, las instalaciones con Apache y mod_php son las de mayor riesgo.

Si no puedes actualizar ya mismo, PHP propone una medida temporal: añadir esta línea en el php.ini o en la configuración del pool de PHP-FPM, y reiniciar.

session.upload_progress.enabled=0

Tiene que ir en la configuración del servidor, no en un .user.ini ni con ini_set() desde la aplicación. Y que quede claro: es un parche de emergencia que bloquea los caminos de ataque conocidos, no una solución. El propio equipo de PHP insiste en que actualizar es la única opción segura.

3. Tu NAS

En QNAP, ve a Panel de control > Sistema > Actualización de firmware y comprueba que tienes, como mínimo, la versión que corresponde a tu sistema de la lista de arriba. En Synology, abre el Centro de paquetes y actualiza PHP y los paquetes que dependan de él. Y en cualquier marca, aprovecha para revisar que el panel de administración no está abierto a Internet. Si necesitas entrar desde fuera, hazlo por VPN.

4. Tus contenedores Docker

Este es el punto que más gente olvida. Cada contenedor de WordPress, Nextcloud o cualquier aplicación PHP lleva su propio PHP, y ni QNAP ni Synology lo actualizan por ti. Para comprobar qué versión tiene un contenedor, puedes usar este comando, cambiando wordpress por el nombre de tu contenedor:

docker exec wordpress php -v

Si sale una versión anterior a las de la lista, descarga la imagen nueva y vuelve a crear el contenedor. Desde la carpeta de tu Docker Compose, o desde Container Station volviendo a desplegar la aplicación:

docker compose pull
docker compose up -d

Si es la primera vez que oyes hablar de esto, en nuestra serie te explicamos qué es Docker y cómo usarlo en un NAS QNAP.

5. Comprueba que nadie ha entrado

Como hubo ataques antes incluso de que existiera el parche, actualizar no basta si tu web estuvo expuesta esos días. Revisa que no haya usuarios administradores que no reconozcas, archivos nuevos o modificados en tu web y accesos raros en los registros del servidor o del NAS. Si tienes la más mínima duda, cambia las contraseñas de la web, de la base de datos y las claves de API que uses, porque, como decíamos, el fallo permitía leer memoria donde pueden quedar esos datos.

Ojo: todavía queda un tercer fallo por parchear

Por si fuera poco, el 23 de octubre PHP avisó de otra vulnerabilidad, la CVE-2026-115560, que también permite ejecutar código. La buena noticia es que solo afecta a aplicaciones con una combinación de ajustes muy poco habitual, y que, según Escudo Digital, no se conocen ataques que la aprovechen. La mala es que, a día de hoy, no tiene parche: llegará con la próxima actualización ordinaria de PHP.

La medida para protegerse es la misma línea de antes, session.upload_progress.enabled=0. Si ya la aplicaste para PHP2Shell, déjala puesta. Y si llevas una web importante, estate atento a las próximas versiones de PHP de las próximas semanas.

Conclusión

PHP2Shell no ha sido el fin de Internet, pero sí un buen aviso. Nos recuerda que un fallo en una pieza que nadie ve puede poner en jaque desde la web de una ferretería hasta el sistema de identificación de un país entero, y que la inteligencia artificial está acelerando tanto el descubrimiento de fallos como los ataques.

La receta, en el fondo, es la de siempre: mantener actualizado todo lo que tengas conectado a Internet, también lo que no se ve, como el PHP de un contenedor o el firmware del NAS; no publicar paneles de administración; y tener copias de seguridad para cuando algo falla. En la mayoría de los casos, revisar todo lo que te hemos contado es cuestión de un rato.

¿Te llegó a afectar PHP2Shell? ¿Tu proveedor de hosting te avisó? Cuéntanoslo en los comentarios.

Fuentes y enlaces útiles

¿Quieres que revisemos tu web, tu NAS o tus servidores? Déjanos tus dudas en los comentarios o contacta con nosotros.

Artículos Relacionados

Docker en QNAP: NAS con contenedores apilados encima

Docker en QNAP: cómo usar Container Station en tu NAS

Guía para usar Docker en QNAP con Container Station: requisitos reales, cómo organizar las carpetas, tu primer contenedor con Docker Compose, la consola SSH y qué conviene dockerizar. Segundo capítulo de nuestra serie sobre Docker.