El 20 de octubre de 2026, el equipo de seguridad de PHP hizo algo que no hace casi nunca: avisar con antelación de que al día siguiente iba a publicar una actualización crítica. Querían que los administradores de medio mundo estuvieran delante del teclado cuando saliera.
El 21 de octubre salieron las cuatro versiones corregidas y, con ellas, un aviso de seguridad cuyo título lo dice todo: «vulnerabilidades críticas de ejecución remota de código, actualice ya». Ese mismo día, INCIBE-CERT elevó su aviso a criticidad crítica y varias empresas de seguridad empezaron a reportar intentos de explotación reales.
El motivo son dos fallos que la comunidad ha bautizado como PHP2Shell: CVE-2026-109618 y CVE-2026-109619. Los dos puntúan 9,2 sobre 10 en la escala CVSS 4.0. Y los dos permiten lo peor que puede permitir un fallo: que alguien ejecute código en tu servidor sin usuario y sin contraseña.
Este artículo no va a repetir lo que ya puedes leer en diez sitios. Va a responder a las dos preguntas que de verdad se hace quien tiene una empresa: cómo sé si me afecta y qué hago si resulta que no puedo arreglarlo.
Qué es PHP2Shell y por qué te afecta aunque tu web «no haga nada raro»
PHP es el lenguaje en el que está hecha buena parte de la web. WordPress, WooCommerce, Moodle, PrestaShop, Nextcloud y miles de aplicaciones corporativas a medida funcionan sobre él.
Aquí está lo importante, y es lo que más cuesta de entender: el fallo no está en tu web, está en el motor que la ejecuta.
Esa distinción no es un matiz técnico, tiene una consecuencia muy concreta. PHP procesa la petición que llega de internet antes de que se ejecute una sola línea de tu aplicación. Eso significa que:
- No lo arregla ningún plugin de seguridad.
- No lo arregla el modo mantenimiento.
- No lo arregla tener la web actualizada ni un buen firewall de aplicación.
- No importa lo bien hecha que esté tu web.
El atacante no necesita llegar a tu web. Le basta con llamar a la puerta.
Los dos fallos son distintos por dentro: el CVE-2026-109618 se aprovecha de una corrupción de memoria cuando el proceso se queda sin ella, y el CVE-2026-109619 de un estado interno que queda sucio entre una petición y la siguiente. Uno de ellos, además, permite leer trozos de la memoria del servidor, que es donde viven las contraseñas de la base de datos y las sesiones de tus usuarios.
Afecta a todas las formas de servir PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El propio equipo de PHP señala que el riesgo es mayor en Apache con mod_php, la configuración más habitual en hosting compartido y en servidores montados hace años.
Las versiones corregidas
Solo hay cuatro. Si tu PHP es anterior a la de su rama, estás expuesto:
| Rama | Versión corregida | Anuncio oficial |
|---|---|---|
| PHP 8.5 | 8.5.12 | php.net |
| PHP 8.4 | 8.4.27 | php.net |
| PHP 8.3 | 8.3.36 | php.net |
| PHP 8.2 | 8.2.35 | php.net |
Si usas PHP 8.1 o anterior, el problema es más gordo que este fallo concreto: esas ramas ya no reciben parches de seguridad de ningún tipo. Puedes comprobar qué ramas siguen soportadas en la página oficial de versiones de PHP.
Cómo saber si tu web está afectada
Solo necesitas un dato: la versión exacta de PHP que está corriendo. Es el mismo dato tanto si tienes la web en un hosting contratado, como en un servidor propio, como en un sistema montado a medida. Lo único que cambia es dónde se mira.
Y lo vas a comparar contra los cuatro números de la tabla de arriba: 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12. Fíjate siempre en el tercero, que es el que confunde a todo el mundo: «tengo PHP 8.3» no dice nada; lo que hay que saber es si es 8.3.36 o algo menor.
1. En el panel de tu hosting
Casi todos los paneles (cPanel, Plesk, Hostinger, SiteGround, IONOS…) tienen una sección llamada «Versión de PHP» o «Selector de PHP». Ahí verás un número completo, del tipo 8.2.20 o 8.3.33. Ese es el que importa.
2. Míralo desde dentro de WordPress
Si tienes WordPress, entra en Herramientas → Salud del sitio → Información → Servidor. La «Versión de PHP» aparece ahí, completa.
3. Si tienes servidor propio
Si la web está en una máquina vuestra —física, virtual o en la nube—, se ve con una orden:
« php -v «
La primera línea devuelve la versión. ⚠️ Cuidado con un detalle que engaña: esa orden te dice la versión del PHP de la línea de comandos, que no siempre es la misma que usa la web. Si la web va con PHP-FPM, Apache con mod_php o similar, la que cuenta es la del servidor web. La forma segura de salir de dudas es mirar la página de información de PHP o preguntárselo a quien lo administre.
Y si el servicio corre en contenedores, ojo con algo importante: la versión de PHP viene dentro de la imagen. Puede que tu sistema operativo esté al día y el PHP siga siendo antiguo.
4. Si es un producto cerrado o un sistema a medida
Aplicaciones que se instalan como un paquete, appliances de fabricante, software antiguo que solo funciona con una versión concreta. Aquí el PHP no lo eliges tú: viene dentro. Normalmente la versión aparece en el panel de administración del propio producto, en un apartado tipo «Información del sistema» o «Estado».
Es el caso más incómodo de todos, y es del que trata el apartado «Qué hacer si no puedes actualizar PHP», más abajo.
5. Pídeselo a quien te lleva el servidor
Un correo de dos líneas:
¿Qué versión exacta de PHP está corriendo nuestra web, y está ya parcheada contra CVE-2026-109618 y CVE-2026-109619?
La respuesta debería ser un número concreto y una fecha. Si lo que recibes es «está todo correcto» o «nosotros nos encargamos de eso», no has recibido una respuesta. Insiste.
Señales de que alguien ya lo ha intentado
Si tienes acceso a los registros del servidor, estas cuatro cosas son compatibles con un intento de explotación:
- Peticiones
multipartextrañas seguidas de errores de límite de memoria. - Oleadas repentinas de errores HTTP 500.
- Cookies
PHPSESSIDanormalmente grandes. - Procesos del servidor web reiniciándose sin explicación.
Ninguna de las cuatro prueba por sí sola que te hayan entrado. Todas juntas, y de golpe, merecen una revisión seria.
Lo que nos encontramos nosotros: dos servidores, dos finales distintos
El día del aviso revisamos nuestra propia infraestructura, servicio por servicio, midiendo la versión real de cada uno en lugar de fiarnos de lo que creíamos tener. Encontramos cuatro servicios en PHP y la foto fue muy desigual.
El primero, nuestra propia web. Corría una versión vieja y era vulnerable. Como el PHP viene de una imagen que reconstruimos nosotros, bastó con reconstruirla: entró la versión corregida, se verificó que el sitio seguía funcionando y se acabó. Diez minutos.
El segundo fue otra historia. Es una herramienta de uso diario, servida con Apache y mod_php, es decir, en la configuración de más riesgo. Su versión de PHP era vulnerable y no había forma de cambiarla: el fabricante congeló esa versión del producto en junio de 2024 y nunca volvió a empaquetarla con un PHP nuevo. No existe una versión corregida de lo que teníamos instalado.
La única salida real era subir el producto entero seis versiones mayores encadenadas, una detrás de otra, con sus migraciones de base de datos y sus complementos rompiéndose por el camino. Y hubo una trampa que merece la pena contar: subir solo un escalón no servía de nada, porque la siguiente versión seguía trayendo un PHP vulnerable. Para que entrara un PHP corregido había que llegar hasta la última. Eso no se ve hasta que lo compruebas.
Mientras tanto, lo cerramos a cal y canto: solo entra una dirección IP concreta. Funciona, pero es un parche, y lo sabemos.
Los otros dos servicios estaban parados. No escuchaban peticiones, así que no estaban expuestos. También conviene decirlo: uno de ellos llevaba una rama de PHP sin soporte desde hacía tiempo. Estaba a salvo por accidente, no por diseño.
Y una cosa más, porque es la que más nos sorprendió: el fallo del que hablaba la prensa esos días no era este. Había otro CVE de PHP circulando por los titulares que no nos afectaba en absoluto, porque solo aplicaba a servidores Windows con una configuración concreta. El que sí nos afectaba no salía en ningún sitio. Gestionar vulnerabilidades por titulares es una forma muy fiable de parchear lo que no toca.
Qué hacer si no puedes actualizar PHP
Esta es la parte que casi nadie cuenta, y es la situación en la que está mucha gente: sabes que tienes un PHP vulnerable y no puedes tocarlo, porque el PHP viene dentro de otra cosa.
Pasa más de lo que parece. Aplicaciones que se distribuyen como un paquete cerrado con su propio PHP dentro. Appliances y máquinas virtuales de fabricante. Software antiguo que solo funciona con una versión concreta. Hosting compartido donde la versión la decide el proveedor.
1. La única solución completa es actualizar
Hay que decirlo claro antes de hablar de parches: todo lo demás son medidas para ganar tiempo, no soluciones. Si puedes actualizar, actualiza y deja de leer aquí.
2. Si no puedes, aísla
Es la recomendación oficial, y es la correcta: un sistema vulnerable y expuesto a internet debe dejar de estar expuesto a internet hasta que puedas parchearlo.
En la práctica significa restringir el acceso a las direcciones IP que lo necesitan, meterlo detrás de una VPN, o las dos cosas. Es incómodo para quien lo usa y es exactamente lo que hicimos nosotros. Pero entre incómodo y comprometido, no hay debate.
Ahora, lo que casi nadie dice sobre aislar.
Aislar reduce la exposición. No arregla la vulnerabilidad. El fallo sigue ahí, intacto, esperando a que alguien le llegue; lo único que has hecho es quitar la cola de gente que podía intentarlo desde internet.
Y esa diferencia importa mucho más de lo que parece, porque los ataques no entran solo por la puerta de delante:
- Un portátil infectado con un correo, dentro de tu oficina, está dentro de tu red.
- Un proveedor con acceso a tu VPN está dentro.
- Un servidor tuyo ya comprometido es el trampolín perfecto para llegar al que has aislado.
- Y alguien de la propia casa, con o sin mala intención, está dentro por definición.
Es decir: has pasado de «cualquiera en internet podría intentarlo» a «solo quien ya esté dentro podría intentarlo». Es una mejora enorme, pero no es estar a salvo. Quien te diga que con aislar ya está resuelto, o no lo sabe o no te lo está contando.
Por eso conviene tener clara la diferencia entre los dos tipos de medida:
| Qué hace | Cuánto dura | |
|---|---|---|
| Actualizar | Elimina la vulnerabilidad | Definitivo |
| Aislar | Reduce quién puede alcanzarla | Temporal. Sirve hasta que puedas actualizar |
| Ajustes de configuración | Estorban algunas formas de aprovecharla | Paliativo. Horas o días, con vigilancia |
Un aislamiento no tiene fecha de caducidad escrita en ningún sitio, y ese es justo el peligro: lo normal es que se quede ahí años, porque «total, ya no se ve desde fuera». Si aíslas, apunta la fecha en la que vas a volver.
3. Las mitigaciones parciales, con honestidad
Circulan tres ajustes de configuración de PHP como mitigación temporal. Vale la pena entender qué hacen y qué riesgo traen:
session.upload_progress.enabled=0— desactiva una función de seguimiento de subidas que poca gente usa. Mitiga parcialmente uno de los dos fallos y el efecto secundario es mínimo. Es la más razonable de las tres, y de hecho es la única que el propio equipo de PHP recomendó expresamente en un aviso aparte, dos días después del parche.- Reducir
post_max_size— limita el tamaño de lo que se puede enviar al servidor. Reduce la superficie de ataque, pero si tu web admite subida de ficheros, los vas a romper. memory_limit=-1— esta hay que explicarla, porque parece lo contrario de lo que debería ser. La idea es que uno de los fallos se dispara cuando el proceso se queda sin memoria; si se le quita el límite, no se queda sin ella. El problema es evidente: un servidor sin límite de memoria es un servidor que se puede tumbar entero con unas cuantas peticiones. Cambias un riesgo por otro, y solo tiene sentido en un entorno vigilado y durante unas horas.
Ninguna de las tres cierra el agujero. Sirven para aguantar hasta la ventana de mantenimiento, nada más.
4. Vigila mientras tanto
Si vas a convivir unos días con un sistema vulnerable, al menos entérate si pasa algo: revisa los registros buscando las señales de arriba y asegúrate de tener una copia de seguridad reciente y probada. Una copia que nunca has restaurado no es una copia.
La pregunta que deberías hacerle a tu proveedor
Si de todo esto te quedas con una sola cosa, que sea esta.
La diferencia entre nuestros dos servidores —diez minutos contra una migración de seis saltos— no la decidió el fallo de PHP. La decidió, dos años antes, cómo estaba empaquetado cada software y si quien había detrás seguía manteniéndolo.
Eso no se ve en una demo. No sale en la comparativa de funciones ni en el precio. Se ve el día que sale un fallo crítico y tienes que ir a mirar.
Así que la próxima vez que vayas a contratar una herramienta que sostenga algo importante de tu empresa, añade una pregunta a la lista:
Cuando salga un fallo crítico en una de las piezas que lleva esto dentro, ¿cuánto tardáis en sacar una versión corregida, y qué tengo que hacer yo para instalarla?
Si no saben contestar, ya tienes tu respuesta.
Y hazte la misma pregunta puertas adentro: de las aplicaciones que sostienen tu empresa, ¿cuáles podrías actualizar esta tarde y cuáles no? Esa lista, escrita, vale más que cualquier auditoría que te vendan.
La oferta de MagicBoxDesk: que esto no sea tu problema
Lo que hicimos ese día —revisar servicio por servicio, medir la versión real de cada uno, parchear lo que se podía y aislar lo que no— es, literalmente, el trabajo que hacemos para nuestros clientes todas las semanas.
En nuestro servicio de ciberseguridad gestionada eso incluye:
- Inventario real de qué versiones corren tus sistemas, medido y no supuesto.
- Vigilancia de vulnerabilidades que te afectan a ti, no de las que salen en los titulares.
- Parcheo gestionado, con ventana de mantenimiento y marcha atrás preparada.
- Mitigación y aislamiento cuando el parche no existe todavía — con fecha de revisión, no para siempre.
- Copias de seguridad con restauración probada, porque el plan B solo cuenta si se ha ensayado.
Trabajamos con pymes de 5 a 300 empleados en Alicante, Barcelona y en remoto para toda España. Precio cerrado y eliges cuánto delegas.
Y hay un caso más, que es el más común de todos y del que no se habla: que sepas perfectamente lo que hay que hacer y no tengas manos para hacerlo. Una semana como esta son horas que nadie tenía previstas, encima del trabajo de siempre. Ahí también entramos: no para sustituir a nadie, sino para absorber el pico y devolverte los sistemas al día.
Si al leer esto no sabes qué versión de PHP corre tu web —o lo sabes y no llegas—, hablemos 30 minutos. Sin compromiso, y de esa llamada sales sabiendo qué te toca.
Fuentes
Todo lo que se afirma aquí sale de estas fuentes. Si solo vas a abrir una, que sea la primera.
Oficiales
- Aviso de seguridad de PHP — «Critical remote code execution vulnerabilities, update now», 21/10/2026. La fuente primaria.
- Aviso previo del equipo de seguridad de PHP, 20/10/2026.
- Aviso informativo sobre
session.upload_progress, 23/10/2026. - ChangeLog de PHP 8 — el detalle de qué cambió en cada versión corregida.
- Versiones de PHP con soporte — para saber si tu rama sigue recibiendo parches.
Instituciones
- INCIBE-CERT — Múltiples vulnerabilidades en PHP, actualizado el 21/10/2026 y elevado a criticidad crítica. Es la referencia española.
Las fichas de las vulnerabilidades
- CVE-2026-109618 — ejecución remota por corrupción de memoria.
- CVE-2026-109619 — ejecución remota por estado global sin limpiar.
Análisis técnico y seguimiento de la explotación
