"No se puede estar tranquilo incluso si no se han confirmado daños": Sitios detenidos debido a vulnerabilidades de PHP, ¿qué está sucediendo ahora?

El sitio que siempre usas de repente no se abre. Pero, ¿cómo lo tomarías si la razón no fuera la destrucción por un ciberataque, sino una suspensión temporal para protegerse de un ataque?

Se ha revelado una vulnerabilidad crítica en PHP, el lenguaje de programación que sustenta sitios web y aplicaciones web, y en Alemania, instituciones gubernamentales han detenido preventivamente sus sitios.

Según un artículo de AFP publicado el 22 de octubre en BUSINESS-PANORAMA, la Oficina Federal de Seguridad de la Información de Alemania (BSI) explicó que no se habían confirmado casos de explotación de esta vulnerabilidad en ese momento. Sin embargo, no se descartó la posibilidad de que un ataque hubiera tenido éxito.

Lo importante al leer esta noticia es que"no se han confirmado daños" no es lo mismo que "se ha confirmado la seguridad".

El anuncio de BSI no es una "declaración de fin"

Según el artículo original, BSI advirtió sobre la vulnerabilidad de PHP el 21 de octubre por la tarde y anunció que se planeaba una actualización de seguridad para las 16:00 del mismo día.

La preocupación era que los ataques se expandieran después de que se hicieran públicos los detalles de la actualización. Si la corrección revela la ubicación del problema, los atacantes podrían analizar esa información y apuntar a sistemas no corregidos. El artículo también menciona preocupaciones sobre cómo el análisis podría ser facilitado por la IA.

El 22 de octubre, BSI explicó que la mayoría de los sitios de las agencias federales que se detuvieron preventivamente habían sido restaurados. Sugirieron que la falta de informes de sistemas comprometidos podría deberse a que muchos operadores siguieron las recomendaciones y completaron las actualizaciones.

Sin embargo, esta es una evaluación basada en la información disponible. No garantiza que se haya completado la investigación de todos los sitios y que no haya habido intrusiones.

La restauración de los sitios es una buena noticia para los usuarios, pero es prematuro concluir que todo el problema se ha resuelto solo por eso.

El problema radica en la "base" de los sitios web

En esta ocasión, PHP corrigió dos vulnerabilidades críticas conocidas como "PHP2Shell". Los números de identificación son CVE-2026-109618 y CVE-2026-109619. Ambas tienen una calificación de 9.2 en el CVSS v4.0, clasificadas como "Críticas".

El 21 de octubre, la Fundación PHP anunció que habían corregido un problema que permitía a un atacante no autenticado ejecutar código en un servidor que ejecuta PHP, bajo ciertas condiciones.

Para los usuarios comunes, PHP es algo que normalmente no notan. No es el diseño de la pantalla ni el artículo en sí, sino lo que maneja el procesamiento detrás de escena.

Por lo tanto, al considerar la respuesta a esta situación, no es suficiente enfocarse solo en la apariencia del sitio o el panel de administración. Es necesario verificar el estado de las correcciones en la base que ejecuta la aplicación.

Las versiones corregidas publicadas por la Fundación PHP son PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12. Los operadores deben verificar el estado de aplicación de las correcciones, incluidas las instrucciones de los proveedores que ofrecen su entorno.

No confundir "intento de ataque" con "éxito de intrusión"

Junto con el artículo original sobre BSI, es importante tener en cuenta el informe de observación de AWS.

AWS anunció que su sistema "MadPot", diseñado para observar ataques, había detectado intentos de explotación de PHP2Shell que datan del 17 de octubre, antes de que se publicaran los detalles de la vulnerabilidad.

Por otro lado, AWS indicó que no está claro si los intentos observados tuvieron éxito en sistemas reales.

En otras palabras, el informe de BSI de que "no se han confirmado casos de explotación" y el informe de AWS de que "se han observado intentos de ataque" son diferentes en cuanto a su enfoque y contenido de confirmación. No se puede concluir que "no hubo ataques" o que "se confirmó un daño de intrusión a gran escala" tomando solo uno de ellos.

Tanto los usuarios como los operadores deben leer por separado la existencia de la vulnerabilidad, la observación de ataques, el éxito de la intrusión y la confirmación de la fuga de información.

En redes sociales, también hay voces que valoran la rápida corrección

En las redes sociales y comunidades en línea, no solo hay un sentido de crisis, sino también opiniones sobre cómo se perciben las noticias.

En el hilo "Has PHP2Shell borne fruit?" en la comunidad de PHP en Reddit, se pueden encontrar opiniones que valoran la rapidez de la corrección y la respuesta de las principales distribuciones de Linux, a pesar de los artículos que generan miedo y las críticas a PHP.

Esto refleja una percepción que desea que se observe no solo la gravedad de la vulnerabilidad, sino también la respuesta de los desarrolladores y distribuidores. Sin embargo, la evaluación del daño por parte del autor de la publicación no indica la seguridad global.

Por otro lado, en una publicación de Reddit sobre el servicio de alias de correo addy.io, se compartió que el sistema web se detuvo temporalmente como respuesta a PHP2Shell. Se explicó que la entrega de correos continuaría y luego se publicó un aviso de que se aplicaron las correcciones y se restauró el servicio.

No basta con decir simplemente "el servicio no está disponible", sino que es importante comunicar qué se detuvo, qué está disponible y cuándo se restauró. Este tipo de intercambio de información puede ser útil para reducir la ansiedad de los usuarios.

Cabe señalar que lo mencionado aquí son publicaciones individuales confirmadas y no representan la opinión mayoritaria o una encuesta de opinión en las redes sociales en general.

Incluso la decisión de detener un sitio requiere explicación

Una suspensión preventiva causa inconvenientes a los usuarios. Si no pueden hacer consultas, avanzar en trámites o comprar productos, también se genera una carga para los operadores.

Aun así, restringir el acceso externo hasta que se completen las correcciones tiene el propósito de reducir la exposición a ataques. CERT-EU también aconseja considerar aislar aplicaciones publicadas en Internet de redes públicas si no se pueden corregir de inmediato.

Por eso, es difícil juzgar la calidad de la operación solo por si se detuvo o no.

Lo que realmente importa es si se explicó la razón de la detención, si se aclararon las funciones afectadas y dónde se puede verificar el próximo aviso.

Un sitio que desaparece sin explicación y uno que comunica medidas para proteger a los usuarios serán percibidos de manera diferente, incluso si ambos están detenidos.

Para los operadores japoneses, tampoco es "noticia extranjera"

El problema de PHP no es solo relevante para sitios en alemán. Si el entorno utiliza la misma tecnología, los operadores japoneses también deben verificarlo.

En ese caso, el primer desafío podría ser aclarar quién gestiona el sitio de la empresa, más que cambiar configuraciones técnicas.

¿Está a cargo una empresa de producción? ¿La empresa de servidores alquilados actualiza la base? ¿O debe responder un responsable interno de la empresa?

Los puntos a verificar se pueden organizar de la siguiente manera:

• ¿Se está utilizando PHP en el entorno operativo del sitio?
• ¿Se han aplicado las correcciones para la vulnerabilidad actual?
• ¿Se ha determinado quién es el responsable de las actualizaciones y cómo se confirmará la finalización de la respuesta?
• Si no se puede corregir de inmediato, ¿quién tomará la decisión de restringir la publicación?

Hay una gran diferencia entre "se supone que el contratista está respondiendo" y "se ha confirmado la respuesta".

Además, CERT-EU indica que para las series de PHP 8.1 y anteriores, cuyo soporte ha finalizado, el proyecto PHP no proporcionará actualizaciones. Si se continúa utilizando un entorno antiguo, se debe verificar si el proveedor de ese entorno ha realizado correcciones y si es necesario migrar.

Tener medidas defensivas no siempre sustituye a las actualizaciones

Puede haber momentos en los que uno quiera pensar que está bien porque se han implementado mecanismos para prevenir ataques.

Sin embargo, AWS ha aclarado que, en este caso, las medidas con WAF son un complemento para reducir el alcance de la exposición al peligro y no sustituyen la actualización de PHP.

Lo importante es no solo el hecho de que se está utilizando algún producto de defensa, sino hasta qué punto esa medida cubre el problema actual.

El artículo original también menciona que BSI instó a los usuarios generales a no permitir el acceso a sus routers desde fuera de casa y a tener cuidado con las descargas y el suministro de información confidencial.

Esto no significa que todos los dispositivos o routers de los usuarios estén directamente afectados por esta vulnerabilidad. Las respuestas de los operadores y la precaución diaria de los usuarios deben considerarse por separado.

Hay trabajo detrás de "no pasó nada"

Después de una gran advertencia, si no se informa de daños visibles, algunas personas podrían pensar "quizás fue una exageración".

Sin embargo, la razón por la que no se ven daños podría ser que las actualizaciones tempranas o las detenciones preventivas funcionaron, o que aún no se ha identificado. No se puede decidir cuál es el caso solo con la información actual.

La vulnerabilidad de PHP en esta ocasión muestra que no solo es responsabilidad de los operadores mantener los sitios en funcionamiento. Detenerlos cuando es necesario, corregirlos, verificar el estado y explicar a los usuarios también son trabajos que sostienen el servicio.

El aviso de "no se han confirmado daños" no es una razón para dejar de responder. Solo después de verificar cómo está su entorno, la lectura de las noticias se traduce en preparación real.

Fuentes

1. BUSINESS-PANORAMA/AFP (22 de octubre de 2026)
   BSI no ha confirmado casos de explotación, no ha descartado la posibilidad de intrusión, el estado de restauración de los sitios gubernamentales, y la base de la advertencia a los usuarios generales.
   https://business-panorama.de/news.php?newsid=6715602

2. Fundación PHP "Today's PHP Security Release, and How We're Strengthening PHP Security"
   Publicación de la versión corregida el 21 de octubre y explicación oficial sobre los peligros que plantea la vulnerabilidad.
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/thephp.foundation

3. CERT-EU "Vulnerabilidades críticas en PHP"
   Números CVE, gravedad, entornos afectados, series con soporte finalizado, consejos oficiales sobre correcciones y aislamiento.
   https://www.cert.europa.eu/publications/security-advisories/2026-018Vulnerabilidades críticas en PHP

4. Blog de Seguridad de AWS: Informe de observación de PHP2Shell por MadPot
   Intentos de ataque antes de la divulgación pública y explicación de que no se sabe si tuvieron éxito en entornos reales. Base para distinguir entre "observación de ataques" y "confirmación de daños".
   https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/aws.amazon.com

5. Blog de Seguridad de AWS: Medidas de mitigación de WAF para PHP2Shell
   Posición de WAF y explicación oficial de que es necesario actualizar PHP.
   https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-cve-2026-109618-and-cve-2026-109619/aws.amazon.com

6. Reddit・r/PHP "Has PHP2Shell borne fruit?"
   Dudas sobre los informes y reacciones individuales que valoran la rápida corrección. La evaluación de daños en la publicación no se adopta como un hecho confirmado.
   https://www.reddit.com/r/PHP/comments/1xchgrv/has_php2shell_borne_fruit/reddit.com

7. Reddit・r/addy_io "Actualización del servicio 🚨Vulnerabilidad PHP2Shell"
   Ejemplo de compartir información sobre la suspensión preventiva del sistema web, la continuación de la entrega de correos y la restauración después de la corrección.
   https://www.reddit.com/r/addy_io/comments/1xbkaeb/service_update_php2shell_vulnerability/