PHP2Shell: vulnerabilidad crítica en PHP y qué hacer | Quantyx

PHP2Shell: la vulnerabilidad crítica de PHP que pone en riesgo a cerca del 70% de la web

El 21 de octubre de 2026, el equipo de PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas que permiten a un atacante ejecutar código en un servidor sin necesidad de iniciar sesión. Se conocen como PHP2Shell y están registradas como CVE-2026-109618 y CVE-2026-109619.

La reacción fue inmediata. Agencias de ciberseguridad de Europa, Estados Unidos, Canadá, Suiza, Nueva Zelanda y España pidieron actualizar de inmediato. En Bélgica y Países Bajos, gobiernos, hospitales, medios y plataformas educativas desconectaron sus sitios web de forma preventiva mientras esperaban o aplicaban el parche.

No es una vulnerabilidad de un plugin ni de un CMS en particular: está en el núcleo de PHP, el lenguaje que funciona detrás de WordPress, Drupal, Joomla, MediaWiki y una gran parte de los sitios corporativos, tiendas en línea e intranets del mundo, incluidos los de Chile y Latinoamérica.

En este artículo explicamos qué pasó, qué tan grave es, por qué la inteligencia artificial cambió las reglas del juego y qué deben hacer empresas, equipos técnicos y usuarios. Si necesitas apoyo para revisar tu sitio, escríbenos en contacto.

Resumen rápido

Qué es PHP y por qué importa tanto

PHP es un lenguaje de programación del lado del servidor: el código que se ejecuta cuando alguien visita una página, envía un formulario o compra en una tienda en línea. Según W3Techs, PHP es usado por el 69,3% de los sitios web cuyo lenguaje de servidor es conocido. Por eso se suele decir que “cerca del 70% de la web” funciona con PHP.

Algunas plataformas que funcionan con PHP:

• WordPress, el gestor de contenidos más usado del mundo, muy común en sitios de pymes, medios e instituciones en Chile.
• WooCommerce, PrestaShop y Magento, para comercio electrónico.
• Drupal y Joomla, frecuentes en sitios institucionales y universidades.
• MediaWiki, el software de Wikipedia.
• Moodle, muy usado en plataformas educativas.
• Miles de sistemas a medida: intranets, portales de clientes, sistemas de reservas, paneles de administración y APIs.

Además, muchos productos comerciales incluyen PHP “por dentro” sin que se note: paneles de hosting, appliances de red, firewalls, sistemas de monitoreo o software empresarial. Por eso las autoridades recomiendan revisar también ese tipo de productos.

Qué pasó: cronología

• Agosto de 2026. Investigadores de Calif y OpenAI reportan de forma independiente el problema al equipo de PHP (11 de agosto). Luego Wiz y OpenAI encuentran variantes. Los hallazgos se mantienen en reserva mientras se prepara el parche.
• 17 de octubre. Amazon detecta en sus sistemas trampa (honeypots) un intento de explotación cuatro días antes de la divulgación pública, desde una red de anonimización.
• 20 de octubre. PHP anuncia que publicará una actualización de seguridad crítica.
• 21 de octubre, madrugada. Comienzan a circular exploits de prueba (PoC) y aumentan los intentos de ataque.
• 21 de octubre. PHP publica las versiones corregidas. Europa, Estados Unidos y otros países emiten alertas. Varios sitios públicos y privados en Bélgica y Países Bajos se desconectan preventivamente.
• 21 de octubre, 14:59 (hora de Chile). El CSIRT Nacional publica la alerta AVC26-00740, clasificada como vulnerabilidad crítica, dirigida a prestadores de servicios esenciales y operadores de importancia vital.
• 22 de octubre. El NCSC de Nueva Zelanda informa que tiene conocimiento de reportes de explotación activa. Amazon señala que PHP2Shell está siendo explotada ampliamente.
• 23 de octubre de 2026: PHP publica un aviso informativo sobre una nueva falla, CVE-2026-115560, que las versiones del 21 de octubre no corrigen. Solo afecta a una configuración poco común y se mitiga con session.upload_progress.enabled=0. Sophos y Arctic Wolf reportan intentos de instalar una variante de la botnet Mirai usando PHP2Shell, aún sin ejecución de código confirmada.

Superficie de ataque: dónde puede entrar un atacante

La superficie de ataque es el conjunto de puntos por donde un sistema puede ser atacado. En PHP2Shell es enorme por tres razones.

1. Está en el núcleo, no en la aplicación

Los fallos están en la forma en que PHP maneja la memoria y los errores mientras procesa cada solicitud. Por eso no importa si tu sitio está bien programado: el problema está debajo de tu código.

2. Se activa antes de que tu código se ejecute

El equipo de PHP demostró un ataque en el que una sola solicitud, sin autenticación, activa la vulnerabilidad antes de que se ejecute cualquier código de la aplicación. No hace falta tener usuario ni contraseña.

3. No depende de que tu sitio tenga formularios de carga

Uno de los vectores aprovecha el procesamiento de solicitudes con archivos (multipart). Como explicó el hacker ético Inti De Ceukelaire a The Brussels Times, el problema aparece en cuanto el servidor examina lo que recibe, aunque el sitio no tenga una función de subir archivos.

Configuraciones afectadas

Gravedad: por qué se compara con Heartbleed y Log4Shell

Ambas vulnerabilidades tienen una puntuación CVSS de 9.2 sobre 10. Pero el puntaje no lo explica todo. Lo que la hace excepcional es la combinación de factores:

1. Ejecución remota de código sin autenticación. Un atacante puede tomar el control del servidor.
2. Lectura de memoria. Según Wiz y SecurityWeek, también permite leer memoria del proceso, que puede contener contraseñas, tokens de sesión, claves de API y certificados.
3. Alcance masivo. Afecta a casi todas las versiones de PHP desde 5.4 y a cerca del 70% de los sitios con lenguaje conocido.
4. Explotación rápida. Hubo intentos antes de la divulgación y exploits públicos en horas.
5. Dificultad para identificar todo lo afectado. PHP está incrustado en productos que no lo muestran.

Wiz afirma que estos hallazgos están entre los más graves descubiertos en PHP y compara PHP2Shell con Heartbleed (2014) y Log4Shell (2021), dos vulnerabilidades que marcaron la historia de la seguridad en internet.

Qué puede hacer un atacante con un sitio comprometido

• Robar bases de datos de clientes, usuarios y pedidos.
• Robar credenciales y claves de API de servicios conectados (pagos, correo, CRM, nube, IA).
• Instalar puertas traseras para volver más tarde.
• Modificar el sitio (defacement) o insertar redirecciones a sitios falsos.
• Usar el sitio para enviar phishing o distribuir malware aprovechando su reputación.
• Usar el servidor para atacar a otros sistemas de la empresa.
• Cifrar información y pedir rescate (ransomware).

Como dijo Shahak Shalev, de Malwarebytes, a SecurityWeek: los atacantes pueden secuestrar sitios reales para aprovechar su reputación, enviar phishing o distribuir malware “desde un canal confiable”.

Impacto en la web en general

• Desconexiones preventivas. En Bélgica se desconectaron sitios del gobierno flamenco, del Parlamento Flamenco, del Ministerio de Relaciones Exteriores, del Centro Belga de Ciberseguridad, de medios, de la plataforma escolar Smartschool y del hospital AZ Monica. En Países Bajos se retiraron temporalmente Overheid.nl, MijnOverheid.nl y DigiD. También hubo efectos en Finlandia.
• Sitios que no usan PHP también tomaron precauciones. De Ceukelaire desconectó sus sitios personales, algo que dice no haber hecho nunca.
• Proveedores de infraestructura como Cloudflare, Akamai, AWS, Fastly, Google, Microsoft, Vercel y Automattic trabajaron en mitigaciones y reglas de firewall para clientes que no podían actualizar de inmediato.
• WordPress recomendó revisar la versión de PHP y actualizar con el proveedor de hosting. Aclaró que no es un problema de WordPress y que no requiere actualizar WordPress.

Qué significa para Chile y Latinoamérica

Chile y la región llegan a esta crisis con un escenario de amenazas ya intenso:

• 324 reportes de incidentes recibió la Agencia Nacional de Ciberseguridad (ANCI) entre enero y junio de 2026, unos 54 ciberataques de efecto significativo al mes.
• En el primer trimestre de 2026, el CSIRT Nacional identificó “explotación de aplicaciones expuestas a internet” como una de las técnicas de acceso inicial más observadas, junto con cuentas válidas y phishing. Es exactamente el tipo de ataque que permite PHP2Shell.
• En ese mismo periodo, la ejecución no autorizada de código apareció en el 8,9% de los reportes, y el phishing o fraude desde infraestructura propia de la institución afectada en el 13,3%.
• Según el Think Ahead Report 2026 de SEK, América Latina registra 2.640 ataques semanales por organización, 35% sobre el promedio mundial, y la actividad maliciosa permaneció en promedio más de 185 días sin ser detectada en sus ejercicios regionales.
• El ESET Security Report 2026 indica que 52,7% de las empresas de la región detectó al menos un intento de ataque en el último año y que 15,4% ni siquiera puede saber si lo sufrió.

¿Por qué el riesgo puede ser mayor en la región?

1. Mucho WordPress y hosting compartido. Gran parte de los sitios de pymes, municipios, colegios, medios y comercios funciona en planes compartidos donde el cliente no controla la versión de PHP.
2. Versiones antiguas. Es común encontrar sitios en PHP 7.x o 8.0 y 8.1, que ya no reciben actualizaciones oficiales.
3. Sitios “abandonados”. Webs que se hicieron una vez y nadie mantiene: landings de campañas pasadas, micrositios, sistemas antiguos.
4. Poca visibilidad. Muchas organizaciones no tienen monitoreo ni inventario de lo que publican en internet.

El marco legal en Chile

La Ley Marco de Ciberseguridad (Ley 21.663) creó la ANCI y obliga a los prestadores de servicios esenciales y operadores de importancia vital a gestionar riesgos y reportar incidentes, con una alerta temprana dentro de las 3 horas siguientes a conocer un incidente significativo. Si tu organización está en esas categorías, PHP2Shell debe tratarse como prioridad de gestión de riesgo y no solo como un tema técnico.

La alerta del CSIRT Nacional

El 21 de octubre de 2026, el CSIRT Nacional de la ANCI publicó la alerta AVC26-00740: PHP – Vulnerabilidades Críticas, dirigida especialmente a prestadores de servicios esenciales y operadores de importancia vital. La alerta:

• Confirma que CVE-2026-109618 y CVE-2026-109619 (PHP2Shell) podrían permitir a un atacante remoto no autenticado ejecutar código arbitrario en servidores web afectados.
• Señala que afectan a PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y que ya se demostró la ejecución remota de código en mod_php antes de que se procese el código de la aplicación.
• Advierte que ya se publicaron pruebas de concepto (PoC), lo que aumenta el riesgo de explotación.
• Recomienda actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, y migrar o pedir parches al proveedor para las versiones 8.1 y anteriores.
• Si no es posible actualizar de inmediato, sugiere medidas temporales: desactivar session.upload_progress.enabled, limitar el tamaño de las solicitudes POST, la cantidad de parámetros y las cargas de archivos, evaluar memory_limit=-1, configurar fatal_error_backtraces=0 en PHP 8.5, y revisar los registros de servidores web, PHP y equipos de seguridad en busca de solicitudes sospechosas y errores anómalos de memoria.
• Recalca que la actualización es la única medida que protege por completo.

Aunque la alerta está dirigida a operadores de servicios esenciales, sus recomendaciones aplican a cualquier empresa u organización chilena con sitios o sistemas en PHP. Para reportar incidentes o hacer consultas, la ANCI dispone del número 1510 y el correo ayuda@anci.gob.cl.

Actualización: PHP advierte de otra falla (CVE-2026-115560)

El 23 de octubre, dos días después del parche de emergencia, PHP publicó un aviso informativo sobre una nueva forma en que un atacante podría ejecutar código en un servidor web. La falla, CVE-2026-115560, es distinta de PHP2Shell y no la corrigen las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35.

¿Quién está en riesgo?

Solo las aplicaciones que cumplen todas estas condiciones a la vez:

• definen session.serialize_handler como php_binary o php_serialize en su configuración;
• lo cambian a php mientras se ejecutan, con ini_set();
• hacen ese cambio antes de llamar a session_start();
• y mantienen activa la función de progreso de carga de sesiones (session upload progress), que viene activada por defecto.

Una aplicación que nunca cambia el serialize_handler mientras se ejecuta no está expuesta por esta vía. PHP considera este escenario poco probable.

¿Qué hacer?

Una sola línea de configuración: session.upload_progress.enabled=0, hasta que salga la próxima versión regular de PHP. Es la misma mitigación que ya se recomendaba para CVE-2026-109619, así que si la aplicaste el 21 de octubre y la mantuviste, no tienes que hacer nada más.

Lo que todavía no se sabe

PHP no ha informado qué versiones están afectadas, qué versión traerá la corrección ni la puntuación de gravedad, y tampoco si la falla comparte origen con CVE-2026-109619. Publicará un aviso completo con la próxima versión regular. No se han reportado ataques que la exploten.

Cómo van los ataques contra PHP2Shell

• Amazon registró un intento de explotación el 17 de octubre, cuatro días antes de la divulgación.
• Cloudflare informó que los intentos pasaron de decenas de miles en los 45 minutos posteriores al anuncio a millones en la madrugada del 22 de octubre.
• Según Sophos y Arctic Wolf, los atacantes han intentado instalar una variante de la botnet Mirai.
• Por ahora, Wordfence y otros reportan escaneos e intentos, pero ninguna ejecución de código confirmada, y los investigadores dicen que un exploit confiable está siendo más difícil de construir de lo esperado.

Que los ataques todavía no tengan éxito no es motivo para esperar: cada día sin actualizar le da más tiempo a los atacantes para perfeccionar sus herramientas.

La IA y los agentes como nuevo vector de ataque

PHP2Shell es probablemente la primera gran vulnerabilidad de la era de la IA. Y eso cambia cómo hay que pensar la seguridad.

La IA hizo explotable un fallo que llevaba años ahí

Según Calif, un problema de manejo de memoria en PHP se detectó en 2020 y se redescubrió en 2024, pero no se corrigió porque nadie había demostrado que fuera explotable. Wiz explica que demostrarlo requería una cadena de pasos “en el límite de lo que investigadores humanos podían lograr”, y que modelos de IA de frontera redujeron sustancialmente esa barrera, permitiendo desarrollar y adaptar exploits funcionales en horas.

En este caso, la IA se usó para encontrar y corregir el problema. Pero la misma capacidad está disponible para los atacantes.

El tiempo entre parche y ataque se está reduciendo a horas

Amazon lo resume así: el análisis asistido por IA abarata convertir un parche o un aviso de seguridad en un exploit funcional, por lo que más actores pueden atacar en horas o incluso minutos después de que se publican los detalles. Su recomendación: para vulnerabilidades críticas en sistemas expuestos a internet, medir los plazos de parcheo en horas, no en 7 o 30 días.

Los agentes de IA amplían la superficie de ataque

Muchas empresas están conectando agentes de IA a sus sitios, CRM, correo, bases de datos y servidores. Eso trae beneficios, como explicamos en agentes de IA para operaciones de marketing, pero también riesgos nuevos:

• Más secretos en juego. Un servidor comprometido puede exponer claves de API de servicios de IA, CRM o pagos guardadas en variables de entorno o en memoria. PHP2Shell permite justamente leer memoria del proceso.
• Permisos excesivos. Un agente con acceso amplio a sistemas internos puede convertirse en una puerta de entrada si sus credenciales se filtran.
• Instrucciones maliciosas (prompt injection). Si un atacante modifica un sitio, puede insertar texto pensado para engañar a agentes de IA que lean esa página.
• Código generado sin revisión. Los asistentes de programación pueden sugerir dependencias o versiones desactualizadas si nadie revisa.
• Automatización del ataque. Los atacantes también usan agentes para escanear internet, identificar versiones vulnerables y probar exploits a gran escala.

Buenas prácticas para el uso de agentes

• Dales a los agentes el mínimo permiso necesario.
• Usa claves de API separadas por servicio, con límites de gasto y rotación periódica.
• Registra lo que hace cada agente para poder rastrearlo.
• Exige aprobación humana para acciones sensibles (pagos, envíos masivos, cambios en producción).
• Revisa el código generado con IA antes de publicarlo.
• Después de un incidente como PHP2Shell, rota todas las claves que pudieran haber estado en un servidor afectado.

Por qué tener todo actualizado ya no es opcional

PHP2Shell deja una lección clara: la seguridad de tu sitio depende de toda la cadena, no solo de tu código.

Hábitos que reducen el riesgo

• Mantener un inventario de todos tus sitios, subdominios, landings y sistemas expuestos.
• Usar versiones de PHP con soporte oficial (hoy, 8.2 o superior).
• Tener un responsable claro de las actualizaciones, interno o externo.
• Hacer respaldos automáticos y probar que se pueden restaurar.
• Tener un firewall de aplicaciones web (WAF).
• Monitorear disponibilidad, cambios en archivos y actividad sospechosa.
• Eliminar sitios, plugins y cuentas que ya no se usan.
• Definir un plan de respuesta: quién decide desconectar, a quién se avisa, cómo se restaura.
• Revisar contratos con proveedores de hosting y desarrollo: ¿quién actualiza y en cuánto tiempo?

Qué deben hacer las empresas ahora

Si tienes hosting administrado o compartido

1. Contacta hoy a tu proveedor de hosting y pregunta si ya actualizó PHP a una versión corregida y si aplicó reglas de WAF.
2. Revisa tu versión de PHP. En WordPress: Herramientas → Salud del sitio → Información → Servidor. En cPanel: MultiPHP Manager.
3. Si estás en PHP 8.1 o anterior, pide migrar a una versión soportada.
4. Mantener o aplicar session.upload_progress.enabled=0 hasta que PHP publique la corrección de CVE-2026-115560, salvo que tu aplicación necesite mostrar el progreso de carga de archivos.
5. Revisar si alguna aplicación cambia session.serialize_handler con ini_set() durante su ejecución.
6. Haz un respaldo completo antes de cualquier cambio.
7. Revisa que el sitio funcione después de la actualización.

Si administras tus propios servidores

1. Actualiza de inmediato a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o al paquete corregido de tu distribución Linux.
2. Prioriza los sistemas expuestos a internet.
3. Reinicia todos los procesos de PHP después de actualizar.
4. Si no puedes actualizar, aísla o desconecta el sistema, como recomiendan CERT-EU, CISA y el NCSC del Reino Unido, y aplica las medidas temporales que indica la alerta AVC26-00740 del CSIRT Nacional.
5. Revisa productos que incluyan PHP internamente. El NCSC de Países Bajos mantiene un listado de software afectado.
6. Investiga desde el 17 de octubre, no desde la fecha de divulgación: busca procesos inesperados de PHP lanzando comandos, archivos nuevos, cuentas nuevas y conexiones salientes extrañas.
7. Rota credenciales y claves de API almacenadas en servidores que pudieron estar expuestos.

Mitigaciones temporales (no reemplazan el parche)

El equipo de PHP publicó medidas que reducen la exposición, pero no hacen segura la instalación. Entre ellas: ajustar memory_limit y post_max_size, desactivar session.upload_progress.enabled y reiniciar los procesos, y limitar el tamaño y la complejidad de las solicitudes en el servidor o proxy. Los detalles están en el aviso oficial de PHP y en el aviso de CERT-EU. Aplícalas solo con apoyo técnico y como medida transitoria.

Para usuarios: qué significa para ti y qué precauciones tomar

Si no administras sitios web, no necesitas actualizar PHP: eso le corresponde a cada empresa o institución. Pero sí puedes verte afectado de forma indirecta, porque un sitio comprometido puede filtrar tus datos o usarse para engañarte.

¿Qué tan grave es para una persona común?

• Si un sitio donde tienes cuenta es atacado, tus datos personales y tu contraseña podrían quedar expuestos.
• Un sitio legítimo comprometido puede mostrar avisos falsos, descargas maliciosas o redirecciones a páginas de phishing.
• Es probable que aumenten los correos y mensajes fraudulentos que se aprovechan de la noticia: “actualiza tu cuenta”, “tu sitio fue hackeado”, “descarga este parche”.

Que un sitio esté caído estos días no significa que haya sido hackeado: muchas organizaciones se desconectaron por precaución, y eso es una buena señal de responsabilidad.

Precauciones recomendadas

• No reutilices contraseñas. Usa una distinta para cada sitio, idealmente con un gestor de contraseñas.
• Activa la verificación en dos pasos en correo, banco, redes sociales y tiendas.
• Desconfía de descargas inesperadas, incluso desde sitios conocidos. Si un sitio de repente te pide instalar algo, ciérralo.
• No descargues “parches de PHP” ni herramientas de seguridad enviadas por correo o WhatsApp: los usuarios no necesitan instalar nada.
• Revisa la URL antes de ingresar datos y entra a tu banco o servicios escribiendo la dirección o desde la app oficial.
• Atento a correos de “restablece tu contraseña” que no solicitaste.
• Mantén actualizados tu navegador, sistema operativo y antivirus.
• Si un servicio informa una filtración, cambia tu contraseña de inmediato en ese y cualquier otro sitio donde la hayas usado.
• Ante fraudes o incidentes, puedes contactar al CSIRT Nacional al 1510 o en ayuda@anci.gob.cl.

Si tienes un sitio pequeño, un blog o una tienda

Aunque no seas técnico, eres responsable de tu sitio:

1. Escríbele hoy a tu proveedor de hosting o a quien te hizo el sitio.
2. Pregunta qué versión de PHP usas y si ya está actualizada.
3. Pide un respaldo reciente.
4. Si nadie mantiene tu sitio, considéralo una señal para resolverlo.

Errores frecuentes en esta crisis

1. Pensar que “mi sitio es pequeño y no le interesa a nadie”. Los ataques son automáticos y masivos.
2. Esperar a que el hosting lo haga solo sin confirmarlo.
3. Actualizar WordPress y creer que con eso basta. El problema está en PHP, no en WordPress.
4. Aplicar solo las mitigaciones temporales y olvidarse del parche.
5. No reiniciar los procesos después de actualizar.
6. Investigar solo desde el 21 de octubre, cuando hubo intentos desde el 17.
7. No rotar claves y contraseñas después de actualizar un servidor expuesto.
8. Olvidar sitios antiguos, landings de campañas pasadas o subdominios.
9. Descargar “parches” desde enlaces recibidos por correo.

Cómo te ayuda Quantyx

En Quantyx desarrollamos y mantenemos sitios y sistemas para empresas. Ante PHP2Shell podemos ayudarte a:

• Hacer un inventario de tus sitios, landings y subdominios expuestos.
• Revisar la versión de PHP y coordinar la actualización con tu proveedor de hosting.
• Migrar sitios en versiones sin soporte a una versión segura, probando que todo siga funcionando.
• Revisar plugins, temas y dependencias.
• Rotar claves de API y revisar los permisos de integraciones y agentes de IA.
• Definir un plan de mantenimiento y actualizaciones para que la próxima vez la respuesta tome horas y no semanas.

Conoce nuestro trabajo en desarrollo personalizado y en agentes, automatizaciones e integraciones.

Preguntas frecuentes

¿Qué es PHP2Shell?

Es el nombre de dos vulnerabilidades críticas en el núcleo de PHP (CVE-2026-109618 y CVE-2026-109619) que permiten ejecutar código en un servidor sin autenticación y leer información sensible de su memoria.

¿Mi sitio WordPress está afectado?

Si funciona con una versión de PHP anterior a las corregidas, sí está en riesgo. No necesitas actualizar WordPress por esto, pero sí PHP. Revísalo en Herramientas → Salud del sitio → Información → Servidor, o pregúntale a tu hosting.

¿Qué versiones de PHP son seguras?

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, o los paquetes corregidos que publiquen las distribuciones Linux. Las versiones 8.1 y anteriores ya no reciben actualizaciones oficiales.

¿Se está explotando ya?

Sí. Amazon detectó intentos desde el 17 de octubre, y tras la publicación del parche varias empresas y agencias reportaron explotación activa.

¿Hay una alerta oficial en Chile?

Sí. El CSIRT Nacional publicó el 21 de octubre de 2026 la alerta AVC26-00740, que califica a PHP2Shell como vulnerabilidad crítica y recomienda actualizar de inmediato.

¿Tengo que desconectar mi sitio?

Si no puedes actualizar pronto, especialmente si usas PHP 8.1 o anterior y administras tu propio servidor, las agencias de ciberseguridad recomiendan considerar desconectarlo o aislarlo hasta aplicar el parche.

¿Un firewall me protege?

Un WAF puede reducir el riesgo mientras actualizas, pero no reemplaza el parche.

¿Los sitios que no usan PHP están a salvo?

No están afectados directamente por esta vulnerabilidad, pero pueden tener componentes que incluyen PHP o depender de servicios que sí lo usan. Revisa tu infraestructura completa.

¿Qué tiene que ver la inteligencia artificial?

Modelos de IA ayudaron a demostrar que un fallo conocido desde hace años era explotable. La misma tecnología permite a los atacantes crear exploits más rápido, lo que reduce el tiempo que tienen las empresas para actualizar.

¿Como usuario, debo instalar algo?

No. Los usuarios no deben instalar ningún “parche de PHP”. Desconfía de mensajes que te pidan hacerlo. Lo que sí conviene es usar contraseñas únicas y verificación en dos pasos.

Ya actualicé PHP, ¿estoy completamente protegido?

De PHP2Shell sí. Pero el 23 de octubre PHP advirtió de otra falla, CVE-2026-115560, que esas versiones no corrigen. Solo afecta a una configuración poco común y se mitiga con session.upload_progress.enabled=0 hasta la próxima versión regular de PHP. Si ya aplicaste esa configuración el 21 de octubre, no tienes que hacer nada más.

Conclusión

• PHP2Shell es una de las vulnerabilidades más graves en la historia de PHP, con ejecución remota de código sin autenticación.
• Afecta a casi todas las versiones desde PHP 5.4 y a cerca del 70% de los sitios con lenguaje conocido.
• Ya hay explotación activa: actualiza hoy a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o aísla el sistema.
• Chile y Latinoamérica tienen un escenario de amenazas intenso y muchos sitios en versiones antiguas.
• La IA acelera el paso entre la publicación de un parche y el ataque: los tiempos de respuesta ahora se miden en horas.
• Mantener todo actualizado, con inventario, respaldos y un responsable claro, ya no es opcional.
• Los usuarios deben protegerse con contraseñas únicas, verificación en dos pasos y desconfianza ante descargas y mensajes inesperados.

Si quieres que revisemos tus sitios y te ayudemos a actualizarlos, cuéntanos tu caso y respondemos en menos de 24 horas hábiles.

Fuentes

• The Hacker News: PHP warns of another unpatched code execution flaw
• CSIRT Nacional: Alerta AVC26-00740, PHP – Vulnerabilidades Críticas
• PHP: anuncio oficial de seguridad
• CERT-EU: Security Advisory 2026-018
• WordPress: Critical PHP Security Release
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• ENISA: Joint statement on critical PHP vulnerabilities
• INCIBE-CERT: Múltiples vulnerabilidades en PHP
• Wiz: PHP2Shell
• AWS Security Blog: PHP2Shell exploitation prior to public disclosure
• SecurityWeek: PHP2Shell patches land as first exploitation attempts hit sensors
• Reuters: EU agency warns websites may need to be taken offline
• The Brussels Times: Major websites go offline
• W3Techs: Usage statistics of PHP
• CSIRT Nacional: Boletín de Investigación de Amenazas T1 2026
• ANCI: Panorama actual de amenazas, octubre 2026
• ESET Security Report 2026
• G5noticias: informe Think Ahead 2026 de SEK

Actualizado: 23 de octubre de 2026, con el aviso de PHP sobre CVE-2026-115560 y el estado de los ataques contra PHP2Shell. Esta es una situación en desarrollo; revisa los avisos oficiales de PHP y del CSIRT Nacional para obtener la información más reciente. Este artículo es informativo y no reemplaza una evaluación técnica de tus sistemas.