🛡 VULNERABILIDADES 🛡

¿Expuesto a PHP2Shell? Expertos en ciberseguridad ofrecen consejos.

⏰24 de octubre de 2026🛡CyberObservatorio

Idioma

◢ VULNERABILIDADES ◣

¿Expuesto a PHP2Shell? Expertos en ciberseguridad ofrecen consejos.

⟫ 23/10/2026 ⟫ Nate Nelson

Fuente: Dark Reading

Nuevos datos revelan que las organizaciones no están avanzando en la implementación de parches para PHP2Shell tan rápido como los atacantes están explotando esta vulnerabilidad. Esta situación resulta comprensible, según los expertos en ciberseguridad, dado que la actualización en este caso es especialmente compleja.

La información comenzó a fluir el 21 de octubre, ofreciendo un panorama sobre la respuesta inicial del mundo a las nuevas vulnerabilidades de PHP. La imagen que se dibujó no fue alentadora. Algunos expertos bien situados detectaron un volumen notable de actividad maliciosa. Matthew Prince, CEO de Cloudflare, informó que en las diez horas previas a que las vulnerabilidades se hicieran públicas el miércoles, su empresa observó miles de intentos de explotación. "Eso saltó a decenas de miles en los 45 minutos posteriores al anuncio, cientos de miles en 2 horas y millones ahora", escribió en X, a finales del 21 de octubre.

Al día siguiente, Check Point Research afirmó que los intentos de explotación ya habían alcanzado el 10% de las organizaciones a nivel mundial. En contraste, solo un pequeño porcentaje de las organizaciones vulnerables había comenzado a actualizar visiblemente a las nuevas versiones de PHP. Utilizando despliegues accesibles a través de Shodan como muestra, los investigadores de Ox Security encontraron que más del 99% de los casos no estaban anunciando una versión recién corregida 24 horas después de que las versiones parcheadas estuvieran disponibles. Además, los investigadores de Flare señalaron que el 73% de esas instancias publicitaban ramas de PHP que ya no reciben actualizaciones de la Fundación PHP. Cabe destacar que estos datos deben ser calificados, ya que el escaneo básico de Internet puede omitir algunas sutilezas cruciales.

Mientras tanto, Cisco Talos estimó, basándose en inteligencia de fuentes abiertas (OSINT), que aproximadamente la mitad de todos los sistemas PHP no recibirán parches. En la mañana del 23 de octubre, hora del este de EE. UU., Ox informó a Dark Reading que su cifra del 99% había disminuido al 97.5%. Flare, por su parte, comunicó a Dark Reading que del 27% de los registros públicos que reflejan ramas soportadas, aproximadamente el 5% había sido actualizado.

Abordar PHP2Shell no es tan sencillo como hacer clic en "Actualizar", reconocen los profesionales del sector. Sin embargo, existen pasos que la mayoría de las organizaciones pueden adoptar para protegerse de inmediato, como buscar diligentemente implementaciones de PHP a lo largo de toda su flota de sistemas, rastrear signos de compromiso y restringir el acceso o desconectar aquellos sistemas que no puedan ser parcheados de inmediato.

En teoría, protegerse contra PHP2Shell debería ser un proceso sencillo. Existen nuevas versiones a las que se puede actualizar, que abordan las vulnerabilidades en cuestión, específicamente CVE-2026-109618 y CVE-2026-109619. En la práctica, sin embargo, la forma de abordar PHP2Shell variará significativamente de una organización a otra, exigiendo más o menos esfuerzo dependiendo de cómo, dónde y de qué maneras utilizan PHP.

El primer paso unánime al que apuntan todos los expertos en ciberseguridad es que las organizaciones deben descubrir e inventariar todos los activos que tengan ejecutando PHP. No obstante, esto es más fácil decirlo que hacerlo. Como señaló la Agencia de Ciberseguridad y Seguridad de Infraestructura (CISA) en una alerta de seguridad del 21 de octubre, PHP no solo es algo que se utiliza para ejecutar sitios web, sino que "a menudo es un componente de otro software y su prevalencia puede no ser directamente observable".

Los investigadores de Flare observaron esta realidad de primera mano al examinar la superficie de ataque. "Lo que más me llamó la atención durante la investigación fue la cantidad de PHP que encontramos fuera del alojamiento web convencional", comenta Adrian Cheek, investigador senior en cibercriminalidad en Flare. "Lo identificamos en dispositivos de almacenamiento, sistemas de control de acceso físico, cámaras e interfaces de acceso remoto. Si solo te enfocas en tus sitios web principales o limitas una evaluación externa a los puertos 80 y 443, te perderás parte de eso".

Para las organizaciones con este tipo de exposición, continúa Cheek, "generalmente no puedes iniciar sesión en un dispositivo de almacenamiento o en una unidad de control de acceso físico y actualizar independientemente su instalación de PHP. Necesitas que el fabricante proporcione un firmware actualizado. Si el fabricante ha dejado de soportar ese producto, la organización puede no tener un parche disponible".

Dejando de lado los casos extremos, supongamos que una organización ha logrado encontrar y listar todas sus implementaciones de PHP. A partir de ahí, notablemente, las cosas solo se complican. Los datos disponibles públicamente sugieren que la mayoría de los PHP en el mundo está ejecutándose en ramas antiguas. "Si estás utilizando una aplicación construida sobre PHP 5 o PHP 7, migrar a una versión actual de PHP podría significar reescribir partes de la aplicación, reemplazar dependencias y probar todo lo que podría fallar. Hay una buena razón por la cual las organizaciones evitan hacer eso de manera casual, especialmente cuando la aplicación soporta algo operativamente importante", explica Cheek.

En estos casos, la remediación será un proceso lento, si es que las organizaciones deciden llevarlo a cabo. Afortunadamente, y de manera confusa, las versiones antiguas de PHP no siempre son insalvables. La versión más común en los registros públicos, la 7.4.3, corresponde a lo que se incluía con Ubuntu 20.04. Como señala Cheek, "las distribuciones de Linux frecuentemente mantienen un número de versión de PHP más antiguo mientras retroceden parches de seguridad. Así que un número de versión antiguo no significa automáticamente que el software no haya sido parcheado". Además de los sistemas operativos, las aplicaciones también pueden retroceder parches para el PHP con el que vienen empaquetadas.

Así, las organizaciones que ejecutan PHP desactualizado realmente caen en categorías muy distintas: algunas organizaciones necesitarán realizar el trabajo pesado necesario para migrar o reemplazar sus aplicaciones o productos. Mientras tanto, los expertos sugieren que consideren desconectar completamente sus sistemas vulnerables. Cheek ofrece también un consejo práctico para mitigar la vulnerabilidad CVE-2026-109619, para aquellos que pueden acceder a la configuración de PHP.

"Los ataques reportados pasan por el progreso de carga de sesiones PHP, una característica que está habilitada por defecto y que no necesita una llamada a session_start en la aplicación. Deshabilitar session.upload_progress.enabled y reiniciar los trabajadores de PHP bloquea las rutas de ataque confirmadas de progreso de carga de sesiones sin necesidad de actualizar la versión de PHP", explica, con la salvedad de que esto no aborda la otra falla de PHP2Shell, CVE-2026-109618, por lo que se considera una medida temporal en el mejor de los casos.

Algunas organizaciones contarán con la ventaja de poder instalar correcciones retroactivas a través de sus proveedores. El 21 de octubre, Canonical, el desarrollador de Ubuntu, publicó parches para PHP2Shell aplicables a todas las versiones desde la 14.04. Sin embargo, incluso estas entidades beneficiadas deberán realizar un esfuerzo adicional en la contabilidad de sus sistemas, ya que una actualización del sistema operativo o de una aplicación no implica necesariamente una actualización completa de la versión de PHP. Así, si se aprovechan de las actualizaciones de Ubuntu, futuros escaneos podrían seguir mostrando que el sistema aparentemente opera con PHP 7.4.3, lo que podría llevar a una falsa sensación de seguridad.

Es crucial recordar que, como apunta Cheek, "el reinicio es fundamental. Instalar un paquete de PHP corregido no sustituye necesariamente al intérprete que ya está cargado en los procesos de trabajo en ejecución". Este detalle técnico subraya la importancia de una gestión adecuada de las actualizaciones, especialmente en un contexto donde las vulnerabilidades como PHP2Shell pueden tener un impacto devastador si no se manejan correctamente.

Además de todos estos aspectos técnicos, el tamaño de la organización influye considerablemente en cómo se pueden abordar las vulnerabilidades relacionadas con PHP2Shell. En el caso de las pequeñas empresas, a menudo comienzan con desventajas en términos de conciencia y recursos necesarios para llevar a cabo la limpieza necesaria. No obstante, tras 48 horas de trabajo ininterrumpido para ayudar a más de 1.000 organizaciones afectadas por PHP2Shell, Neatsun Ziv, CEO de OX Security, destaca las ventajas que pueden tener las organizaciones más pequeñas. "En las organizaciones pequeñas, puedes hacer lo que quieras. Simplemente entras y aplicas el parche. Esperas cinco horas. Nadie se queja de que se rompa algo", comenta Ziv.

Sin embargo, las organizaciones más grandes presentan un panorama completamente diferente. Según Ziv, "tienen una imagen dorada: una base de servidor que actualizan". Este enfoque sigue un modelo descendente: se despliega una nueva imagen dorada, que se construye con nuevo software, y este nuevo software va a producción, donde no se puede realizar ningún cambio. "Esta es la norma en los despliegues actuales. Nadie va a los servidores y realmente los parchea. Con el tiempo, esto se vuelve insostenible", añade.

Además, hay que considerar cuántas personas de distintos equipos deben estar involucradas en las actualizaciones importantes dentro de una gran organización. También es importante mencionar que las organizaciones grandes operan sistemas desproporcionadamente significativos que no pueden permitirse fallar. Ziv destaca que "la mayoría de las organizaciones con las que trabajamos encontraron cientos de servidores que están ejecutando PHP", lo que pone de manifiesto la extensión de la vulnerabilidad.

Por otro lado, Alex Spokoiny, director de seguridad y confianza de Check Point, enfatiza que, más allá de los problemas internos, las organizaciones también enfrentan riesgos derivados de cómo sus proveedores manejan PHP2Shell. "El primer paso es involucrar a los proveedores relevantes y entender cómo están respondiendo. ¿Se ven afectados? ¿Qué protecciones han implementado? ¿Cuándo esperan completar la remediación? Si no puedes obtener respuestas claras o razonables a estas preguntas, eso es algo que debes considerar en tu evaluación de riesgos y potencialmente explorar opciones alternativas", recomienda.

Además, las organizaciones pueden colaborar entre sí, beneficiándose mutuamente. "Por ejemplo, donde sea técnicamente posible, pueden extender la protección de su propio cortafuegos de aplicaciones web (WAF) a las aplicaciones operadas por terceros, ayudando a reducir la exposición mientras el proveedor trabaja hacia una solución permanente", concluye Spokoiny. Esta colaboración puede ser clave para mitigar riesgos en un entorno donde la ciberseguridad es cada vez más crítica.

◢ VULNERABILIDADES ◣

Exposed to PHP2Shell? Cyber Experts Weigh in With Advice

⟫ 23/10/2026 ⟫ Nate Nelson

Source: Dark Reading

New data shows that organizations aren't moving to patchPHP2Shellas fast as attackers are moving to exploit it. It's understandable, cybersecurity experts say, because updating in this case is especially complicated. The data began trickling in on Oct. 21, painting a picture of the world's initial response to the newPHP vulnerabilities. The picture wasn't pretty. Some well-positioned experts picked up on a remarkable volume of threat activity. Cloudflare CEO Matthew Prince stated that in the 10 hours before the vulnerabilities were publicly disclosed on Wednesday, his company observed thousands of exploitation attempts. "That jumped to tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now," hewroteon X, late on Oct. 21. The next day, Check Point Research claimed that attempts at exploitation had already reached10%of organizations worldwide. On the flip side, only a small percentage of vulnerable organizations have been visibly updating to new PHP releases. Using discoverable deployments on Shodan as a sample, Ox Security researchers found that more than99%of instances were not yet advertising a newly patched version 24 hours after fixed versions were made available. Researchers at Flare piled on, noting that73%of those instances advertised PHP branches that no longer receive updates from the PHP Foundation. (It also qualified these figures, noting that basic Internet scanning misses some crucial nuances.) Meanwhile, Cisco Talos estimated, based on open source intelligence (OSINT), that aroundhalf of all PHP systemswon't receive patches. On the morning of Oct. 23, Eastern time, Ox informed Dark Reading that its 99% figure had dropped to 97.5%. And Flare told Dark Reading that of the 27% of public records reflecting upstream-supported branches, about 5% have been updated. Addressing PHP2Shell is often not as simple as clicking "Update," practitioners acknowledge. Still, there are steps that most organizations can take to protect themselves immediately, like diligently looking for PHP deployments across an organization's entire fleet of systems, hunting for signs of compromise, and restricting access to or otherwise taking offline any systems that can't be patched immediately. In principle, protecting against PHP2Shell should be simple. There are new versions one can update to, which cover the vulnerabilities in question, CVE-2026-109618 and CVE-2026-109619. In practice, addressing PHP2Shell will look very different from one organization to the next, and require more or less effort, depending on how, where, and in what ways they use PHP. The unanimous first step all cybersecurity experts point to is that organizations shoulddiscover and inventoryall of the assets they have running PHP. It's easier said than done. As the Cybersecurity and Infrastructure Security Agency (CISA) noted inan Oct. 21 security alert, PHP isn't just something that runs websites, it's "often a component of other software and prevalence may not be directly observable." Flare researchers saw that firsthand when examing the attack surface. "What stood out to me during the research was how much PHP we found outside conventional web hosting," says Adrian Cheek, senior cybercrime researcher at Flare. "We identified it in storage devices, physical access-control systems, cameras and remote-access interfaces. If you're only looking at your main websites or limiting an external assessment to ports 80 and 443, you're going to miss some of that." For organizations with this sort of exposure, he continues, "You generally can't log into a storage appliance or physical access-control unit and independently upgrade its PHP installation. You need the manufacturer to provide updated firmware. If the manufacturer has stopped supporting that product, the organization may have no patch available." Putting edge cases aside, let's assume that an organization has managed to find and list out all of its PHP deployments. From there, remarkably, things only get more complicated. Publicly available data seems to suggest that most PHP out in the world is running on old branches. "If you’re running an application built around PHP 5 or PHP 7, moving to a current PHP release could mean rewriting parts of the application, replacing dependencies, and testing everything that might break. There’s a good reason why organizations avoid doing that casually, particularly when the application supports something operationally important," Cheek explains. In these cases, remediation will be a slow process, if organizations choose to pursue it at all. Luckily, and confusingly, old PHP versions aren't always unsavable. The most common version in public records, 7.4.3, is what shipped with Ubuntu 20.04. As Cheek points out, "Linux distributionsfrequently retain an older PHP version number while backporting security fixes. So an old version number doesn't automatically mean the software hasn't been patched." Besides operating systems, applications can also backport fixes for the PHP they come packaged with. Thus, organizations running outdated PHP actually fall into very distinct buckets: Some organizations will need to do the heavy lifting necessary to migrate or replace their applications or products. In the meantime, experts say, they should consider taking their vulnerable systems offline entirely. Cheek also offers one pro tip to mitigate CVE-2026-109619, for those that can reach the PHP configuration. "The reported attacks run through PHP session upload progress, a feature that is on by default and needs no session_start call in the application. Disabling session.upload_progress.enabled and restarting the PHP workers blocks the confirmed session-upload-progress attack paths without requiring a PHP version upgrade," he explains, with the qualification that it doesn't address the other PHP2Shell flaw, CVE-2026-109618, so it's a temporary measure at best. Some organizations will be privileged enough to install backported fixes through their vendors. On Oct. 21, Ubuntu developer Canonical publishedfixesfor PHP2Shell for all versions since 14.04. Even these relieved parties will have more accounting work to do, since an OS or application update doesn't necessarily carry a full PHP version upgrade. If one takes advantage of Ubuntu's updates, future scans could continue to show it ostensibly running PHP 7.4.3. And don't forget, Cheek says: "The restart matters. Installing a corrected PHP package doesn't necessarily replace the interpreter already loaded into running worker processes." Besides all of the technical details, size will determine a lot about how organizations can respond to PHP2Shell. As with anyurgent cybersecurity vulnerability, small businesses may start off with disadvantages in awareness as well as the resources needed to get themselves cleaned up. Yet after 48 hours of working nonstop to help more than 1,000 organizations with PHP2Shell, OX Security CEO Neatsun Ziv is quicker to point out the advantages in being small. " At small organizations, you can do whatever you want. You just go in and patch. You wait five hours. Nobody complains about breaking anything," he says. But larger organizations are different, he says. "They've got a golden image — one server baseline they update," Ziv says. "It's always a downstream model: you deploy a new golden image, this golden image is then being built with new software, this new software goes to production, and nobody can change production. This is the norm in deployments today. Nobody goes to servers and actually patches them. It just becomes unmaintainable in the long term." And that's to say nothing of just how many people from different teams need to be involved in major updates within a large organization; or of how major organizations run disproportionately significant systems that can't afford to break; or of how prevalent and varied PHP can be even within organizations. As Ziv notes, "Most of the organizations that we work with found hundreds of servers that are running PHP." Check Point chief security and trust officer Alex Spokoiny adds that even beyond one's own house, organizations also face risk from how all of their suppliers handle PHP2Shell. "The first step is to engage the relevant suppliers and understand how they are responding. Are they affected? What protections have they put in place? When do they expect remediation to be completed? If you cannot get clear or reasonable answers to those questions, that is itself something you need to factor into your risk assessment and potentially consider alternative options," he advises. Organizations can also team up, to everyone's benefit. "For example, where technically possible, they may be able to extend their own Web application firewall (WAF) protection to applications operated by third parties, helping reduce exposure while the provider works toward a permanent fix," Spokoiny says.

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD