PHP2Shell es el nombre de dos vulnerabilidades críticas en PHP, el lenguaje con el que funciona la mayoría de los sitios web, registradas como CVE-2026-109618 y CVE-2026-109619 con una calificación de 9.2 sobre 10. Permiten que alguien ejecute código en un servidor web sin usuario ni contraseña. PHP las corrigió el 21 de octubre de 2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y actualizar es la única solución completa.
Si tu empresa tiene un sitio, una tienda en línea, un portal de clientes o una intranet hecha en PHP, el trabajo de esta semana es concreto: ubicar dónde corre, actualizar y vigilar mientras tanto. Te explicamos cómo hacerlo y lo que ya hicimos con los entornos de nuestros clientes desde el día del aviso.
Qué es PHP2Shell y por qué es tan grave
PHP es el lenguaje que corre en el servidor y arma las páginas de un sitio cada vez que alguien las visita o envía un formulario. Según W3Techs, lo usa el 69.3% de los sitios cuyo lenguaje de servidor se conoce; de ahí sale la cifra de "7 de cada 10 sitios" que circula en las noticias.
PHP2Shell permite una ejecución remota de código: que un atacante, desde internet y sin usuario ni contraseña, haga que el servidor ejecute las instrucciones que él quiera.
Son dos errores en la forma en que PHP administra su memoria:
- CVE-2026-109618: cuando PHP se queda sin memoria a mitad de una petición, como al recibir un archivo por un formulario, deja datos a medio preparar que después trata como válidos.
- CVE-2026-109619: información de una visita anterior queda guardada en el proceso que atiende al sitio, y la siguiente visita puede usarla. Además de permitir la ejecución de código, puede dejar ver fragmentos de memoria con datos de otras sesiones.
Lo que la hace seria es el momento en que ocurre: PHP procesa la petición maliciosa antes de que cargue tu sitio. Por eso el inicio de sesión de tu aplicación no la frena, y no importa qué tan bien esté programado tu sitio: la falla está en PHP, no en tu código.
Qué anunció PHP y por qué conviene actuar esta semana
PHP, uno de los lenguajes más extendidos de la web, tuvo que publicar correcciones para dos vulnerabilidades críticas. Lo comunicó en su aviso oficial, y esta es la secuencia:
- 17 de octubre de 2026: Amazon registra en su red de señuelos un intento de explotación, cuatro días antes del aviso público.
- 20 de octubre: PHP anuncia que al día siguiente publicará una actualización de seguridad para dos CVE críticos, ambos calificados con 9.2.
- 21 de octubre: PHP publica las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, junto con medidas temporales para quien no pueda actualizar de inmediato.
El Equipo de Respuesta a Emergencias Informáticas de la Unión Europea (CERT-EU) considera probable que ya se esté explotando, porque los detalles técnicos se discuten en público. Al 22 de octubre, la agencia de ciberseguridad de Estados Unidos (CISA) no la había agregado a su catálogo de vulnerabilidades explotadas. Con cualquiera de las dos lecturas, la conclusión es la misma: el tiempo entre que sale un parche y aparecen los primeros ataques es cada vez más corto.
¿Tu empresa está expuesta? Cómo saberlo en una tarde
Cualquier servidor que use PHP para atender páginas web está afectado, sin importar si usa Apache, Nginx con PHP-FPM, LiteSpeed u otra configuración. Están en riesgo todas las versiones anteriores a las corregidas, incluidas las ramas que ya no reciben soporte. La pregunta útil no es si usas PHP, sino dónde:
- ☐ Tu sitio web corporativo, sobre todo si está hecho en WordPress, Drupal o Joomla.
- ☐ Tu tienda en línea, si usa Magento, PrestaShop o WooCommerce.
- ☐ Portales de clientes, de proveedores o de facturación desarrollados a la medida.
- ☐ La intranet o herramientas internas que tu equipo usa desde el navegador.
- ☐ Equipos y programas de otras marcas que traen PHP por dentro, como consolas de administración; varios fabricantes ya están revisando sus productos.
- ☐ Sitios de campañas o micrositios que hizo una agencia y que nadie volvió a revisar.
Para cada uno, la persona responsable o tu proveedor de hosting debe decirte qué versión de PHP corre. En un servidor propio, tu equipo lo confirma en segundos:
Con esa respuesta, esta tabla te dice qué hacer:
| Si tu versión es... | Versión corregida | Qué hacer |
|---|---|---|
| PHP 8.5 | 8.5.12 | Actualizar y reiniciar los procesos de PHP |
| PHP 8.4 | 8.4.27 | Actualizar y reiniciar los procesos de PHP |
| PHP 8.3 | 8.3.36 | Actualizar y reiniciar los procesos de PHP |
| PHP 8.2 | 8.2.35 | Actualizar y reiniciar los procesos de PHP |
| PHP 8.1, 8.0 o 7.4 | Sin versión oficial | Pedir a tu proveedor la corrección para tu versión (PHP publicó parches de código para estas ramas) y planear la migración a una versión con soporte |
| PHP 7.3 o anterior | Sin corrección | Migrar a una versión con soporte o aislar el servidor de internet mientras tanto |
Si tu sitio vive en un hosting compartido, no puedes actualizar PHP por tu cuenta: pide por escrito a tu proveedor la versión exacta y la fecha en que aplicó la corrección. Lo mismo con los equipos de otras marcas: la corrección llega con la actualización del fabricante.
Qué hacer esta semana: actualizar, reiniciar y contener lo que no puedas actualizar
El aviso oficial de PHP es claro: no hay mitigación completa, solo la actualización. El orden que recomendamos es este:
- Prioriza lo que está expuesto a internet. Primero los servidores accesibles desde fuera; después, los internos.
- Actualiza a la versión corregida de tu rama. Si usas los paquetes de tu distribución de Linux, la mayoría ya publicó la corrección; tu equipo debe confirmar la versión instalada después de actualizar.
- Reinicia los procesos de PHP. Una de las fallas vive en procesos que siguen corriendo, así que actualizar sin reiniciar deja el riesgo activo.
- Si no puedes actualizar hoy, reduce la exposición. PHP publicó ajustes temporales que tu equipo puede aplicar en la configuración del servidor, como desactivar el seguimiento del progreso de subidas de archivos (
session.upload_progress.enabled=0) y limitar el tamaño de las peticiones. Ayudan, pero no sustituyen al parche. - Aísla lo que no tenga corrección. Si un servidor no puede actualizarse, sácalo de internet o ponlo detrás de un acceso restringido hasta resolverlo.
Así se ven los pasos 2 y 3 en un servidor Linux con PHP 8.3:
Si tu sitio pasa por un firewall de aplicaciones web (WAF) o una red de distribución de contenido, revisa con el proveedor si ya activó reglas para esta falla; varias empresas del sector las liberaron el mismo día. Son una capa extra mientras actualizas, no un reemplazo. Este ciclo de detectar, priorizar, aplicar y comprobar es justo lo que ordena una buena gestión de parches.
Señales de que alguien lo está intentando en tu servidor
Como el ataque ocurre antes de que cargue tu aplicación, los registros del sitio suelen decir poco. Conviene vigilar estas señales en el servidor mientras terminas de actualizar:
- Envíos de archivos poco comunes seguidos de errores de falta de memoria.
- Ráfagas de errores 500, el código que muestra un sitio cuando algo falla del lado del servidor.
- Cookies de sesión de un tamaño o formato fuera de lo normal en las respuestas del sitio.
- Procesos de PHP que se reinician sin una causa clara.
Ninguna de estas señales prueba un ataque por sí sola. Lo que importa es correlacionarlas, revisar si después del intento el servidor abrió conexiones o ejecutó programas inusuales y actuar rápido. Eso es trabajo de vigilancia continua con detección de intrusos y análisis de cada alerta, no de una revisión manual una vez a la semana.
Cómo te ayuda TecnetSOC con PHP2Shell
Desde el aviso del 21 de octubre, en TecnetSOC identificamos los servidores expuestos en los entornos de nuestros clientes, activamos protección y reglas de detección para esta falla y coordinamos la actualización con cada responsable. Esto es lo que hacemos por ti:
Ubicamos cada servidor con PHP y su versión
El inventario de software muestra qué corre en cada servidor monitoreado y en qué versión, sin depender de revisiones manuales.
Te decimos qué actualizar y cómo
El módulo de vulnerabilidades marca cada CVE con su gravedad, los servidores afectados, la versión a la que hay que actualizar y la instrucción exacta para hacerlo. Nosotros priorizamos y avisamos; tu equipo o tu proveedor aplica la actualización en la ventana que acordemos.
Te protegemos mientras actualizas, con parcheo virtual
El parcheo virtual bloquea los intentos de explotar la falla aunque el servidor todavía tenga la versión vulnerable de PHP:
- En el tráfico: reglas de prevención de intrusos que descartan las peticiones diseñadas para explotar PHP2Shell antes de que lleguen a PHP.
- En el servidor: protección que vigila los procesos de PHP mientras corren y frena el comportamiento anómalo de un ataque.
No requiere reiniciar y cubre también versiones antiguas de PHP que no pueden actualizarse de inmediato. Es temporal: la actualización sigue siendo la única solución completa.
Detectamos y contenemos cualquier intento
Vigilamos las señales de ataque las 24 horas. En incidentes críticos, el aviso y el inicio de la investigación llegan en menos de 30 minutos, y desde el plan Response nuestro equipo contiene la amenaza por ti: aísla el equipo o bloquea la actividad sospechosa.
Puedes probar TecnetSOC Response 30 días sin método de pago y revisar tu exposición a PHP2Shell con tus propios datos.
Preguntas frecuentes sobre PHP2Shell
Es el nombre con el que se conoce a las dos fallas. "Shell" es la consola desde la que se le dan órdenes a un servidor, así que el nombre resume el riesgo: pasar de una visita a PHP al control del servidor. Sigue la línea de nombres como Log4Shell, la falla de 2021 en una librería de Java, y técnicamente es una ejecución remota de código.
Si tu WordPress corre sobre una versión de PHP sin corregir, sí: WordPress funciona sobre PHP, igual que Drupal, Joomla o Magento. Actualizar WordPress o sus plugins no corrige la falla; lo que hay que actualizar es PHP en el servidor.
No directamente. La falla ocurre dentro del servidor web, en el momento en que PHP recibe la petición. Lo que ayuda mientras actualizas es la vigilancia del servidor y las reglas de un firewall de aplicaciones web; la corrección definitiva sigue siendo actualizar PHP.
Además de las señales del servidor, busca archivos nuevos en las carpetas del sitio, usuarios administradores que nadie creó y conexiones del servidor hacia direcciones desconocidas. Si encuentras algo, no borres ni reinstales antes de que un especialista lo revise: esa evidencia dice hasta dónde llegó el atacante.
Es su puntaje CVSS, la escala de 0 a 10 que usa la industria para medir la gravedad de una vulnerabilidad. De 9.0 en adelante se considera crítica: se puede explotar a distancia, sin credenciales, y el atacante podría leer, modificar o detener lo que corre en el servidor.
En un servidor que usa los paquetes de su distribución, unos minutos más el reinicio de los servicios. Lo que lleva más tiempo es comprobar que el sitio siga funcionando, sobre todo al pasar de una versión sin soporte, como la 7.4, a una 8.x: ahí conviene probar primero en una copia del sitio.
Experto en Microsoft Cloud y Ciberseguridad con más de una década de experiencia en la industria tecnológica. Es reconocido por su amplio conocimiento en la implementación de soluciones basadas en la nube y en la protección de datos y sistemas contra amenazas cibernéticas. Como líder y conferencista, Gustavo sigue compartiendo sus conocimientos y mejores prácticas en eventos tecnológicos y programas de capacitación. Su enfoque práctico y su dedicación a mantenerse actualizado en un entorno tecnológico en constante evolución lo convierten en un recurso invaluable para las empresas y profesionales que buscan aprovechar al máximo la tecnología de manera segura.
