Saltar a contenido
Verifica Explicadores
El logotipo PHP (preprocesador de hipertexto) en la pantalla de un teléfono inteligente y un código de computadora. · Foto: Kirill Kudryavstsev, AFP

El logotipo PHP (preprocesador de hipertexto) en la pantalla de un teléfono inteligente y un código de computadora.

Foto: Kirill Kudryavstsev, AFP

PHP y las vulnerabilidades que encendieron las alarmas de empresas y estados: qué se sabe y qué riesgos persisten

Dos fallas críticas en el lenguaje de programación más utilizado en el mundo llevaron a organismos públicos y empresas de distintos países a desconectar temporalmente sus portales.

La interrupción de varios sitios web de organismos públicos uruguayos durante la semana pasada respondió a una alerta internacional por dos vulnerabilidades críticas en PHP, un lenguaje de programación utilizado para desarrollar páginas y aplicaciones web. La decisión de desconectar temporalmente algunos servicios buscó reducir el riesgo de ataques mientras se instalaban las actualizaciones de seguridad.

Sin embargo, la caída de los portales no significa que hayan sido hackeados, como especularon los internautas en redes durante las primeras horas de la suspensión. Para comprender lo ocurrido es necesario distinguir entre la existencia de una vulnerabilidad, la posibilidad de que un sistema sea atacado y la confirmación de que alguien haya aprovechado efectivamente esa falla.

PHP es un lenguaje de programación que permite a los servidores generar contenido dinámico y procesar las solicitudes de los usuarios. Se encuentra en la base de numerosos sitios web y sistemas de gestión de contenidos, entre ellos WordPress y Drupal, y está presente en aproximadamente el 70% de los sitios web del mundo. De hecho, su uso es tan extendido que es utilizado por la propia Casa Blanca.

Enrique Amestoy, especialista en tecnologías de la información y ciberseguridad, señaló a la diaria Verifica que una de las claves para entender la dimensión del episodio es que el problema no estaba necesariamente en el diseño de las páginas ni en las herramientas utilizadas para administrarlas, sino en el lenguaje con el que funcionan.

“El problema no fueron los gestores de contenido, sino el lenguaje de programación con el que está hecho”, explicó. Una vulnerabilidad en una aplicación es una “puerta de entrada”, puede afectar a esa herramienta o a los sitios que la utilizan, mientras que una falla en un componente de base puede comprometer a una variedad mucho mayor de sistemas.

El 20 de octubre, el equipo de desarrollo de PHP anunció que publicaría actualizaciones de seguridad para corregir dos vulnerabilidades críticas. Los parches, los códigos que reparan, estuvieron disponibles el 21 de octubre para las versiones 8.2, 8.3, 8.4 y 8.5 mediante las actualizaciones 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Estos parches son fragmentos de código que reparan la vulnerabilidad y “cierran” la puerta a intrusiones no deseadas.

Las dos fallas recibieron una puntuación de 9,2 sobre 10 en la escala CVSS, utilizada internacionalmente para evaluar la gravedad de las vulnerabilidades, que la define como “crítica” y “fácil de aprovechar”.

Según las advertencias del equipo de PHP y de organismos internacionales de ciberseguridad, como el CERT de la Unión Europea, las vulnerabilidades podían permitir la ejecución remota de código sin que el atacante necesitara autenticarse. En determinadas condiciones, esto significa que alguien podría enviar una solicitud especialmente diseñada a un servidor vulnerable y conseguir ejecutar instrucciones en él.

“Lo que podría eventualmente implicar es que atacantes pudieran meterse al servidor y, dependiendo de qué tan seguro esté configurado, podrían acceder a información, como una base de datos de usuarios y contraseñas”, advirtió Amestoy. El alcance de una eventual intrusión dependería de los permisos del proceso afectado, de la configuración del servidor y de las medidas de seguridad adicionales.

Por su parte, el asesor en seguridad de la información Mauricio Papaleo utilizó una comparación para explicar la relación entre el lenguaje y los sitios web: “Si fuera una casa, PHP sería la estructura, mientras que el sitio sería cada uno de los pisos construidos sobre esa estructura”. Por tal motivo, es que Papaleo señala que el anuncio impactó a nivel mundial y destacó el ejemplo de la primera ministra de Japón, Sanae Takaichi, quien solicitó el máximo esfuerzo en parchear los sistemas. “No es un proceso sencillo”, afirmó el especialista, ya que requiere dar de baja temporalmente los sistemas, lo que paraliza diversos procesos.

¿Por qué se desconectaron los sitios del Estado?

Ante la alerta, varios organismos públicos uruguayos dejaron temporalmente fuera de servicio sus portales por orden del Certuy, organismo dependiente de Presidencia encargado de la ciberseguridad del Estado, mientras se realizaban las actualizaciones correspondientes.
La situación también se registró en otros países, donde las autoridades recomendaron instalar los parches de inmediato o desconectar los sistemas que no pudieran actualizarse a tiempo. De acuerdo con lo informado por la Agencia Reuters, los gobiernos de Alemania, Francia, Bélgica, Países Bajos, Finlandia y República Checa ordenaron desconectar sitios webs estatales para evitar infiltraciones.

Si bien Amestoy reconoció que la medida tuvo consecuencias para la ciudadanía, porque la disponibilidad de los portales públicos es necesaria para acceder a información y realizar trámites, señaló que el riesgo justificaba la interrupción temporal y que desde el punto de vista de la seguridad “la postura que tomó el Estado de poner todo en pausa fue inteligente”.

“En un mundo hiperconectado como el que estamos, todo es digital y no se admite que algo esté caído ni cinco minutos, porque todo es inmediato”, señaló Papaleo sobre la urgencia con la que actuaron los estados para actualizar los parches. El especialista también explicó que instalar una actualización no siempre es un procedimiento inmediato. Las organizaciones pueden utilizar distintas versiones del lenguaje, configuraciones específicas y aplicaciones que dependen de componentes antiguos.

Antes de restablecer el servicio, deben comprobar que las correcciones se hayan aplicado correctamente y que los sistemas continúen funcionando. “No todas están parcheadas, hay algunas que sí, otras que no. Entonces, si tenés que evolucionar a una parcheada, no siempre se puede hacer”, señaló.

Asimismo, si bien ya fueron restablecidos la mayoría de los portales web del Estado y la suspensión no superó las 48 horas, a la noche seguían afectados algunos procesos como el sistema de tienda virtual de la Agencia Reguladora de Compras Estatales o bajas temporales en los sistemas de solicitudes en línea de la Intendencia de Montevideo.

Foto del artículo 'PHP y las vulnerabilidades que encendieron las alarmas de empresas y estados: qué se sabe y qué riesgos persisten'

¿Hubo ataques informáticos?

El 21 de octubre, Amazon informó que su equipo de inteligencia de amenazas había detectado un intento de explotación de las vulnerabilidades el 17 de octubre, cuatro días antes de la publicación de los parches. La actividad fue identificada en un sistema señuelo utilizado para estudiar ataques informáticos. La empresa señaló que no estaba claro cómo el actor había obtenido información sobre las fallas antes de su divulgación pública.

Por otra parte, el portal especializado The Hacker News informó el pasado 27 de octubre que la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos (CISA) confirmó la explotación activa de las dos vulnerabilidades críticas de PHP, conocidas como PHP2Shell, que pueden permitir que un atacante ejecute código de forma remota en servidores vulnerables sin necesidad de autenticarse. La confirmación se produjo luego de que investigadores detectaron ejecuciones de código exitosas en sistemas señuelo (honeypots) el 24 de octubre.

Por eso, además de instalar las versiones corregidas, los administradores deben revisar los registros de actividad y buscar señales de accesos no autorizados. La CISA recomendó prestar atención, entre otros indicadores, a la ejecución de procesos inusuales y a la descarga de herramientas en los servidores.

Si bien no existen al momento informes de que los sistemas uruguayos hayan sido atacados, Amestoy advirtió que una intrusión podría no detectarse inmediatamente. “Puede pasar que alguien haya aprovechado la vulnerabilidad, que se haya metido a un servidor, robado datos y que nos enteremos dentro de un mes”, planteó. En Uruguay, los organismos públicos ya han enfrentado incidentes de ciberseguridad con consecuencias sobre la información estatal y los datos personales. Uno de los antecedentes más relevantes se remonta a 2020, cuando fue vulnerada la base de datos de la Dirección Nacional de Identificación Civil, dependiente del Ministerio del Interior, que comprometió los datos de 84.001 pasaportes electrónicos, incluidos fotografías, huellas dactilares, nombres y números de documentos. El incidente fue detectado el 8 de diciembre de ese año, aunque los primeros registros de la intrusión databan de octubre.

Otro caso de impacto significativo ocurrió en julio de 2024, cuando un ataque informático contra la Intendencia de Paysandú afectó varios servicios municipales. La liquidación de sueldos, el sistema tributario, el correo electrónico, el sitio web institucional y la conectividad con el Sistema Único de Cobro de Ingresos Vehiculares, entre otros servicios, quedaron comprometidos. Los atacantes sustrajeron y cifraron información con el objetivo de exigir un rescate, que la comuna se negó a pagar.

En 2025 también se registraron incidentes que afectaron a organismos nacionales. En marzo, la página web de la Dirección Nacional de Aviación Civil e Infraestructura Aeronáutica fue hackeada y exhibió mensajes políticos y datos personales. Sin embargo, el gobierno informó entonces que no había encontrado evidencias de acceso irregular al Sistema de Gestión de Seguridad Pública. En agosto, por su parte, la Oficina de Planeamiento y Presupuesto confirmó un acceso no autorizado a un conjunto de archivos, en un incidente en el que se reportó la filtración de 170 gigabytes de información.

“Tenemos experiencias bastante jodidas, como el hackeo al Banco Hipotecario en el que robaron las credenciales de un usuario”, recordó Amestoy, quien consideró que en Uruguay “algo hemos aprendido”, pero que “tenemos que estar preparados para que estas cosas pasen todos los días”.

Las afectaciones al sector privado

Las vulnerabilidades de PHP también afectaron a empresas privadas, aunque su alcance es difícil de dimensionar. Papaleo explicó que no existe un monitoreo que permita conocer cuántas empresas debieron interrumpir sus servicios o dejaron sus páginas web fuera de línea a raíz de estos problemas. “¿Quién está mirando esa información?”, advirtió el especialista.

Según Papaleo, el impacto alcanzó también a pequeñas y medianas empresas, que dependen de proveedores externos para mantener sus sitios web. “Son pymes o muchas veces dependen del que esté hosteando también la solución, que es el que le actualiza las cosas y no depende de ellos”, explicó. “Las empresas privadas sí han tenido impacto, lo que pasa es que muchos ni se enteraron”, resumió.

Para el especialista, el episodio presentó una dificultad que trasciende Uruguay y el sector público, que refiere a las limitaciones para actualizar los sistemas y aplicar parches de seguridad con rapidez. “Lo que no tiene la madurez todavía a nivel mundial y a nivel país es que en los procesos de TI y de ciberseguridad no hay procesos ágiles para realizar el parcheo de los sistemas o para tener todos los sistemas actualizados a las últimas versiones”, afirmó. Si bien consideró que mantener los sistemas actualizados es una práctica que “todo el mundo debería tener”, advirtió que “es costosa” y que, en muchos casos, no se implementa.

En ese sentido, Papaleo sostuvo que el problema “no es exclusivo de Uruguay ni del Estado”, sino de “madurez de la industria”, concluyó.

Octubre Negro: acumulación de fallas críticas y ataques con IA

Papaleo explicó que el episodio de PHP no fue un hecho aislado. Oracle, por ejemplo, lanzó parches para cerca de 1.500 vulnerabilidades en los últimos días. “Esa cantidad de vulnerabilidades en un producto era una cosa impensada hace uno o dos años. Ahora las tiene un solo producto en menos de un mes”, señaló el informático.

La sucesión de incidentes registrados durante octubre llevó a especialistas y empresas del sector a denominar al período Octubre Negro en referencia a la concentración de fallas críticas, filtraciones y problemas de seguridad en componentes tecnológicos utilizados a escala mundial.

En pocos días se publicaron alertas y actualizaciones de seguridad para tecnologías como PHP, GitLab, Python, Java y Node.js. Algunas de las fallas podían permitir la ejecución remota de código o el acceso no autorizado a sistemas. También se detectaron problemas en la infraestructura de confianza digital, como alertas sobre claves privadas comprometidas asociadas a certificados intermedios de la entidad certificadora eMudhra, lo que llevó a los principales navegadores a tomar medidas para dejar de confiar en los certificados afectados.

A esta acumulación se suma el uso de inteligencia artificial en ambos lados de la disputa. Aunque las herramientas de IA permiten a investigadores detectar fallas y desarrollar correcciones con mayor rapidez, también pueden ayudar a los atacantes a identificar objetivos, automatizar tareas y acelerar la explotación de vulnerabilidades.

“Cada día va a ser peor o más complejo. Después de todo, siempre el juego, en términos de seguridad informática y hackers, es la pelea entre el bueno y el malo”, opinó Amestoy.

¿Tenés algún aporte para hacer?

Valoramos cualquier aporte aclaratorio que quieras realizar sobre el artículo que acabás de leer.