Ubiquiti corrige fallas críticas de UniFi en Connect, Talk, Access, Protect y OS – CYBERDEFENSA.MX

Ubiquiti tiene actualizaciones enviadas para abordar múltiples fallas de seguridad críticas que afectan a UniFi Connect, UniFi Talk, UniFi Access, UniFi Protect y UniFi OS que podrían resultar en una escalada de privilegios y la ejecución de comandos arbitrarios.

La lista de vulnerabilidades es la siguiente:

  • CVE-2026-50746 (Puntuación CVSS: 10,0): una vulnerabilidad de control de acceso inadecuado en la aplicación UniFi Connect que un atacante con acceso a la red podría aprovechar para ejecutar una inyección de comando en el dispositivo host. (Afecta a las versiones 3.4.16 y anteriores; solucionado en la versión 3.4.20)
  • CVE-2026-50747 (Puntuación CVSS: 9,9): una serie de vulnerabilidades de inyección SQL autenticadas en la aplicación UniFi Talk que un atacante con acceso a la red podría aprovechar para escalar privilegios en el dispositivo host. (Afecta a las versiones 5.1.2 y anteriores; solucionado en la versión 5.2.2)
  • CVE-2026-50748 (Puntuación CVSS: 9,9): una vulnerabilidad de validación de entrada incorrecta en la aplicación UniFi Access que un atacante con acceso a la red podría aprovechar para ejecutar una inyección de comando en el dispositivo host. (Afecta a las versiones 4.2.28 y anteriores; solucionado en la versión 4.2.29)
  • CVE-2026-54400 (Puntuación CVSS: 9,1): una vulnerabilidad de control de acceso inadecuado en la aplicación UniFi Access que un atacante con acceso a la red podría aprovechar para escalar privilegios en el dispositivo host. (Afecta a las versiones 4.2.28 y anteriores; solucionado en la versión 4.2.29)
  • CVE-2026-55115 (Puntuación CVSS: 9,9): una vulnerabilidad de falsificación de solicitudes del lado del servidor (SSRF) en la aplicación UniFi Protect que un atacante con acceso a la red y privilegios bajos podría aprovechar para escalar privilegios en el dispositivo host. (Afecta a 7.1.77 y anteriores; solucionado en la versión 7.1.83)
  • CVE-2026-54402 (Puntuación CVSS: 9,9): una vulnerabilidad de validación de entrada incorrecta en el sistema operativo UniFi que un atacante con acceso a la red podría aprovechar para ejecutar una inyección de comando en el dispositivo host. (Afecta a las versiones 5.1.15 y anteriores; solucionado en la versión 5.1.19)
  • CVE-2026-55116 (Puntuación CVSS: 9,0): una vulnerabilidad de control de acceso inadecuado en el sistema operativo UniFi que un atacante con acceso a la red podría aprovechar para realizar cambios no autorizados en ciertos dispositivos. (Afecta a las versiones 5.1.15 y anteriores; solucionado en la versión 5.1.19)
Ciberseguridad

Si bien no hay evidencia de que las fallas hayan sido explotadas en la naturaleza, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) señaló que un conjunto de tres vulnerabilidades en el sistema operativo UniFi (CVE-2026-34908, CVE-2026-34909 y CVE-2026-34910) habían sido utilizadas como arma en ataques del mundo real el mes pasado.

También se ha observado que actores de amenazas patrocinados por el estado ruso reclutan enrutadores Ubiquiti Edge OS comprometidos en una botnet diseñada para representar tráfico malicioso. La botnet, denominada MooBot, fue derribada en una operación policial en febrero de 2024.

OpenAI amplía el programa Trusted Access for Cyber ​​con el nuevo modelo GPT 5.4 Cyber

Abierto AI dicho está ampliando su programa Trusted Access for Cyber ​​a “miles de personas y organizaciones” que utilizarán la tecnología de la empresa para eliminar errores y vulnerabilidades en sus productos.

El programa también incorporará GPT 5.4 Cyber, una nueva variante de ChatGPT que, según OpenAI, está optimizada específicamente para tareas de ciberseguridad. El objetivo de OpenAI con esta versión es hacer que las herramientas avanzadas de ciberseguridad sean más accesibles.

La compañía dijo que el acceso al programa y al modelo centrado en la ciberseguridad seguirá estando regido por reglas «fuertes» de verificación de identidad y de conocimiento de su cliente para ayudar a prevenir la propagación del modelo a malos actores.

«Nuestro objetivo es hacer que estas herramientas estén lo más ampliamente disponibles posible y al mismo tiempo prevenir el uso indebido», dijo la compañía en un blog publicado el martes. «Diseñamos mecanismos que evitan decidir arbitrariamente quién obtiene acceso para uso legítimo y quién no».

El anuncio de OpenAI se produce una semana después de que Anthropic lanzara el Proyecto Glasswing, un esfuerzo similar que busca proporcionar a las principales empresas de tecnología Claude Mythos, un modelo inédito que, según los funcionarios de Anthropic, es demasiado peligroso para venderlo comercialmente.

Los funcionarios de OpenAI señalaron públicamente anunciado Programa Trusted Access for Cyber ​​meses antes. También han evitado silenciosamente comparaciones directas con Mythos y GPT 5.4 Cyber.

Los expertos en ciberseguridad de EE. UU. y el Reino Unido han descrito a Mythos como una mejora significativa con respecto a los modelos fronterizos anteriores en cuanto a identificar (y potencialmente explotar) vulnerabilidades de ciberseguridad, aunque persiste el debate y la especulación sobre el impacto final del modelo en la seguridad de la información.

De manera similar, GPT 5.4 Cyber ​​se ha perfeccionado para pruebas e investigación de vulnerabilidades, aunque OpenAI quiere realizar mejoras iterativas en el programa a medida que se aprenden lecciones.

La compañía tiene planes de permitir que un grupo más amplio de operadores cibernéticos utilice el modelo para proteger infraestructuras críticas, servicios públicos y otros sistemas digitales. La compañía dijo que también teme tener demasiada influencia sobre qué industrias o sectores finalmente participan en el programa.

«No creemos que sea práctico o apropiado decidir de forma centralizada quién puede defenderse», afirma el blog. «En lugar de eso, nuestro objetivo es permitir que haya tantos defensores legítimos como sea posible, con un acceso basado en la verificación, las señales de confianza y la rendición de cuentas».

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

Miles de claves API públicas de Google Cloud expuestas con Gemini Access después de la habilitación de API – CYBERDEFENSA.MX

Una nueva investigación ha descubierto que se podría abusar de las claves API de Google Cloud, generalmente designadas como identificadores de proyecto con fines de facturación, para autenticarse en puntos finales sensibles de Gemini y acceder a datos privados.

Los hallazgos provienen de Truffle Security, que descubrió casi 3.000 claves API de Google (identificadas por el prefijo «AIza») incrustadas en el código del lado del cliente para proporcionar servicios relacionados con Google, como mapas incrustados en sitios web.

«Con una clave válida, un atacante puede acceder a los archivos cargados, a los datos almacenados en caché y cargar el uso de LLM a su cuenta», dijo el investigador de seguridad Joe Leon. dichoañadiendo las claves «ahora también se autentican en Gemini aunque nunca fueron destinadas a ello».

El problema ocurre cuando los usuarios habilitan la API de Gemini en un proyecto de Google Cloud (es decir, API de lenguaje generativo), lo que hace que las claves de API existentes en ese proyecto, incluidas aquellas a las que se puede acceder a través del código JavaScript del sitio web, obtengan acceso subrepticio a los puntos finales de Gemini sin ninguna advertencia o aviso.

Ciberseguridad

Esto permite efectivamente que cualquier atacante que raspe sitios web obtenga dichas claves API y las utilice con fines nefastos y robo de cuotas, incluido el acceso a archivos confidenciales a través de los puntos finales /files y /cachedContents, así como realizar llamadas a la API Gemini, acumulando enormes facturas para las víctimas.

Además, Truffle Security descubrió que la creación de una nueva clave API en Google Cloud tiene como valor predeterminado «Sin restricciones», lo que significa que es aplicable para todas las API habilitadas en el proyecto, incluido Gemini.

«El resultado: miles de claves API que se implementaron como tokens de facturación benignos ahora son credenciales de Gemini activas en la Internet pública», dijo Leon. En total, la compañía dijo que encontró 2.863 claves activas accesibles en la Internet pública, incluido un sitio web asociado con Google.

La divulgación se produce cuando Quokka publicó un informe similar, en el que encontró más de 35.000 claves API únicas de Google integradas en su análisis de 250.000 aplicaciones de Android.

«Más allá del posible abuso de costos a través de solicitudes automatizadas de LLM, las organizaciones también deben considerar cómo los puntos finales habilitados para IA podrían interactuar con mensajes, contenido generado o servicios en la nube conectados de manera que amplíen el radio de explosión de una clave comprometida», dijo la empresa de seguridad móvil. dicho.

«Incluso si no se puede acceder a datos directos del cliente, la combinación de acceso a inferencia, consumo de cuotas y posible integración con recursos más amplios de Google Cloud crea un perfil de riesgo que es materialmente diferente del modelo de identificador de facturación original en el que confiaron los desarrolladores».

Aunque inicialmente se consideró que el comportamiento era intencionado, desde entonces Google intervino para solucionar el problema.

«Somos conscientes de este informe y hemos trabajado con los investigadores para abordar el problema», dijo un portavoz de Google a The Hacker News por correo electrónico. «Proteger los datos y la infraestructura de nuestros usuarios es nuestra principal prioridad. Ya hemos implementado medidas proactivas para detectar y bloquear claves API filtradas que intentan acceder a la API de Gemini».

Actualmente no se sabe si este problema alguna vez fue explotado en la naturaleza. Sin embargo, en un publicación en Reddit publicado hace dos días, un usuario afirmó que una clave API de Google Cloud «robada» resultó en cargos de $82,314.44 entre el 11 y el 12 de febrero de 2026, frente a un gasto regular de $180 por mes.

Nos comunicamos con Google para obtener más comentarios y actualizaremos la historia si recibimos una respuesta.

Ciberseguridad

Se recomienda a los usuarios que hayan configurado proyectos de Google Cloud que verifiquen sus API y servicios, y verifiquen si las API relacionadas con la inteligencia artificial (IA) están habilitadas. Si están habilitadas y son de acceso público (ya sea en JavaScript del lado del cliente o registradas en un repositorio público), asegúrese de que las claves estén rotadas.

«Empiece primero con las claves más antiguas», dijo Truffle Security. «Es más probable que se hayan implementado públicamente bajo la antigua guía de que las claves API se pueden compartir de forma segura y luego obtuvieron privilegios de Gemini de manera retroactiva cuando alguien de su equipo habilitó la API».

«Este es un gran ejemplo de cómo el riesgo es dinámico y cómo las API pueden tener permisos excesivos después del hecho», dijo Tim Erlin, estratega de seguridad de Wallarm, en un comunicado. «Las pruebas de seguridad, el escaneo de vulnerabilidades y otras evaluaciones deben ser continuas».

«Las API son complicadas en particular porque los cambios en sus operaciones o los datos a los que pueden acceder no son necesariamente vulnerabilidades, pero pueden aumentar directamente el riesgo. La adopción de IA que se ejecuta en estas API y su uso solo acelera el problema. Encontrar vulnerabilidades no es suficiente para las API. Las organizaciones tienen que perfilar el comportamiento y el acceso a los datos, identificar anomalías y bloquear activamente la actividad maliciosa».