Google agrega una espera de 24 horas para la descarga de aplicaciones no verificadas para reducir el malware y las estafas – CYBERDEFENSA.MX

Google el jueves anunciado un nuevo «flujo avanzado» para la descarga de Android que requiere un período de espera obligatorio de 24 horas para instalar aplicaciones de desarrolladores no verificados en un intento de equilibrar la apertura con la seguridad.

Los nuevos cambios se producen en el contexto de un mandato de verificación de desarrolladores que el gigante tecnológico anunció el año pasado que requiere que todas las aplicaciones de Android estén registradas por desarrolladores verificados para instalarse en dispositivos Android certificados. La medida, añadió, se hizo para detectar a los malos actores más rápidamente y evitar que distribuyan malware.

Esto también incluye escenarios potenciales en los que los ciberdelincuentes engañan a los usuarios desprevenidos que descargan dichas aplicaciones para que les otorguen privilegios elevados que permitan desactivar Play Protect, la función antimalware integrada en todos los dispositivos Android certificados por Google.

Ciberseguridad

Sin embargo, el requisitos de registro obligatorios ha sido recibió críticas de más de 50 desarrolladores de aplicaciones y mercados, incluidos F-Droid, Brave, The Electronic Frontier Foundation, Proton, The Tor Project, Vivaldi, quienes dicen que corren el riesgo de crear fricciones y barreras de entrada, y plantean preocupaciones sobre privacidad y vigilancia en ausencia de claridad sobre qué información personal deben proporcionar los desarrolladores, cómo se almacenarán, protegerán y utilizarán estos datos, y si podrían estar sujetos a solicitudes gubernamentales o procesos legales.

Como una forma de sofocar algunos de estos problemas espinosos, Google ha enfatizado que el flujo avanzado recientemente desarrollado permite a los usuarios avanzados mantener la capacidad de descargar aplicaciones de desarrolladores no verificados con un proceso único que requiere que sigan los pasos a continuación:

  • Habilite el modo desarrollador en la configuración del sistema.
  • Confirme que están dando este paso por su propia voluntad y que no están siendo entrenados.
  • Reinicie el teléfono y vuelva a autenticarse para evitar que un estafador controle las acciones que está realizando un usuario.
  • Espere un período de 24 horas y confirme que realmente están realizando este cambio con autenticación biométrica o PIN del dispositivo.
  • Instale aplicaciones de desarrolladores no verificados una vez que los usuarios comprendan los riesgos, ya sea de forma indefinida o por un período de siete días.

«En ese período de 24 horas, creemos que a los atacantes les resulta mucho más difícil persistir en su ataque», dijo el presidente del ecosistema Android, Sameer Samat. citado diciendo a Ars Técnica. «En ese tiempo, probablemente puedas descubrir que tu ser querido no está realmente encarcelado o que tu cuenta bancaria no está realmente bajo ataque».

Google también dijo que planea ofrecer «cuentas de distribución limitada» gratuitas que permitan a los desarrolladores aficionados y estudiantes compartir aplicaciones con hasta 20 dispositivos sin tener que «proporcionar una identificación emitida por el gobierno o pagar una tarifa de registro».

Vale la pena señalar que el proceso antes mencionado no se aplica a las instalaciones a través de Android Debug Bridge (ADB). Las cuentas de distribución limitadas para estudiantes y aficionados, así como el flujo avanzado para usuarios, estarán disponibles en agosto de 2026, antes de que los nuevos requisitos de verificación de desarrolladores entren en vigor el mes siguiente.

Ciberseguridad

«Sabemos que un enfoque de ‘talla única’ no funciona para nuestro ecosistema diverso», dijo Google. «Queremos asegurarnos de que la verificación de identidad no sea una barrera de entrada, por lo que ofrecemos diferentes caminos para satisfacer sus necesidades específicas».

El desarrollo coincide con la aparición de un nuevo malware para Android llamado Perseus que se dirige activamente a usuarios en Turquía e Italia con el objetivo de realizar apropiación de dispositivos (DTO) y fraude financiero.

Durante los cuatro meses, se han detectado al menos 17 familias de malware para Android. Incluyen FvncBot, SeedSnatcher, ClayRat, Wonderland, Cellik, Frogblight, NexusRoute, ZeroDayRAT, Arsink (y su variante mejorada SURXRAT), deVixor, Phantom, Massiv, PixRevolution, TaxiSpy RAT, BeatBanker, Mirax y Oblivion RAT.

Google corrige dos Chrome Zero-Day explotados en estado salvaje que afectan a Skia y V8 – CYBERDEFENSA.MX

Google lanzó el jueves actualizaciones de seguridad para su navegador web Chrome para abordar dos vulnerabilidades de alta gravedad que, según dijo, han sido explotadas en la naturaleza.

La lista de vulnerabilidades es la siguiente:

  • CVE-2026-3909 (Puntuación CVSS: 8,8): una vulnerabilidad de escritura fuera de límites en la biblioteca de gráficos Skia 2D que permite a un atacante remoto realizar acceso a memoria fuera de límites a través de una página HTML diseñada.
  • CVE-2026-3910 (Puntuación CVSS: 8,8): una vulnerabilidad de implementación inapropiada en el motor V8 JavaScript y WebAssembly que permite a un atacante remoto ejecutar código arbitrario dentro de un entorno limitado a través de una página HTML diseñada.

Ambas vulnerabilidades fueron descubiertas y reportadas por el propio Google el 10 de marzo de 2026. Como es habitual en estos casos, no hay detalles disponibles sobre cómo se está abusando de los problemas en la naturaleza y quién está detrás de los esfuerzos. Esto se hace para evitar que otros actores de amenazas exploten los problemas.

Ciberseguridad

«Google es consciente de que existen exploits tanto para CVE-2026-3909 como para CVE-2026-3910», dijo la empresa. anotado.

El desarrollo se produce menos de un mes después de que Google enviara correcciones para un error de uso después de la liberación de alta gravedad en el componente CSS de Chrome (CVE-2026-2441, puntuación CVSS: 8.8) que también había sido explotado como un día cero. Google ha parcheado un total de tres días cero de Chrome activamente armados desde principios de año.

Para una protección óptima, se recomienda a los usuarios actualizar su navegador Chrome a las versiones 146.0.7680.75/76 para Windows y Apple macOS, y 146.0.7680.75 para Linux. Para asegurarse de que estén instaladas las últimas actualizaciones, los usuarios pueden navegar a Más > Ayuda > Acerca de Google Chrome y seleccionar Reiniciar.

También se recomienda a los usuarios de otros navegadores basados ​​en Chromium, como Microsoft Edge, Brave, Opera y Vivaldi, que apliquen las correcciones cuando estén disponibles.

Las nuevas fallas de «LeakyLooker» en Google Looker Studio podrían permitir consultas SQL entre inquilinos – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han revelado nueve vulnerabilidades entre inquilinos en Google Looker Studio que podrían haber permitido a los atacantes ejecutar consultas SQL arbitrarias en las bases de datos de las víctimas y filtrar datos confidenciales dentro de los entornos de Google Cloud de las organizaciones.

Las deficiencias han sido nombradas colectivamente. Looker con fugas por Tenable. No hay evidencia de que las vulnerabilidades hayan sido explotadas en la naturaleza. Tras la divulgación responsable en junio de 2025, Google solucionó los problemas.

La lista de fallas de seguridad es la siguiente:

Ciberseguridad

«Las vulnerabilidades rompieron supuestos de diseño fundamentales, revelaron una nueva clase de ataque y podrían haber permitido a los atacantes filtrar, insertar y eliminar datos en los servicios de las víctimas y en el entorno de Google Cloud», dijo la investigadora de seguridad Liv Matan. dicho en un informe compartido con The Hacker News.

«Estas vulnerabilidades expusieron datos confidenciales en los entornos de Google Cloud Platform (GCP), afectando potencialmente a cualquier organización que utilice Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage y casi cualquier otro conector de datos de Looker Studio».

La explotación exitosa de las fallas entre inquilinos podría permitir a los actores de amenazas obtener acceso a conjuntos de datos y proyectos completos en diferentes inquilinos de la nube.

Los atacantes podrían buscar informes públicos de Looker Studio u obtener acceso a informes privados que utilicen estos conectores (por ejemplo, BigQuery) y tomar el control de las bases de datos, permitiéndoles ejecutar consultas SQL arbitrarias en todo el proyecto GCP del propietario.

Alternativamente, una víctima crea un informe como público o lo comparte con un destinatario específico y utiliza una fuente de datos conectada a JDBC, como PostgreSQL. En este escenario, el atacante puede aprovechar una falla lógica en la función de copia de informes que permite clonar informes conservando las credenciales del propietario original, lo que le permite eliminar o modificar tablas.

Otra ruta de alto impacto detallada por la compañía de ciberseguridad implicó la exfiltración de datos con un solo clic, donde compartir un informe especialmente diseñado obliga al navegador de la víctima a ejecutar código malicioso que contacta un proyecto controlado por un atacante para reconstruir bases de datos completas a partir de registros.

«Las vulnerabilidades rompieron la promesa fundamental de que un ‘espectador’ nunca debería poder controlar los datos que está viendo», dijo Matan, y agregó que «podrían haber permitido a los atacantes filtrar o modificar datos en los servicios de Google como BigQuery y Google Sheets».

Silver Dragon vinculado a APT41 apunta a gobiernos que utilizan Cobalt Strike y Google Drive C2 – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de un grupo de amenazas persistentes avanzadas (APT) denominado Dragón plateado que se ha relacionado con ataques cibernéticos dirigidos a entidades en Europa y el sudeste asiático desde al menos mediados de 2024.

«Silver Dragon obtiene su acceso inicial explotando servidores de Internet públicos y enviando correos electrónicos de phishing que contienen archivos adjuntos maliciosos», Check Point dicho en un informe técnico. «Para mantener la persistencia, el grupo secuestra servicios legítimos de Windows, lo que permite que los procesos de malware se mezclen con la actividad normal del sistema».

Se estima que Silver Dragon opera dentro del marco de APT41. APT41 es el criptonimo asignado a un prolífico grupo de hackers chino conocido por su objetivo de ciberespionaje en los sectores de salud, telecomunicaciones, alta tecnología, educación, servicios de viajes y medios de comunicación ya en 2012. También se cree que participa en actividades con motivación financiera potencialmente fuera del control estatal.

Se ha descubierto que los ataques organizados por Silver Dragon apuntan principalmente a entidades gubernamentales, y el adversario utiliza balizas Cobalt Strike para persistir en los hosts comprometidos. También se sabe que emplea técnicas como el túnel DNS para la comunicación de comando y control (C2) para evitar la detección.

Check Point dijo que identificó tres cadenas de infección diferentes para entregar Cobalt Strike: Secuestro de dominio de aplicaciónDLL de servicio y phishing basado en correo electrónico.

Ciberseguridad

«Las dos primeras cadenas de infección, el secuestro de AppDomain y el Service DLL, muestran una clara superposición operativa», dijo la empresa de ciberseguridad. «Ambas se entregan a través de archivos comprimidos, lo que sugiere su uso en escenarios posteriores a la explotación. En varios casos, estas cadenas se implementaron tras el compromiso de servidores vulnerables expuestos públicamente».

Las dos cadenas utilizan un archivo RAR que contiene un script por lotes, y la primera cadena lo utiliza para colocar MonikerLoader, un cargador basado en NET responsable de descifrar y ejecutar una segunda etapa directamente en la memoria. La segunda etapa, por su parte, imita el comportamiento de MonikerLoader, actuando como un conducto para cargar la carga útil final de la baliza Cobalt Strike.

Por otro lado, la cadena de DLL del servicio utiliza un script por lotes para entregar un cargador de DLL de código shell denominado BamboLoader, que está registrado como un servicio de Windows. Es un malware C++ muy ofuscado que se utiliza para descifrar y descomprimir el código shell almacenado en el disco e inyectarlo en un proceso legítimo de Windows, como «taskhost.exe». El binario destinado a la inyección se puede configurar dentro de BamboLoader.

La tercera cadena de infección implica una campaña de phishing dirigida principalmente a Uzbekistán con accesos directos maliciosos de Windows (LNK) como archivos adjuntos. El archivo LNK armado está diseñado para iniciar código PowerShell mediante «cmd.exe», lo que lleva a la extracción y ejecución de cargas útiles de la siguiente etapa. Esto incluye cuatro archivos diferentes:

  • documento señuelo
  • Ejecutable legítimo vulnerable a la carga lateral de DLL («GameHook.exe»)
  • DLL maliciosa también conocida como BamboLoader («graphics-hook-filter64.dll»)
  • Carga útil cifrada de Cobalt Strike («simhei.dat»)

Como parte de esta campaña, el documento señuelo se muestra a la víctima, mientras que, en segundo plano, la DLL maliciosa se descarga a través de «GameHook.exe» para finalmente iniciar Cobalt Strike. Los ataques también se caracterizan por el despliegue de diversas herramientas posteriores a la explotación:

  • Pantalla plateadauna herramienta de monitoreo de pantalla .NET utilizada para capturar capturas de pantalla periódicas de la actividad del usuario, incluida la posición precisa del cursor.
  • SSHcmduna utilidad SSH de línea de comandos .NET que proporciona ejecución remota de comandos y capacidades de transferencia de archivos a través de SSH.
  • Puerta de engranajesuna puerta trasera NET que comparte similitudes con MonikerLoader y se comunica con su infraestructura C2 a través de Google Drive.
Ciberseguridad

Una vez ejecutada, la puerta trasera se autentica en la cuenta de Google Drive controlada por el atacante y carga un archivo de latido que contiene información básica del sistema. Curiosamente, la puerta trasera utiliza diferentes extensiones de archivo para indicar la naturaleza de la tarea a realizar en el host infectado. Los resultados de la ejecución de la tarea se capturan y cargan en Drive.

  • *.pngpara enviar archivos de latidos.
  • *.pdfpara recibir y ejecutar comandos, enumerar el contenido de un directorio, crear un nuevo directorio y eliminar todos los archivos dentro de un directorio específico. Los resultados de la operación se envían al servidor en forma de archivo *.db.
  • *.taxipara recibir y ejecutar comandos para recopilar información del host y una lista de procesos en ejecución, enumerar archivos y directorios, ejecutar comandos a través de «cmd.exe» o tareas programadas, cargar archivos en Google Drive y finalizar el implante. El estado de ejecución se carga como un archivo .bak.
  • *.rarpara recibir y ejecutar cargas útiles. Si el archivo RAR se llama «wiatrace.bak», la puerta trasera lo trata como un paquete de actualización automática. Los resultados se cargan como archivos .bak.
  • *.7zpara recibir y ejecutar complementos en la memoria. Los resultados se cargan como archivos .bak.

Los vínculos de Silver Dragon con APT41 se derivan de superposiciones comerciales con scripts de instalación posteriores a la explotación anteriores. atribuido a este último y el hecho de que el mecanismo de descifrado utilizado por BamboLoader se ha observado en cargadores de shellcode vinculados a la actividad APT del nexo con China.

«El grupo evoluciona continuamente sus herramientas y técnicas, probando e implementando activamente nuevas capacidades en diferentes campañas», dijo Check Point. «El uso de diversos exploits de vulnerabilidad, cargadores personalizados y comunicación C2 sofisticada basada en archivos refleja un grupo de amenazas adaptable y con buenos recursos».

Google confirma CVE-2026-21385 en componente Qualcomm Android explotado – CYBERDEFENSA.MX

Google el lunes revelado que una falla de seguridad de alta gravedad que afecta a un componente de código abierto de Qualcomm utilizado en dispositivos Android ha sido explotada en la naturaleza.

La vulnerabilidad en cuestión es CVE-2026-21385 (Puntuación CVSS: 7,8), una lectura excesiva del búfer en el componente Gráficos.

«Corrupción de la memoria al agregar datos proporcionados por el usuario sin verificar el espacio disponible en el buffer», Qualcomm dicho en un aviso, describiéndolo como un desbordamiento de enteros.

El fabricante de chips dijo que se le informó sobre la falla a través del equipo de seguridad de Android de Google el 18 de diciembre de 2025. Los clientes fueron notificados sobre el defecto de seguridad el 2 de febrero de 2026.

Ciberseguridad

Actualmente no hay detalles sobre cómo se está explotando la vulnerabilidad en la naturaleza. Sin embargo, Google reconoció en su boletín mensual de seguridad de Android que «hay indicios de que CVE-2026-21385 puede estar bajo explotación limitada y dirigida».

La actualización de Google de marzo de 2026 contiene parches para un total de 129 vulnerabilidades, incluida una falla crítica en el componente del sistema (CVE-2026-0006) que podría conducir a la ejecución remota de código sin requerir privilegios adicionales ni interacción del usuario. Por el contrario, Google abordó una vulnerabilidad de Android en enero de 2026 y ninguna el mes pasado.

Google también ha solucionado varios errores clasificados como críticos: un error de escalada de privilegios en Framework (CVE-2026-0047), una denegación de servicio (DoS) en el sistema (CVE-2025-48631) y siete fallas de escalada de privilegios en los componentes del Kernel (CVE-2024-43859, CVE-2026-0037, CVE-2026-0038, CVE-2026-0027, CVE-2026-0028, CVE-2026-0030 y CVE-2026-0031).

El boletín de seguridad de Android incluye dos niveles de parche (2026-03-01 y 2026-03-05) para brindar a los socios de Android la flexibilidad de abordar vulnerabilidades comunes en diferentes dispositivos más rápidamente.

El segundo nivel de parche incluye correcciones para los componentes del Kernel, así como los de Arm, Imagination Technologies, MediaTek, Qualcomm y Unisoc.

Google aborda activamente el día cero de Qualcomm en un nuevo lote de 129 vulnerabilidades de Android

Google reveló el lunes una vulnerabilidad de día cero explotada activamente, advirtiendo que el defecto de alta gravedad que afecta a un componente de pantalla de código abierto de Qualcomm para dispositivos Android «puede estar bajo explotación limitada y dirigida».

La vulnerabilidad de la corrupción de la memoria CVE-2026-21385 – que el equipo de seguridad de Android de Google informó a Qualcomm el 18 de diciembre, afecta a 234 conjuntos de chips, dijo Qualcomm en un boletín de seguridad. Qualcomm dijo que notificó a los clientes sobre la vulnerabilidad el 2 de febrero.

Qualcomm se negó a decir cuándo ocurrió el primer caso conocido de explotación, cuántas víctimas se vieron afectadas directamente y qué ocurrió durante el período de 10 semanas entre el informe y la divulgación pública de la vulnerabilidad.

«Felicitamos a los investigadores del Grupo de Análisis de Amenazas de Google por utilizar prácticas de divulgación coordinadas», dijo un portavoz de Qualcomm a CyberScoop. «Las correcciones estuvieron disponibles para nuestros clientes en enero de 2026. Alentamos a los usuarios finales a aplicar actualizaciones de seguridad a medida que estén disponibles por parte de los fabricantes de dispositivos».

Un portavoz de Google dijo que Qualcomm marcó la vulnerabilidad como explotada. «No tenemos ninguna información ni acceso a los informes de explotación», añadió el portavoz.

Google solucionó 129 defectos en su actualización de seguridad mensual para dispositivos Android, lo que refleja un aumento en las divulgaciones de vulnerabilidades por parte del proveedor. La última actualización de seguridad de la compañía contiene la mayor cantidad de vulnerabilidades de Android parcheadas en un solo mes desde abril de 2018.

El programa público de divulgación e informes de vulnerabilidades de Google para Android ha sido desigual. La empresa normalmente publicaba docenas de parches de seguridad cada mes, pero esa cadencia se ha convertido en una rutina más ocasional.

En lo que va del año, Google abordó una vulnerabilidad de Android en enero y ninguna en febrero. También hubo pausas ocasionales el año pasado cuando Google no informó ninguna vulnerabilidad en julio y octubre, seis en agosto y dos vulnerabilidades en noviembre. Sin embargo, las divulgaciones para 2025 alcanzaron su punto máximo con 120 defectos en septiembre y repuntaron nuevamente en diciembre con 107 vulnerabilidades, incluidas dos de día cero.

Google respondió anteriormente a preguntas sobre caídas en la cantidad de vulnerabilidades que revela cada mes, señalando que sigue centrado en los defectos que representan el mayor peligro.

«Android detiene la mayor parte de la explotación de vulnerabilidades en la fuente con un amplio refuerzo de la plataforma, como nuestro uso del lenguaje Rust, seguro para la memoria, y protecciones antiexplotación avanzadas», dijo un portavoz de Google en diciembre. «Android y Pixel abordan continuamente las vulnerabilidades de seguridad conocidas y priorizan reparar y parchar primero las de mayor riesgo».

El boletín de seguridad de Android de marzo incluye dos niveles de parche (2026-03-01 y 2026-03-05), lo que permite a los socios de Android abordar vulnerabilidades comunes en diferentes dispositivos. Los fabricantes de dispositivos Android lanzan parches de seguridad según su propio calendario después de haber personalizado las actualizaciones del sistema operativo para su hardware específico.

La actualización de seguridad principal contiene 63 vulnerabilidades, incluidas 32 en el marco, 19 en el sistema y 12 que afectan a Google Play. Casi la mitad de esas vulnerabilidades tienen identificadores CVE a partir de 2025.

El segundo parche aborda 66 vulnerabilidades, incluidas 15 vulnerabilidades que afectan al kernel, un defecto de un componente Arm, siete fallas de Imagination Technologies y siete vulnerabilidades en los componentes de Unisoc.

El segundo nivel de parche también contiene correcciones para ocho vulnerabilidades en componentes de Qualcomm de código cerrado y siete defectos de alta gravedad en componentes de Qualcomm de código abierto, incluido CVE-2026-21385.

Google dijo que el código fuente de todas las vulnerabilidades abordadas en el boletín de seguridad de Android de este mes se publicará en el repositorio del Proyecto de Código Abierto de Android el miércoles.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

Google desarrolla certificados Merkle Tree para habilitar HTTPS resistente a Quantum en Chrome

Google ha anunciado un nuevo programa en su navegador Chrome para garantizar que los certificados HTTPS estén seguros frente al riesgo futuro que suponen los ordenadores cuánticos.

«Para garantizar la escalabilidad y eficiencia del ecosistema, Chrome no tiene un plan inmediato para agregar versiones tradicionales Certificados X.509 que contiene criptografía post-cuántica al Tienda raíz de Chrome«, el equipo de redes y web segura de Chrome dicho.

«En cambio, Chrome, en colaboración con otros socios, está desarrollando un evolución de certificados HTTPS basados ​​en Certificados de árbol Merkle (MTC), actualmente en desarrollo en el grupo de trabajo PLANTS.»

Como explica Cloudflare, MTC es un propuesta para la próxima generación de infraestructura de clave pública (PKI) utilizada para proteger Internet, cuyo objetivo es reducir la cantidad de claves públicas y firmas en el protocolo de enlace TLS al mínimo requerido.

Ciberseguridad

Bajo este modelo, una Autoridad de Certificación (CA) firma un único ‘Tree Head’ que representa potencialmente millones de certificados, y el ‘certificado’ enviado al navegador es una prueba ligera de inclusión en ese árbol, dijo Google.

En otras palabras, los MTC facilitan la adopción de algoritmos poscuánticos sin tener que incurrir en ancho de banda adicional asociado con las cadenas de certificados X.509 clásicas. El enfoque, añadió la empresa, desacopla la seguridad del algoritmo criptográfico correspondiente del tamaño de los datos transmitidos al usuario.

«Al reducir al mínimo absoluto los datos de autenticación en un protocolo de enlace TLS, los MTC pretenden mantener la web poscuántica tan rápida y fluida como la Internet actual, manteniendo un alto rendimiento incluso cuando adoptamos una seguridad más sólida», dijo Google.

El gigante tecnológico dijo que ya está experimentando con MTC con tráfico de Internet real y que planea expandir gradualmente el lanzamiento en tres fases distintas para el tercer trimestre de 2027.

  • Fase 1 (En curso): Google está llevando a cabo un estudio de viabilidad en colaboración con Cloudflare para evaluar el rendimiento y la seguridad de las conexiones TLS que dependen de MTC.
  • Fase 2 (Primer trimestre de 2027): Google planea invitar a Certificate Transparency (CT) Registro operadores con al menos un «usable«Inicie sesión en Chrome antes del 1 de febrero de 2026 para participar en el arranque inicial de los MTC públicos.
  • Fase 3 (Tercer trimestre de 2027): Google finalizará los requisitos para incorporar CA adicionales en el nuevo almacén raíz resistente a Chrome Quantum (CQRS) y el programa raíz correspondiente que solo admite MTC.

«Consideramos la adopción de MTC y un almacén raíz resistente a los cuánticos como una oportunidad crítica para garantizar la solidez de las bases del ecosistema actual», dijo Google. Al diseñar para las demandas específicas de una Internet moderna y ágil, podemos acelerar la adopción de la resiliencia poscuántica para todos los usuarios de la web.

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».