SAFE. Guía para proteger tu vida digital y tu privacidad
Showing posts with label gigantes. Show all posts
Showing posts with label gigantes. Show all posts

Jun 25, 2026

LastPass confirma (de nuevo) brecha que filtró nombres, teléfonos y direcciones de correo de sus usuarios

LastPass ha tenido un historial complicado en materia de seguridad durante los últimos años. De acuerdo con TechCrunch, la brecha no ocurrió directamente en LastPass, sino en Klue, una plataforma que la empresa utiliza en sus operaciones comerciales. Según el reporte, los atacantes aprovecharon el acceso a Klue para obtener tokens OAuth que la plataforma almacenaba en nombre de sus clientes, incluido LastPass.

LastPass se suma a una creciente lista de empresas de ciberseguridad que han reportado robos de datos como consecuencia de la brecha de seguridad en Klue, que la compañía reveló la semana pasada. Otras empresas afectadas incluyen Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium.

Con esas credenciales, los atacantes lograron entrar en el entorno de Salesforce de LastPass y extraer datos de sus usuarios. La información comprometida incluye nombres, números de teléfono, direcciones de correo electrónico y direcciones físicas, junto con datos de casos de soporte al cliente y registros relacionados con ventas. Tras detectar la presencia de atacantes en su sistema, Klue notificó a LastPass sobre el incidente.

Lo que todavía no está claro es el contenido exacto de los tickets de soporte al cliente. Ese tipo de registros suele contener fragmentos de información sensible, ya que los usuarios generalmente contactan con soporte cuando tienen problemas de facturación o necesitan recuperar el acceso a sus cuentas. Incidentes anteriores con datos de tickets de soporte han llegado a exponer credenciales y documentos de identidad oficiales.

LastPass ha declarado que la brecha de Klue no afectó a sus sistemas en ningún momento. Las contraseñas almacenadas en las bóvedas de los usuarios permanecen seguras, y no hay evidencia de que los atacantes accedieran a datos relacionados con la plataforma Gong, otra herramienta integrada con Klue.

La reputación de LastPass lleva tiempo acumulando golpes. En 2022, la compañía sufrió una brecha mucho más grave en la que los atacantes se hicieron con todas las bóvedas cifradas de contraseñas de sus clientes. Aunque esos archivos estaban protegidos con las contraseñas maestras de cada usuario, los hackers consiguieron descifrar algunas de ellas que usaban claves débiles y las aprovecharon para acceder a billeteras de criptomonedas.

Este nuevo incidente es menos catastrófico en comparación, pero tiene sus propias implicaciones. Tener tu nombre, teléfono y dirección en manos de atacantes es suficiente para convertirte en objetivo de phishing o ingeniería social. LastPass lo reconoce en su comunicado oficial y recomienda a sus usuarios estar alerta ante cualquier contacto no solicitado, ya sea por email, teléfono u otros canales.

Otro detalle que vale la pena recordar es que nadie de LastPass te pedirá jamás tu contraseña maestra. Si recibes un mensaje solicitándola, independientemente de cómo esté redactado, es una señal de alarma.

Según el reporte, el responsable del ataque es un grupo de extorsión llamado Icarus, que también ha atacado a otras compañías a través de la brecha en Klue. El grupo ya amenazó con publicar los datos robados si no recibe un pago por rescate. Klue, por su parte, aún no ha confirmado cuántos clientes se han visto afectados ni si ha habido contacto con los atacantes.

LastPass confirmó que han remediado el problema y los tokens OAuth expuestos han sido rotados desde entonces. "Los productos, servicios e infraestructuras de LastPass no se vieron afectados de ninguna manera y las bóvedas de clientes siguen siendo seguros", mencionó.

Fuente: TechCrunch

Jun 12, 2026

Vulnerabilidad Zero-Day en Oracle PeopleSoft (CVE-2026-35273) siendo explotada

El grupo de extorsionadores ShinyHunters explotó una vulnerabilidad sin parchear en Oracle PeopleSoft para infiltrarse en sistemas empresariales, robar datos y exigir un pago para mantenerlos privados. La campaña afectó principalmente a las universidades.

Mandiant, de Google, atribuye la actividad al grupo UNC6240 y la fecha entre el 27 de mayo y el 9 de junio. Oracle no publicó su aviso hasta el 10 de junio, por lo que la vulnerabilidad fue de Zero-Day durante todo ese período.

La vulnerabilidad, CVE-2026-35273, es un fallo de ejecución remota de código en PeopleSoft Enterprise PeopleTools con una calificación de 9.8 sobre 10. No requiere inicio de sesión ni interacción del usuario; solo acceso a la red mediante HTTP para tomar el control del servidor. Si utiliza PeopleSoft con el Centro de administración de entornos accesible desde el exterior, está expuesto, y la medida inmediata es proteger esos puntos finales.

La vulnerabilidad reside en el componente de Administración de entornos de actualizaciones, el componente que gestiona el Centro de administración de entornos (PSEMHUB). Oracle indica que PeopleTools 8.61 y 8.62 están afectadas y que las versiones anteriores, sin soporte, probablemente también sean vulnerables. Atribuye el informe a investigadores de TrendAI Zero Day Initiative y TrendAI Research.

Charles Carmakal, CTO de Mandiant, confirmó que la vulnerabilidad está siendo explotada; Oracle no ha confirmado si ha detectado alguna explotación. Su aviso remite a un documento de disponibilidad de parches que requiere una cuenta de soporte, y no está claro si existe una solución completa disponible para todos. Por ahora, la guía se centra en la mitigación.

Los detalles operativos se hicieron públicos porque los atacantes dejaron sus propios equipos expuestos. La investigadora @nahamike01 señaló públicamente los directorios abiertos. Mandiant analizó cinco direcciones IP consecutivas que ejecutaban el servidor SimpleHTTP de Python en el puerto 8888. Estos servidores expusieron los archivos de preparación: un archivo .bash_history compartido, agentes de administración remota MeshCentral personalizados disfrazados de binarios de Microsoft Azure y un script de movimiento lateral.

Los agentes se conectaron a un servidor de comando y control en azurenetfiles.net, un dominio elegido para imitar Azure NetApp Files. El script, llamado [victim]_fanout.sh, se propaga a través de SSH enviando una lista predefinida de nombres de usuario y contraseñas a hosts internos obtenidos de /etc/hosts, y luego coloca un archivo marcador llamado README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT en directorios de PeopleSoft. El historial de comandos muestra los datos comprimidos con zstd y una conexión SSH saliente al servidor que aloja la copia pública del sitio de filtración ShinyHunters.

Mandiant notificó a más de 100 organizaciones cuyas direcciones IP coincidían con los puntos finales vulnerables. El 68% pertenecían al sector de la educación superior, la mayoría en Estados Unidos. Algunas bloquearon la actividad; otras fueron comprometidas y sus datos se publicaron en el sitio de filtración.

La Universidad de Nottingham es una de las primeras víctimas confirmadas. Have I Been Pwned ha contabilizado aproximadamente 455.000 direcciones de correo electrónico únicas en la filtración, que incluye a estudiantes actuales y antiguos alumnos, con nombres, direcciones, números de teléfono, números de pasaporte e información sobre etnia y discapacidades. La universidad ha confirmado la brecha de seguridad.

Oracle recomienda deshabilitar el servicio Environment Management Hub en configuraciones multiservidor o eliminar la aplicación PSEMHUB por completo en configuraciones de un solo servidor. Si no es posible realizar ninguna de estas acciones, bloquee el acceso externo a /PSEMHUB/* (especialmente /PSEMHUB/hub) y /PSIGW/HttpListeningConnector en el perímetro.

Mandiant advierte que las reglas de inspección del cuerpo del WAF por sí solas no son suficientes, ya que pueden eludirse. Restringir estos puntos finales no interrumpe las sesiones de usuario normales.

A continuación, busque indicios de una posible vulneración:

  • Registros de acceso de WebLogic que muestren solicitudes POST externas a /PSEMHUB/hub o /PSIGW/HttpListeningConnector. Archivos .jsp inesperados en el directorio de la aplicación web PSEMHUB.war, o carpetas extrañas llamadas logs, persistantstorage o scratchpad en las rutas de PSEMHUB.
  • Archivos .xml modificados recientemente en envmetadata/data/environment del directorio raíz del documento web, que pueden ser explotados para la persistencia de XMLDecoder que se activa en el siguiente reinicio.
  • Tráfico SMB saliente en el puerto 445 desde hosts de PeopleSoft a destinos externos, que la cadena de exploits puede usar para capturar hashes NetNTLM de cuentas de máquina.
  • Aplique la actualización de Oracle para su versión de PeopleTools una vez que confirme que está disponible en My Oracle Support.

ShinyHunters afirma que la búsqueda de víctimas acaba de comenzar y no ha publicado la mayoría de las organizaciones que menciona, por lo que es probable que haya más nombres.

El método es la clave. Últimamente, ShinyHunters ha recurrido al vishing, tokens robados y controles de acceso débiles para robar datos de plataformas SaaS y educativas, desde clientes de Salesforce hasta Canvas. Una vulnerabilidad de día cero en un servidor de software ERP local representa un avance significativo, dirigido a los mismos objetivos con gran cantidad de datos.

La incógnita reside en si se trató de una vulnerabilidad de día cero aislada o del inicio de la incursión de ShinyHunters en la explotación de sistemas ERP.

Fuente: THN

May 22, 2026

GitHub confirma la violación de 3.800 repositorios mediante una extensión maliciosa VSCode

GitHub ha confirmado que aproximadamente 3.800 repositorios internos fueron vulnerados después de que uno de sus empleados instalara una extensión maliciosa de VS Code. Desde entonces, la compañía eliminó la extensión troyanizada sin nombre del mercado de VS Code y aseguró el dispositivo comprometido.

"Ayer detectamos y contuvimos un dispositivo comprometido de un empleado que involucraba una extensión VS Code envenenada. Eliminamos la versión de la extensión maliciosa, aislamos el punto final y comenzamos a responder al incidente de inmediato", dijo la compañía. "Nuestra evaluación actual es que la actividad implicó la exfiltración de repositorios internos de GitHub únicamente. Las afirmaciones actuales del atacante de ~3.800 repositorios son direccionalmente consistentes con nuestra investigación hasta el momento".

Esto se produce después de que GitHub dijera el martes por la noche que estaba investigando reclamos de acceso no autorizado a sus repositorios internos y agregó que no tiene evidencia de que los datos de los clientes almacenados fuera de los repositorios afectados se hayan visto afectados.

Si bien GitHub aún no ha atribuido la infracción, el grupo de hackers TeamPCP reclamó acceso al código fuente de GitHub y "~4.000 repositorios de código privado" en el foro de cibercrimen Breached el martes, pidiendo al menos 50.000 dólares por los datos robados.

​TeamPCP estuvo vinculado anteriormente a ataques masivos a la cadena de suministro dirigidos a plataformas de código de desarrollador, incluidas GitHub, PyPI, NPM, and Docker, y, más recientemente, a la campaña de la cadena de suministro "Mini Shai-Hulud" (que también afectó a dos empleados de OpenAI).

Las extensiones de VS Code son complementos que se pueden instalar desde VS Code Marketplace (la tienda oficial de complementos para el editor de código de Microsoft) para agregar funciones o integrar herramientas en el editor.

Esta no es la primera vez que se detecta en el mercado una extensión VS Code troyanizada, ya que en los últimos años se han utilizado muchas otras extensiones maliciosas con millones de instalaciones para robar credenciales de desarrollador y otros datos confidenciales.

Por ejemplo, el año pasado, las extensiones VSCode con 9 millones de instalaciones fueron retiradas por riesgos de seguridad, y 10 más, haciéndose pasar por herramientas de desarrollo legítimas, infectaron a los usuarios con el criptominero XMRig.

Más adelante en el año, una extensión maliciosa con capacidades básicas de ransomware se coló en el mercado de VS Code después de que un actor de amenazas llamado WhiteCobra lo inundara con 24 extensiones de robo de criptomonedas.

Más recientemente, en enero, dos extensiones maliciosas anunciadas como asistentes de codificación basadas en inteligencia artificial con 1,5 millones de instalaciones extrajeron datos de sistemas de desarrolladores comprometidos a servidores en China.

La plataforma basada en la nube de GitHub ahora es utilizada por más de 4 millones de organizaciones (incluido el 90% de las Fortune 100) y más de 180 millones de desarrolladores que contribuyen a más de 420 millones de repositorios de código.

Actualización: GitHub ahora ha vinculado esta infracción con el ataque a la cadena de suministro de npm de TanStack y dice que el empleado instaló una versión maliciosa de la extensión de la consola Nx.

Fuente: BC

May 1, 2026

Ubuntu interrumpido por ataque DDoS

Un grupo de hacktivistas se atribuyó la responsabilidad de la caída de la infraestructura pública de Ubuntu, la popular distribución del sistema operativo Linux, así como de Canonical, la empresa que desarrolla y mantiene el software. El ataque comenzó el jueves y continúa afectando a servicios esenciales para los usuarios de Ubuntu.

"La infraestructura web de Canonical está sufriendo un ataque transfronterizo sostenido y estamos trabajando para solucionarlo. Proporcionaremos más información a través de nuestros canales oficiales tan pronto como sea posible", declaró la empresa en su sitio web.

Los servicios impactados son los siguientes:

Se cree que los hacktivistas lanzaron un ataque de denegación de servicio distribuido (DDoS), un ataque rudimentario pero a menudo efectivo que consiste en saturar un objetivo con tráfico basura hasta sobrecargarlo o colapsarlo.

Los desarrolladores de Ubuntu han estado debatiendo el ataque en un foro no oficial de la comunidad, afirmando que afecta a la API de seguridad de Ubuntu y a varios sitios web de Ubuntu y Canonical. Según una publicación en un foro de inteligencia sobre amenazas, el ataque DDoS también ha impedido a los usuarios actualizar e instalar Ubuntu. TechCrunch verificó que las actualizaciones no se instalaron en un dispositivo de prueba con Ubuntu.

Los hacktivistas que se hacen llamar The Islamic Cyber Resistance in Iraq 313 Team afirmaron en su canal de Telegram ser los responsables del ataque DDoS. El grupo afirmó estar utilizando Beamed, un servicio de DDoS por encargo.

Este tipo de servicios, también conocidos como booters o stressers, permiten a cualquier persona pagar para lanzar ataques DDoS, incluso sin conocimientos técnicos ni la infraestructura necesaria para saturar los objetivos con tráfico falso. En este caso, el servicio de ataques DDoS por encargo afirma tener capacidad para realizar ataques de más de 3,5 Tbps, lo que representa aproximadamente la mitad del ancho de banda de un ciberataque que Cloudflare calificó el año pasado como el "mayor ataque DDoS jamás registrado".

Fuente: TechCrunch

Apr 27, 2026

Phishing y estafas en Booking, luego del hackeo y filtración de datos de clientes, reservas y contactos


 La plataforma, reconocida a nivel mundial por su servicio de reservas de alojamiento, ha notificado a una parte de sus usuarios sobre el acceso no autorizado a información sensible vinculada a sus reservas. Aunque la empresa descarta que los atacantes hayan accedido a datos financieros, recomienda a sus clientes permanecer atentos ante posibles intentos de fraude y phishing derivados del incidente.

Los ataques de phishing ya han comenzado. Este tipo de robos de datos se aprovechan para ataques de phishing masivos, y parece que dichos ataques ya han comenzado. Al menos un usuario indicó en Reddit que había recibido un mensaje sospechoso por WhatsApp con detalles de su reserva e información personal. Eso parece confirmar que los atacantes ya están usando los datos robados para engañar a clientes antes de que se produjera el anuncio público.

Ya hay cientos de casos de usuarios estafados con las cuentas obtenidas.Para tratar de mitigar posibles problemas, la empresa forzó el reseteo de los PIN de reserva de todas las reservas afectadas, tanto activas como pasadas.

La compañía ha comunicado que detectó actividad sospechosa en sus sistemas, lo que derivó en un acceso no autorizado a datos relacionados con las reservas. Booking explicó a Infobae que "terceros no autorizados lograron acceder a parte de la información de reservas de algunos de nuestros clientes".

Entre los datos comprometidos figuran nombres, direcciones de correo electrónico, domicilios, números de teléfono y detalles de las reservas, así como cualquier otra información compartida con el alojamiento correspondiente.

A pesar del alcance del ataque, la empresa asegura que la información financiera de sus usuarios permanece segura, ya que no se accedió a esos datos desde sus sistemas. Como medida de precaución, Booking actualizó el número PIN de las reservas afectadas e informó puntualmente a los clientes involucrados.

Ante el escenario generado por la brecha de seguridad, Booking insta a sus usuarios a estar especialmente atentos a posibles intentos de phishing. La plataforma advierte que nunca solicitará información de tarjetas de crédito por canales como correo electrónico, teléfono, WhatsApp o SMS, ni requerirá transferencias bancarias fuera de las condiciones de pago estipuladas en la confirmación de la reserva.

Durante las próximas semanas, es recomendable que los usuarios de Booking extremen la precaución ante mensajes, correos o llamadas que puedan simular comunicaciones oficiales y transmitir urgencia.

Los ciberdelincuentes suelen emplear tácticas de presión para inducir respuestas rápidas, presentando falsas alertas sobre cargos inminentes o supuestos problemas con la reserva. Es fundamental desconfiar de cualquier comunicación que exija acciones inmediatas para evitar cargos, ya que suelen ser intentos de fraude.

La empresa no especificó cuántos clientes resultaron afectados ni la duración exacta del acceso no autorizado, aunque confirmó haber notificado a la autoridad de protección de datos de Países Bajos, en cumplimiento de la normativa vigente. Booking también anunció el refuerzo de sus medidas de seguridad para proteger a sus usuarios en el futuro.

Fuente: Xataka

Apr 23, 2026

CLI de Bitwarden comprometida en la campaña de la cadena de suministro de Checkmarx

Bitwarden CLI se ha visto comprometida como parte de la campaña de cadena de suministro Checkmarx recientemente descubierta y en curso, según nuevos hallazgos de JFrog y Socket.

Cuando se le contactó para hacer comentarios, Bitwarden confirmó el incidente, pero enfatizó que no se accedió a datos del usuario final como parte del ataque.

"La versión del paquete afectado parece ser @bitwarden/[email protected], y el código malicioso fue publicado en 'bw1.js', un archivo incluido en el contenido del paquete", dijo la compañía de seguridad de aplicaciones. "El ataque parece haber aprovechado una GitHub Action comprometida en el proceso de CI/CD de Bitwarden, consistente con el patrón observado en otros repositorios afectados en esta campaña".

En una publicación en X, JFrog dijo que la versión fraudulenta del paquete "roba tokens de GitHub/npm, .ssh, .env, historial de shell, acciones de GitHub y secretos de la nube, luego filtra los datos a dominios privados y a medida que GitHub se compromete".

Si bien la versión maliciosa ya no está disponible para descargar desde npm, Socket dijo que el compromiso sigue el mismo vector de cadena de suministro de GitHub Actions identificado en la campaña Checkmarx.

Como parte del esfuerzo, se descubrió que los actores de amenazas abusan de tokens de GitHub robados para inyectar un nuevo flujo de trabajo de GitHub Actions que captura secretos disponibles para la ejecución del flujo de trabajo y utiliza credenciales NPM recopiladas para enviar versiones maliciosas del paquete para leer el malware a los usuarios posteriores.

Según el investigador de seguridad Adnan Khan, se dice que el actor de amenazas utilizó un flujo de trabajo malicioso para publicar la CLI de bitwarden maliciosa. "Creo que esta es la primera vez que un paquete que utiliza la publicación confiable de NPM se ve comprometido", agregó Khan.

Se sospecha que el actor de amenazas conocido como TeamPCP está detrás del último ataque dirigido a Checkmarx. Al momento de escribir este artículo, la cuenta X de TeamPCP ha sido suspendida por violar las reglas de la plataforma.

OX Security, en un desglose del ataque, dijo que identificó la cadena "Shai-Hulud: The Third Coming" en el paquete, lo que sugiere que esta es probablemente la siguiente fase de la campaña de ataque a la cadena de suministro que salió a la luz el año pasado.

"El último incidente de Shai Hulud es sólo el último de una larga cadena de amenazas dirigidas a desarrolladores de todo el mundo. Los datos de los usuarios se están filtrando públicamente a GitHub, a menudo pasando desapercibidos porque las herramientas de seguridad normalmente no señalan los datos que se envían allí", dijo Moshe Siman Tov Bustan, líder del equipo de investigación de seguridad de OX Security. "Esto hace que el riesgo sea significativamente más peligroso: cualquiera que busque en GitHub puede potencialmente encontrar y acceder a esas credenciales. En ese punto, los datos confidenciales ya no están en manos de un solo actor de amenazas, sino que están expuestos a cualquiera".

La investigación de Bitwarden no encontró evidencia de que se hubiera accedido a los datos de la bóveda del usuario final o que estuvieran en riesgo, o que los datos o sistemas de producción estuvieran comprometidos. Una vez que se detectó el problema, se revocó el acceso comprometido, la versión maliciosa de npm quedó obsoleta y se iniciaron medidas de reparación de inmediato.

El problema afectó el mecanismo de distribución de NPM para la CLI durante esa ventana limitada, no la integridad del código base legítimo de la CLI de Bitwarden ni los datos almacenados de la bóveda.

Los usuarios que no descargaron el paquete de NPM durante esa ventana no se vieron afectados.

Fuente: THN

Apr 19, 2026

Brecha de seguridad en Vercel (CAMBIA las variables y API)

La plataforma de desarrollo en la nube Vercel ha revelado un incidente de seguridad luego de que ciberdelincuentes afirmaran haber vulnerado sus sistemas e intentaran vender los datos robados.

Vercel ha confirmado la brecha de seguridad mientras actores de amenazas afirman estar vendiendo datos robados. En un boletín de seguridad, la compañía indicó que un subconjunto limitado de clientes se vio afectado por una brecha de seguridad.

Vercel es una plataforma en la nube que proporciona infraestructura de alojamiento e implementación para desarrolladores, con un fuerte enfoque en frameworks de JavaScript. La compañía es conocida por desarrollar Next.js, un framework de React ampliamente utilizado, y por ofrecer servicios como funciones sin servidor, computación perimetral y pipelines de CI/CD que permiten a los desarrolladores crear, previsualizar e implementar aplicaciones.

"Hemos identificado un incidente de seguridad que implicó el acceso no autorizado a ciertos sistemas internos de Vercel", advierte Vercel. "Estamos investigando activamente y hemos contratado a expertos en respuesta a incidentes para que nos ayuden en la investigación y la remediación. Hemos notificado a las autoridades y actualizaremos esta página a medida que avance la investigación".

La empresa afirma que sus servicios no se han visto afectados y que está trabajando con los clientes afectados. Vercel indica que está tomando medidas para proteger a sus clientes, aconsejándoles que revisen las variables de entorno, utilicen su función de variables de entorno sensibles y roten las claves secretas si es necesario.

Mientras tanto, en un conocido foro se ofrecen los supuestos datos robados por 2 millones de dólares, incluyendo claves API, código fuente y cuentas de empleados. Tras la publicación de esta noticia, Vercel actualizó su aviso para indicar que la brecha se originó por la vulneración de la aplicación OAuth de Google Workspace de una herramienta de IA de terceros.

Vercel recomienda a los administradores de Google Workspace y a los propietarios de cuentas de Google que revisen la siguiente aplicación:

Aplicación OAuth: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Mediante una serie de maniobras que se iniciaron desde la cuenta de Google Workspace de Vercel comprometida de un empleado, el atacante obtuvo acceso a los entornos de Vercel. Posteriormente, Guillermo Rauch, CEO de Vercel, compartió detalles adicionales sobre X, indicando que el acceso inicial se produjo después de que la cuenta de Google Workspace de un empleado de Vercel se viera comprometida mediante una brecha en la plataforma de IA Context.ai.

Según Rauch, el atacante escaló el acceso desde la cuenta comprometida a los entornos de Vercel, donde pudo acceder a variables de entorno que no estaban marcadas como sensibles y, por lo tanto, no estaban cifradas en reposo. Si bien estaban destinadas a contener información no sensible, el atacante obtuvo acceso adicional tras enumerar estas variables.

"Vercel almacena todas las variables de entorno de los clientes completamente cifradas en reposo. Contamos con numerosos mecanismos de defensa en profundidad para proteger los sistemas centrales y los datos de los clientes", afirmó Rauch. "Sin embargo, tenemos la capacidad de designar las variables de entorno como 'no sensibles'. Desafortunadamente, el atacante obtuvo acceso adicional mediante su enumeración". La investigación de la compañía ha confirmado que Next.js, Turbopack y sus demás proyectos de código abierto siguen siendo seguros.

Por su parte, Context.ai informó que alertó de inmediato a todos los clientes afectados y les proporcionó los pasos necesarios a seguir. No reveló cuántos clientes se vieron afectados por la brecha de seguridad. En un informe publicado hoy, Hudson Rock reveló que un empleado de Context.ai fue víctima de Lumma Stealer en febrero de 2026, lo que plantea la posibilidad de que la infección haya desencadenado la escalada de la cadena de suministro. Las credenciales corporativas robadas durante el ataque incluían credenciales de Google Workspace, junto con claves y accesos para Supabase, Datadog y Authkit.

Entre los registros robados también se encontraba la cuenta "[email protected]", lo que probablemente permitió al atacante escalar privilegios, eludir los controles de seguridad y acceder con éxito a la infraestructura de Vercel. Se estima que el usuario es un miembro clave del equipo "context-inc" de Vercel.

"Los registros indican que el usuario buscaba y descargaba activamente exploits para juegos, específicamente scripts y ejecutores de 'auto-farming' para Roblox. Este tipo de descargas maliciosas son vectores conocidos para la implementación de Lumma Stealer.", declaró la empresa.

Vercel también ha implementado actualizaciones en su panel de control, incluyendo una página de resumen de variables de entorno y una interfaz mejorada para gestionar variables de entorno sensibles.

Se recomienda encarecidamente a los clientes que revisen las variables de entorno en busca de información sensible y que activen la función de variables sensibles para garantizar su cifrado en reposo.

Recomendaciones

La investigación continúa pero, mientras tanto, estas son las mejores prácticas que puede seguir para su tranquilidad:

  • Revise el registro de actividad de su cuenta y entornos en busca de actividad sospechosa. Puede revisar los registros de actividad en el panel de control o mediante CLI.
  • Revise y rote las variables de entorno. Las variables de entorno marcadas como "confidenciales" en Vercel se almacenan de forma que se impide su lectura, y actualmente no tenemos evidencia de que se haya accedido a esos valores. Sin embargo, si alguna de sus variables de entorno contiene secretos (claves API, tokens, credenciales de base de datos, claves de firma) que no se marcaron como confidenciales, esos valores deben tratarse como potencialmente expuestos y rotarse con prioridad.
  • Aproveche la función de variables de entorno confidenciales en el futuro para proteger los valores secretos de futuras lecturas.
  • Investigue las implementaciones recientes en busca de implementaciones inesperadas o sospechosas. En caso de duda, elimine las implementaciones en cuestión.
  • Asegúrese de que la Protección de Implementación esté configurada como mínimo en Estándar.
  • Rote sus tokens de Protección de Implementación, si los tiene configurados.

Para obtener ayuda para rotar sus secretos o para cualquier otro tipo de asistencia técnica, póngase en contacto vercel.com/help.

Fuente: BC

Apr 6, 2026

LinkedIn escanea más de 6.000 extensiones de Chrome y recopila datos

Un nuevo informe, denominado BrowserGate, advierte que LinkedIn, propiedad de Microsoft, utiliza JavaScript ocultos en su sitio web para escanear los navegadores de los visitantes en busca de extensiones instaladas y recopilar datos de sus dispositivos.

Según un informe, que afirma ser una asociación de usuarios comerciales de LinkedIn, la plataforma de Microsoft inyecta JavaScript en las sesiones de los usuarios para comprobar miles de extensiones de navegador y vincular los resultados a perfiles de usuario identificables.

El autor afirma que esta práctica se utiliza para recopilar información personal y corporativa sensible, ya que las cuentas de LinkedIn están vinculadas a identidades reales, empleadores y puestos de trabajo.

"LinkedIn escanea más de 200 productos que compiten directamente con sus propias herramientas de ventas, incluyendo Apollo, Lusha y ZoomInfo. Dado que LinkedIn conoce el empleador de cada usuario, puede identificar qué empresas utilizan qué productos de la competencia. Está extrayendo las listas de clientes de miles de empresas de software de los navegadores de sus usuarios sin que nadie lo sepa", afirma el informe.

"Luego utiliza la información que encuentra". LinkedIn ya ha enviado amenazas de represalias a usuarios de herramientas de terceros, utilizando datos obtenidos mediante este escaneo encubierto para identificar a sus objetivos.

BleepingComputer ha confirmado de forma independiente parte de estas afirmaciones mediante sus propias pruebas, durante las cuales observaron que el sitio web de LinkedIn cargaba un archivo JavaScript con un nombre aleatorio. Este script comprobaba la presencia de 6.236 extensiones de navegador intentando acceder a los recursos de archivo asociados a un ID de extensión específico, una técnica conocida para detectar si las extensiones están instaladas.

Este script de identificación de extensiones ya se había reportado en 2025, pero en aquel entonces solo detectaba aproximadamente 2.000 extensiones. Un repositorio de GitHub diferente, de hace dos meses, muestra la detección de 3.000 extensiones, lo que demuestra que el número de extensiones detectadas sigue aumentando.

Si bien muchas de las extensiones analizadas están relacionadas con LinkedIn, el script también detectó, de forma extraña, extensiones de idioma y gramática, herramientas para profesionales fiscales y otras funciones aparentemente no relacionadas.

Además, el script recopila una amplia gama de datos del navegador y del dispositivo, incluyendo el número de núcleos de la CPU, la memoria disponible, la resolución de pantalla, la zona horaria, la configuración de idioma, el estado de la batería, información de audio y las características de almacenamiento.

BleepingComputer no pudo verificar las afirmaciones del informe BrowserGate sobre el uso de los datos ni si estos se comparten con terceros. Sin embargo, en el pasado se han utilizado técnicas de huella digital similares para crear perfiles de navegador únicos, lo que permite rastrear a los usuarios en diferentes sitios web.

LinkedIn niega las acusaciones de uso de datos.

LinkedIn no niega detectar extensiones de navegador específicas y declaró que la información se utiliza para proteger la plataforma y a sus usuarios. No obstante, la empresa afirma que el informe proviene de una persona cuya cuenta fue suspendida por extraer contenido de LinkedIn e infringir los términos de uso del sitio.

LinkedIn afirma que el informe BrowserGate surge de una disputa con el desarrollador de una extensión de navegador relacionada con LinkedIn llamada "Teamfluence", la cual, según LinkedIn, fue restringida por infringir los términos de la plataforma. En documentos compartidos con BleepingComputer, un tribunal alemán denegó la solicitud de medida cautelar del desarrollador, al considerar que las acciones de LinkedIn no constituían obstrucción ilegal ni discriminación.

El tribunal también determinó que la recopilación automatizada de datos por sí sola podría infringir los términos de uso de LinkedIn y que la plataforma tenía derecho a bloquear las cuentas para protegerla. LinkedIn argumenta que el informe BrowserGate es un intento de reabrir públicamente dicha disputa.

Independientemente de los motivos del informe, un punto es indiscutible: El sitio web de LinkedIn utiliza un script de identificación que detecta más de 6.000 extensiones ejecutándose en un navegador Chromium, junto con otros datos sobre el sistema del visitante. Esta no es la primera vez que las empresas utilizan scripts de identificación agresivos para detectar programas que se ejecutan en el dispositivo de un visitante.

En 2021, se descubrió que eBay utilizaba JavaScript para realizar escaneos automáticos de puertos en los dispositivos de los visitantes y determinar si ejecutaban diversos programas de soporte remoto. Aunque eBay nunca confirmó el motivo del uso de estos scripts, se creía que se utilizaban para bloquear el fraude en dispositivos comprometidos.

Posteriormente, se descubrió que numerosas otras empresas utilizaban el mismo script de identificación, entre ellas Citibank, TD Bank, Ameriprise, Chick-fil-A, Lendup, BeachBody, Equifax IQ Connect, TIAA-CREF, Sky, GumTree y WePay.

Fuente: BC


Mar 26, 2026

Condenan a Meta y a Google por diseñar productos adictivos

Un jurado ha declarado a Meta y a Google responsables civilmente y obligadas a pagar indemnizaciones a una joven de 20 años que alegó que su adicción a las plataformas de redes sociales de ambas compañías le provocó una crisis de salud mental. El veredicto incluyó una indemnización de 6 millones de dólares para la demandante, actualmente de 20 años. Ambas compañías anticiparon que apelarán la decisión.

La demandante ha salido victoriosa por el veredicto que ha sido emitido en Los Ángeles. Tanto Meta como Google están sufriendo miles de demandas similares que sostienen que Instagram y YouTube están diseñadas intencionalmente para generar adicción en usuarios jóvenes sin considerar su bienestar.

El jurado ha determinado que Meta deberá pagar al menos 2,1 millones de dólares en daños y perjuicios, y que Google debe abonar al menos 900.000 dólares. El jurado escuchará más argumentos para decidir si también impone daños punitivos a las compañías.

Sin embargo, según declaraciones atribuidas a un portavoz de Google, la compañía no está de acuerdo "con el veredicto y planean apelar", ya que "este caso malinterpreta a YouTube, que es una plataforma de streaming construida de manera responsable, no un sitio de redes sociales".

Este es el primer caso de este tipo que aparece por el Tribunal Estatal de California, donde un jurado de doce miembros debía determinar si Meta y Google actuaron con negligencia en el diseño y la operación de sus plataformas. Además, concretaron si las plataformas deberían haber advertido de que sus productos podían ser perjudiciales para los menores.

Kaley afirmó haber comenzado a ver videos en YouTube a los seis años y a usar la aplicación de fotos Instagram a los nueve. La víctima responsabilizó a las plataformas de diversos daños, entre ellos ansiedad, depresión y dismorfia corporal.

En paralelo, fiscales generales de aproximadamente 30 estados también iniciaron acciones judiciales contra estas compañías. En ese contexto, un jurado en Nuevo México emitió recientemente otro veredicto contra Meta, con una indemnización de 375 millones de dólares, al considerar que la empresa engañó a adolescentes respecto de las herramientas de protección frente a riesgos como la explotación sexual.

El fallo de Los Ángeles es el primero dentro de un conjunto de miles de demandas similares en curso contra empresas como Meta, Google, Snap y TikTok. Estas acciones incluyen tanto reclamos individuales por daños personales como presentaciones de distritos escolares en Estados Unidos, que sostienen que el uso de redes sociales afecta el desempeño académico y el entorno educativo.

Fuente: BusinessInsider

Feb 10, 2026

El FBI no pudo acceder al iPhone de un reportero porque tenía activado el Lockdown Mode

El FBI no ha podido acceder al iPhone confiscado de una periodista del Washington Post porque estaba en modo de bloqueo, una función a veces pasada por alto que hace que los iPhones sean mucho más seguros.

El registro judicial muestra a qué dispositivos y datos pudo acceder el FBI, y a cuáles no, tras allanar el domicilio de la periodista, Hannah Natanson, en enero, como parte de una investigación sobre filtraciones de información clasificada. También ofrece una perspectiva poco común sobre la aparente eficacia del modo de bloqueo, o al menos sobre su posible eficacia antes de que el FBI intente otras técnicas para acceder al dispositivo.

"Debido a que el iPhone estaba en modo de bloqueo, CART no pudo extraer datos", se lee en el expediente judicial, refiriéndose a CART, el Equipo de Respuesta de Análisis Informático del FBI, una unidad dedicada a realizar análisis forenses de dispositivos incautados.

El FBI allanó el domicilio de Natanson como parte de su investigación sobre el contratista gubernamental Aurelio Pérez-Lugones, acusado, entre otros cargos, de retención de información de defensa nacional. El gobierno cree que Pérez-Lugones fue una fuente de información para Natanson y le proporcionó información clasificada. Mientras se ejecutaba una orden de registro para su teléfono móvil, los investigadores revisaron los mensajes de Signal entre Pérez-Lugones y la periodista.

Posteriormente, el gobierno obtuvo órdenes de registro para la residencia, el vehículo y la persona de Natanson con el fin de incautar sus dispositivos electrónicos. Esas órdenes incluían cláusulas que les habrían permitido legalmente presionar los dedos de Natanson sobre los dispositivos, o acercarlos a su rostro, para desbloquearlos si la biometría estaba activada.

En el piso superior de la residencia de Natanson, el FBI encontró una MacBook Pro plateada apagada, un iPhone 13 de Apple, una grabadora de audio de la marca Handy y un disco duro portátil Seagate, según el expediente judicial. "El iPhone se encontró encendido y cargándose, y su pantalla indicaba que el teléfono estaba en modo de 'bloqueo'", dice el expediente judicial.

El expediente judicial que menciona el Lockdown Mode se presentó el 30 de enero, aproximadamente dos semanas después de que el FBI allanara la residencia de Natanson, lo que indica que el FBI no ha podido acceder al iPhone durante ese tiempo.

Apple comercializa principalmente el "Modo Bloqueo" como una función para mitigar el spyware de acceso remoto, como el que venden empresas como NSO Group a agencias gubernamentales. En esencia, el Modo Bloqueo realiza algunos cambios en el funcionamiento de iOS para dificultar que terceros hackeen un iPhone. Bloquea la mayoría de los tipos de archivos adjuntos en los mensajes; carga las páginas web de forma diferente; y detiene las llamadas de FaceTime a menos que hayas llamado a esa persona en los últimos 30 días.

Herramientas de análisis forense móvil como Graykey y Cellebrite, que las fuerzas del orden utilizan para acceder a teléfonos, funcionan conectándose físicamente a un teléfono para luego desbloquearlo. "Muchas técnicas forenses avanzadas y herramientas policiales se basan en vulnerabilidades que el Modo Bloqueo bloquea o limita explícitamente", declaró Andrew Garrett, director ejecutivo de la firma de análisis forense digital Garrett Discovery, a 404 Media.

Existe una constante interacción entre las empresas que fabrican teléfonos móviles y sus sistemas operativos, concretamente Apple y Google, y las empresas que crean herramientas para acceder a esos dispositivos. En 2024, 404 Media reveló que Apple introdujo discretamente un código que reiniciaba los iPhones después de un tiempo sin interacción, lo que dificultaba su desbloqueo por parte de la policía. En general, a las autoridades les resulta más difícil descifrar dispositivos que han estado apagados o no se han desbloqueado desde su encendido, un estado conocido como Antes del Primer Desbloqueo (Before First Unlock - BFU).

El FBI aún pudo acceder a otro de los dispositivos de Natanson, concretamente a una segunda MacBook Pro plateada. El expediente judicial indica que el FBI aún no ha obtenido una imagen física completa del dispositivo, que ofrece una visión prácticamente completa de lo que contenía. Sin embargo, los agentes sí tomaron fotos y grabaciones de audio de las conversaciones almacenadas en la aplicación Signal de la computadora portátil, según el expediente judicial.

Fuente: 404Media

Jan 26, 2026

Microsoft entregó al FBI claves para desbloquear datos cifrados con BitLocker

A principios del año pasado, el FBI entregó a Microsoft una orden de registro, solicitándole claves de recuperación para desbloquear los datos cifrados almacenados en tres equipos portátiles. Los investigadores federales en Guam creían que los dispositivos contenían pruebas que ayudarían a demostrar que quienes gestionaban el programa de asistencia por desempleo formaban parte de un complot para robar fondos.

Los datos estaban protegidos con BitLocker, un software que se habilita automáticamente en muchos Windows modernos para salvaguardar todos los datos del disco duro. BitLocker codifica los datos para que solo quienes tengan una clave puedan descifrarlos.

Los usuarios pueden almacenar esas claves en un dispositivo propio, pero Microsoft también recomienda que los usuarios de BitLocker guarden sus claves en sus servidores para mayor comodidad. Si bien esto significa que alguien puede acceder a sus datos si olvida su contraseña o si los repetidos intentos fallidos de iniciar sesión bloquean el dispositivo, también los expone a citaciones y órdenes judiciales de las fuerzas del orden.

Microsoft confirmó a Forbes que proporciona claves de recuperación de BitLocker si recibe una orden judicial válida. "Si bien la recuperación de claves ofrece comodidad, también conlleva el riesgo de acceso no deseado, por lo que Microsoft cree que los clientes son quienes mejor pueden decidir cómo administrar sus claves", declaró Charles Chamberlayne, portavoz de Microsoft.

Añadió que la compañía recibe alrededor de 20 solicitudes de claves de BitLocker al año y, en muchos casos, el usuario no ha almacenado su clave en la nube, lo que imposibilita que Microsoft pueda ayudarle.

El caso de Guam es el primer caso conocido en el que la empresa de Redmond, Washington, ha proporcionado una clave de cifrado a las fuerzas del orden. En 2013, un ingeniero de Microsoft afirmó que funcionarios del gobierno le habían contactado para instalar puertas traseras en BitLocker, pero que había rechazado las solicitudes.

Este no es un problema exclusivo de EE.UU. Jennifer Granick, asesora de vigilancia y ciberseguridad de la ACLU, señaló que gobiernos extranjeros con historiales cuestionables en materia de derechos humanos también exigen datos a gigantes tecnológicos como Microsoft. "El almacenamiento remoto de claves de descifrado puede ser bastante peligroso", afirmó.

Las fuerzas del orden solicitan regularmente a los gigantes tecnológicos que proporcionen claves de cifrado, implementen accesos de puerta trasera o debiliten su seguridad de otras maneras. Sin embargo, otras empresas se han negado. A Apple, en particular, se le ha solicitado repetidamente acceso a datos cifrados en su nube o en sus dispositivos. En un enfrentamiento muy publicitado con el gobierno en 2016, Apple impugnó una orden del FBI para ayudar a abrir los teléfonos de los terroristas que dispararon y mataron a 14 personas en San Bernardino, California. Finalmente, el FBI encontró a un contratista para hackear los iPhones.

Expertos en privacidad y cifrado declararon a Forbes que Microsoft debería tener la responsabilidad de brindar una mayor protección a los dispositivos y datos personales de los consumidores. Apple, con sus sistemas comparables FileVault y Passwords, y la aplicación de mensajería WhatsApp de Meta también permiten a los usuarios realizar copias de seguridad de los datos en sus aplicaciones y almacenar una clave en la nube.

Sin embargo, ambos permiten al usuario guardar la clave en un archivo cifrado en la nube, lo que hace inútiles las solicitudes de las fuerzas del orden. No se ha informado de que ninguno de los dos haya entregado claves de cifrado de ningún tipo en el pasado. "Se trata de datos privados en una computadora privada, y tomaron la decisión arquitectónica de mantener el acceso a esos datos. Definitivamente deberían tratarlos como algo que pertenece al usuario", dijo Matt Green, experto en criptografía y profesor asociado del Instituto de Seguridad de la Información de la Universidad Johns Hopkins.

"Si Apple puede hacerlo, si Google puede hacerlo, entonces Microsoft puede hacerlo. Microsoft es la única empresa que no lo está haciendo. Es un poco extraño… La lección aquí es que si se tiene acceso a las claves, eventualmente las fuerzas del orden vendrán".

Granick expresó su preocupación por la cantidad de información que el FBI podría obtener si los agentes acceden a datos protegidos por BitLocker. "Las claves le dan al gobierno acceso a información mucho más allá del plazo de la mayoría de los delitos, a todo lo que está en el disco duro", dijo. "Entonces debemos confiar en que los agentes solo busquen información relevante para la investigación autorizada y no aprovechen la oportunidad para hurgar en ella".

Tanto Green como Granick afirmaron que Microsoft podría obligar a los usuarios a instalar una clave en un dispositivo de hardware, como una memoria USB, que funcionaría como clave de respaldo o recuperación. Microsoft permite esa opción, pero no es la configuración predeterminada de BitLocker en PC con Windows.

Sin las claves de cifrado de Microsoft, el FBI habría tenido dificultades para obtener datos útiles de las computadoras. Los algoritmos de cifrado de BitLocker han demostrado ser impenetrables ante intentos previos de las fuerzas del orden, según una revisión de casos históricos. A principios de 2025, un experto forense de la unidad de Investigaciones de Seguridad Nacional del ICE escribió en un documento judicial que su agencia "no contaba con las herramientas forenses necesarias para acceder a dispositivos cifrados con Microsoft BitLocker ni con ningún otro tipo de cifrado". En un caso anterior, investigadores federales obtuvieron claves al descubrir que un sospechoso las había almacenado en unidades sin cifrar.

Ahora que el FBI y otras agencias saben que Microsoft cumplirá con órdenes judiciales similares al caso de Guam, es probable que exijan más claves de cifrado, afirmó Green. "Mi experiencia me dice que, una vez que el gobierno estadounidense se acostumbra a tener una capacidad, es muy difícil deshacerse de ella".

Fuente: Forbes

Jan 9, 2026

Microsoft forzará el MFA en su Centro de Administración a partir de febrero

A partir del próximo mes, Microsoft comenzará a implementar de forma obligatoria la autenticación multifactor (MFA) para todos los usuarios que accedan al Centro de administración de Microsoft 365.

Si bien los requisitos de MFA para el Centro de Administración comenzaron a implementarse en febrero de 2025, Microsoft los implementará a partir de ahora para todos los usuarios y bloqueará el inicio de sesión en el portal de administración de Microsoft 365 a quienes no tengan MFA habilitada tras la entrada en vigor del cambio el 9 de febrero de 2026.

Esto afectará a las URL del Centro de administración utilizadas por los administradores de TI para administrar cuentas y servicios de Microsoft 365:

Microsoft afirmó que implementar la MFA para todos los inicios de sesión en el Centro de Administración añade una protección crucial que va más allá de la seguridad estándar con contraseñas, lo que dificulta considerablemente que los atacantes vulneren las cuentas. "Implementar la MFA en el Centro de administración de Microsoft 365 reduce significativamente el riesgo de vulneración de cuentas, evita el acceso no autorizado y protege los datos confidenciales".

Al añadir una capa adicional de protección, además de la autenticación estándar de nombre de usuario y contraseña, la MFA dificulta el robo de datos por parte de atacantes y previene el acceso no autorizado mediante phishing, robo de credenciales, ataques de fuerza bruta o reutilización de contraseñas.

Microsoft también instó a los administradores a tomar medidas inmediatas para evitar interrupciones en las operaciones de TI y las funciones administrativas, ya que las organizaciones que no habiliten la MFA antes de la fecha límite de febrero experimentarán interrupciones de acceso cuando los administradores comiencen a experimentar errores de inicio de sesión.

Los administradores globales pueden configurar la MFA mediante el asistente de configuración de Microsoft o siguiendo la documentación oficial. Los usuarios individuales pueden comprobar sus métodos de verificación y agregar opciones de autenticación a través del portal de configuración de MFA de Microsoft.

Microsoft también ha estado aplicando la MFA para los inicios de sesión del Portal de Azure en todos los inquilinos desde marzo de 2025, un cambio anunciado en mayo de 2024, cuando comenzó a exigir la MFA a todos los usuarios que inician sesión en Azure para administrar recursos. También comenzó a aplicar la MFA en la CLI de Azure, PowerShell, SDK y API en octubre de 2025 para proteger las cuentas de los usuarios contra ataques.

Un estudio de Microsoft de noviembre de 2023 descubrió que el 99,99% de las cuentas protegidas con MFA bloquean con éxito los intentos de ataque y que MFA también redujo la posibilidad de que la cuenta se vea comprometida en un 98,56%, incluso cuando las credenciales están comprometidas.

Fuente: BC

Jan 8, 2026

WhatsApp corrige de forma silenciosa vulnerabilidades que permitían fingerprinting

El investigador Tal Be'ery afirma que han descubierto que WhatsApp está implementando silenciosamente correcciones para las vulnerabilidades de privacidad de huellas dactilares de los dispositivos. Aunque la empresa no lo reconozca públicamente y la corrección siga incompleta, al menos indica que WhatsApp finalmente está comenzando a abordar las vulnerabilidades que fueron divulgadas responsablemente por la comunidad de seguridad.

Si bien el protocolo de cifrado de Extremo a Extremo (E2EE) de WhatsApp protege la confidencialidad de los mensajes, sus fallos de diseño e implementación exponen los detalles del dispositivo de los usuarios (fingerprinting). Esta información proporciona a los atacantes que utilizan WhatsApp como vector de ataque datos cruciales de reconocimiento sobre las posibles víctimas.

Recientemente, WhatsApp comenzó a solucionar algunos de estos problemas de forma discreta.

Los problemas originales

Por qué es importante la huella digital. Cuando los atacantes avanzados intentan infectar el dispositivo móvil de sus víctimas con malware, WhatsApp es su principal vehículo debido a su ubicuidad.

El primer paso en una campaña cibernética es el reconocimiento. Los atacantes deben conocer el sistema operativo del dispositivo de su víctima para infectarlo con éxito. Enviar un exploit de Android a un iPhone (o viceversa) no solo es ineficaz, sino que puede alertar a las víctimas de que están siendo atacadas. Este descubrimiento puede desencadenar un efecto dominó, poniendo en peligro las vulnerabilidades Zero-Day y Zero-Click valoradas en millones de dólares de los atacantes, su infraestructura completa y su lista de objetivos.

Este fue el caso reciente en el que Citizen Lab y WhatsApp aprovecharon un exploit detectado para exponer las operaciones del grupo de spyware Paragon.

Múltiples filtraciones de privacidad en WhatsApp

A principios de 2024, se publicó en Usenix una investigación sobre los problemas de privacidad de WhatsApp y los investigadores mostraron cómo WhatsApp filtra la identidad y la cardinalidad de los dispositivos de los usuarios:

El problema principal radica en que, bajo el protocolo multidispositivo E2EE de WhatsApp, cada dispositivo del usuario receptor mantiene una sesión independiente con el dispositivo del remitente, con diferentes claves de cifrado, lo que permite su identificación.

Más tarde ese mismo año, demostraron cómo los atacantes pueden abusar de estas sesiones individuales por dispositivo para dirigir sus ataques a un dispositivo específico de su elección.

En 2025, Gabriel Karl Gegenhuber (University of Vienna) demostró que los atacantes no solo pueden conocer la identidad de los dispositivos a partir de las claves de cifrado, sino que también pueden identificarlos mediante huellas dactilares, es decir, determinar su sistema operativo (SO) exacto.

Con esta cadena de vulnerabilidades, los atacantes ahora pueden:

  • Descubrir qué dispositivo móvil usa su víctima: Android o iPhone.
  • Distribuir el exploit relevante a este dispositivo específico y no a otros dispositivos de usuario.

Todos estos problemas se comunicaron responsablemente a WhatsApp, pero no se habían abordado hasta ahora.

Lo BUENO

¡WhatsApp finalmente ha comenzado a abordar este importante problema!

Este es un cambio muy bienvenido respecto a la postura original de Meta, que no consideraba este problema de huellas digitales como un vulnerabilidad de privacidad relevante que requiriera una solución.

Lo (no tan) MALO

Los atacantes aún pueden distinguir con alta precisión entre Android y iPhone basándose en el PK ID de un solo uso.

Dado que iPhone inicializa este parámetro con un valor bajo y lo incrementa lentamente (cada pocos días), aún es muy distinguible del valor aleatorio de Android, que utiliza todo su rango de 24 bits.

Sin embargo, parece razonable creer que este es el primer paso de WhatsApp hacia una solución más completa que hará que estos campos sean aleatorios en todos los sistemas operativos y plataformas. Si este es el plan, eliminará esta vulnerabilidad de privacidad de huellas digitales.

El (algo) FEO

Parece que WhatsApp implementó esta solución de forma discreta, sin notificar a los investigadores originales de estos problemas, otorgar las recompensas correspondientes ni asignar a estas vulnerabilidades un número CVE.

En un problema de identificación de dispositivos diferente, pero similar, que se comunicó a WhatsApp. La empresa implementó una solución y otorgó una pequeña recompensa, pero no asignó un CVE por "no cumplir con el umbral de gravedad". Un CVE no debe considerarse una "marca de vergüenza", sino una herramienta para documentar y debatir adecuadamente los problemas de seguridad y privacidad.

WhatsApp de Meta está mejorando su seguridad y privacidad contra las vulnerabilidades de identificación. El trabajo de investigación realizado por la comunidad de seguridad no fue en vano. Sin embargo, creemos que WhatsApp podría ser más transparente y colaborativo, trabajando más abiertamente con la comunidad de seguridad para el bien común de sus usuarios.

Fuente: TalBerrySec

Dec 10, 2025

Vulnerabilidades críticas en Fortinet, Ivanti, SAP

Fortinet, Ivanti y SAP han tomado medidas para abordar fallas de seguridad críticas en sus productos que, de explotarse con éxito, podrían resultar en la elusión de la autenticación y la ejecución de código.

Vulnerabilidad crítica en Fortinet

Las vulnerabilidades de Fortinet afectan a FortiOS, FortiWeb, FortiProxy y FortiSwitchManager y están relacionadas con un caso de verificación incorrecta de una firma criptográfica. Se identifican como CVE-2025-59718 y CVE-2025-59719 (CVSS: 9.8). Abas vulnerabilidades permiten eludir la autenticación SSO de FortiCloud mediante mensajes SAML manipulados debido a una validación criptográfica deficiente.

"Una vulnerabilidad de verificación incorrecta de la firma criptográfica [CWE-347] en FortiOS, FortiWeb, FortiProxy y FortiSwitchManager podría permitir que un atacante no autenticado eluda la autenticación de inicio de sesión SSO de FortiCloud mediante un mensaje SAML manipulado, si dicha función está habilitada en el dispositivo", declaró Fortinet en un aviso.

Sin embargo, la compañía señaló que la función de inicio de sesión SSO de FortiCloud no está habilitada en la configuración predeterminada de fábrica. El inicio de sesión SSO de FortiCloud se habilita cuando un administrador registra el dispositivo en FortiCare y no ha desactivado la opción "Permitir inicio de sesión administrativo con FortiCloud SSO" en la página de registro.

Para proteger temporalmente sus sistemas contra ataques que explotan estas vulnerabilidades, se recomienda a las organizaciones desactivar la función de inicio de sesión de FortiCloud (si está activada) hasta que se actualice. 

Además, la empresa corrigió otras vulnerabilidades CVE-2025-59808 (CVSS 6.8), que permite restablecer contraseñas sin solicitar la contraseña actual si un atacante ya accedió a la cuenta, y CVE-2025-64471 (CVSS 7.5), que posibilita autenticarse usando un hash en lugar de la contraseña.

Las vulnerabilidades están relacionadas con SAML SSO, un mecanismo que permite iniciar sesión usando servicios en la nube. 

Si bien FortiCloud SSO está apagado por defecto, se activa automáticamente cuando el equipo se registra por primera vez, a menos que alguien lo deshabilite manualmente. El problema solo ocurre cuando la opción FortiCloud SSO está activada.

Ivanti publica corrección para falla crítica de EPM

Ivanti también ha publicado actualizaciones para abordar cuatro fallas de seguridad en Endpoint Manager (EPM), una de las cuales es un error de gravedad crítica en el núcleo de EPM y las consolas remotas. La vulnerabilidad, con el identificador CVE-2025-10573, tiene una puntuación CVSS de 9.6.

"Los XSS almacenados en Ivanti Endpoint Manager anteriores a la versión 2024 SU4 SR1 permiten que un atacante remoto no autenticado ejecute JavaScript arbitrario en el contexto de una sesión de administrador", afirmó Ivanti.

Ryan Emmons, investigador de seguridad de Rapid7, quien descubrió e informó sobre la vulnerabilidad el 15 de agosto de 2025, explicó que esta permite que un atacante con acceso no autenticado al servicio web principal de EPM conecte endpoints administrados falsos al servidor de EPM para envenenar el panel web del administrador con JavaScript malicioso.

"Cuando un administrador de Ivanti EPM accede a una de las interfaces del panel envenenadas durante el uso normal, esa interacción pasiva del usuario activa la ejecución de JavaScript del lado del cliente, lo que permite al atacante obtener el control de la sesión del administrador", explicó Emmons.

Douglas McKee, director de inteligencia de vulnerabilidades de Rapid7, declaró que la vulnerabilidad CVE-2025-10573 representa un riesgo grave, ya que su explotación es sencilla y se puede realizar enviando un informe de dispositivo falso al servidor mediante un formato de archivo básico.

"Si bien el ataque solo se ejecuta completamente cuando un administrador accede al panel de control, esta es una tarea rutinaria y necesaria para el personal de TI; por lo tanto, la probabilidad de que se active el exploit durante las operaciones normales es alta, lo que finalmente permite al atacante tomar el control de la sesión del administrador", añadió McKee.

Ensar Seker, CISO de la empresa de inteligencia de amenazas SOCRadar, también enfatizó que el requisito de interacción del usuario no reduce el nivel de amenaza de la vulnerabilidad y que tiene un potencial de explotación significativo cuando se combina con ingeniería social.

"La ejecución remota de código mediante inyección de JavaScript ya no es teórica en los ataques a la cadena de suministro; se ha vuelto operativamente viable", afirmó Seker. "Las organizaciones deben actuar con rapidez para aplicar parches y, lo que es más importante, implementar una rigurosa limpieza de la interfaz de usuario y segmentación de privilegios".

La compañía indicó que se requiere la interacción del usuario para explotar la falla y que no tiene constancia de ningún ataque activo. Esta vulnerabilidad se ha parcheado en la versión 2024 SU4 SR1 de EPM.

También se han parcheado en la misma versión otras tres vulnerabilidades de alta gravedad (CVE-2025-13659, CVE-2025-13661 y CVE-2025-13662) que podrían permitir que un atacante remoto no autenticado ejecute código arbitrario. CVE-2025-13662, al igual que CVE-2025-59718 y CVE-2025-59719, se debe a una verificación incorrecta de las firmas criptográficas en el componente de gestión de parches.

SAP corrige tres fallas críticas

Por último, SAP ha publicado actualizaciones de seguridad en diciembre para abordar 14 vulnerabilidades en varios productos, incluyendo tres fallas de gravedad crítica. Se enumeran a continuación:

  • CVE-2025-42880 (CVSS: 9,9): Vulnerabilidad de inyección de código en SAP Solution Manager
  • CVE-2025-55754 (CVSS: 9,6): Múltiples vulnerabilidades en Apache Tomcat dentro de SAP Commerce Cloud
  • CVE-2025-42928 (CVSS: 9,1): Vulnerabilidad de deserialización en SAP jConnect SDK para Sybase Adaptive Server Enterprise (ASE)

La plataforma de seguridad de SAP, Onapsis, con sede en Boston, ha sido responsable de informar sobre las vulnerabilidades CVE-2025-42880 y CVE-2025-42928. La compañía afirmó haber identificado un módulo de función remota en SAP Solution Manager que permite a un atacante autenticado inyectar código arbitrario.

"Dado el papel fundamental de SAP Solution Manager en el entorno de sistemas SAP, recomendamos encarecidamente la aplicación oportuna de un parche", declaró Thomas Fritsch, investigador de seguridad de Onapsis.

Por otro lado, CVE-2025-42928 permite la ejecución remota de código al proporcionar una entrada especialmente diseñada al componente SAP jConnect SDK. Sin embargo, una explotación exitosa requiere privilegios elevados.

Dado que las vulnerabilidades de seguridad en el software de Fortinet, Ivanti y SAP son frecuentemente explotadas por actores maliciosos, es fundamental que los usuarios actúen con rapidez para aplicar las correcciones.

Fuente: THN

Dec 3, 2025

Entra ID endurecerá su Política de Seguridad de Contenido (CSP) para bloquear ataques en el inicio de sesión

Microsoft ha revelado una actualización crítica en su política de seguridad que entrará en vigor en octubre de 2026. La compañía bloqueará la ejecución de cualquier script no autorizado durante los procesos de autenticación en Entra ID, como parte de su estrategia para erradicar vectores de ataque basados en inyección de código.

Como parte de su Iniciativa de Futuro Seguro (SFI), Microsoft ha confirmado que endurecerá su Política de Seguridad de Contenido (CSP) para las experiencias de inicio de sesión web. El objetivo principal es proteger el dominio login.microsoftonline.com asegurando que únicamente se ejecuten scripts provenientes de dominios de confianza de Microsoft o fuentes en línea verificadas por la compañía.

Esta medida, que se desplegará globalmente a mediados o finales de octubre de 2026, busca cerrar la puerta a los ataques de Cross-Site Scripting (XSS). Estos ataques aprovechan vulnerabilidades para inyectar código malicioso en sitios legítimos, comprometiendo las credenciales del usuario o secuestrando sesiones activas.

Es importante destacar que esta restricción se aplicará específicamente a los inicios de sesión realizados a través de navegadores web en el dominio principal de autenticación de Microsoft. Según la documentación técnica, los servicios de Microsoft Entra External ID no se verán afectados por este cambio en la política.

La actualización funcionará bajo un modelo de «lista blanca» estricta:

  • Solo se permitirán descargas de scripts desde redes de entrega de contenido (CDN) oficiales de Microsoft.
  • La ejecución de scripts en línea (inline) requerirá validación de origen.

Este anuncio se enmarca en el tercer informe de progreso de la SFI, publicado en noviembre de 2025. Tras un informe crítico de la Junta de Revisión de Seguridad Cibernética (CSRB) de EE.UU. en 2024, Microsoft ha acelerado sus esfuerzos para priorizar la seguridad en el diseño de sus productos.

Entre los logros recientes destacados por el gigante tecnológico se encuentran:

  • La adopción del 99,6% de autenticación multifactor (MFA) resistente al phishing en sus dispositivos y usuarios.
  • La migración masiva de la infraestructura de firma de identidad a computación confidencial en Azure.
  • La eliminación de servicios obsoletos como Active Directory Federation Services (ADFS) en sus entornos de productividad para reducir la superficie de ataque.
  • La desactivación de más de medio millón de inquilinos (tenants) y aplicaciones antiguas sin uso.

Recomendaciones para organizaciones y usuarios.

Para evitar interrupciones cuando la política entre en vigor en 2026, Microsoft aconseja tomar medidas proactivas desde ahora:

  • Auditoría de herramientas: Las organizaciones deben identificar y descartar extensiones de navegador o herramientas de terceros que modifiquen o inyecten código en la página de inicio de sesión de Entra ID.
  • Pruebas de compatibilidad: Los desarrolladores y administradores pueden verificar si sus flujos actuales violan la futura política utilizando la consola del desarrollador del navegador. Si aparecen errores indicando que «se negó la carga del script» debido a directivas script-src o nonce, es señal de que la herramienta utilizada dejará de funcionar tras la actualización.
  • Adopción de alternativas: Se recomienda migrar a soluciones que respeten la integridad del flujo de autenticación nativo de Microsoft.

Fuente: Hispasec

Nov 30, 2025

Miles de cuentas y datos personales se filtran de OpenAI y ChatGPT

Tarde o temprano tenía que ocurrir. Sam Altman avisó hace unas semanas que ChatGPT no es lugar para ir confiando los datos más privados e informaciones personales que no se deben compartir, por lo que pudiera pasar.

Pues lo que tenía que ocurrir, ya ha ocurrido: un ataque informático ha logrado traspasar las barreras de seguridad de OpenAI y han quedado expuestas miles de cuentas privadas de usuarios. Todavía están evaluando el problema para sacar cuentas de la magnitud real del hackeo.

En un comunicado emitido este jueves, OpenAI reconoce el robo de datos, aunque aclara que no se trata de una intrusión en los sistemas de ChatGPT, sino de la API, el sistema que usan los desarrolladores para integrar servicios de OpenAI en sus productos informáticos.

Para descargarse de responsabilidades, el comunicado oficial deja claro en sus primeras líneas que no les han entrado a ellos, sino que los ciberdelincuentes se han colado en los sistemas de Mixpanel, la empresa con la que colaboran para analizar la ingente cantidad de datos que generan a diario.

"No ha sido una vulneración de los sistemas de OpenAI. Ningún chat, solicitud de API, datos de uso de API, contraseñas, credenciales, claves de API, detalles de pago ni identificaciones gubernamentales se han visto comprometidos ni expuestos".

Según el escrito, "el 9 de noviembre de 2025, Mixpanel detectó que un atacante había obtenido acceso no autorizado a parte de sus sistemas y había exportado un conjunto de datos con información limitada de identificación de clientes e información analítica. Mixpanel notificó a OpenAI que estaban investigando y, el 25 de noviembre de 2025, compartió con nosotros el conjunto de datos afectado".

¿Qué datos se han filtrado?

Los usuarios de la API son, principalmente, desarrolladores y programadores informáticos, así que los usuarios que se dediquen a otras cosas no tendrían por qué preocuparse. En este caso, estos son los datos que se han filtrado:

  • Nombre del usuario de la cuenta de la API
  • Dirección de correo electrónico asociada a la cuenta API
  • Ubicación aproximada según el navegador del usuario API (ciudad, estado, país)
  • Sistema operativo y navegador utilizados para acceder a la cuenta API
  • Sitios web de referencia
  • ID de organización o usuario asociados a la cuenta API

OpenAI ha confirmado también que se ha desconectado totalmente de Mixpanel, acorde con los protocolos de investigación de la intrusión, hasta dilucidar el alcance exacto del ataque.

Fuente: La Vanguardia

Nov 29, 2025

¿Oracle víctima de Cl0p gracias a su propio producto EBS?

El jueves pasado, Oracle fue víctima de un ataque de día cero contra su propia E-Business Suite (EBS), después de que, en un momento de "atrápame si puedes", el ransomware Cl0p se atribuyera a la empresa de software y computación en la nube como parte de su última oleada de hackeos impulsada por Oracle.

La compañía apareció en el blog de filtraciones del grupo de ransomware, como si quisiera restregarle a Oracle sus propias fallas de ciberseguridad, después de que el grupo explotara su software E-Business Suite (EBS) en un ataque crítico Zero-Day, afectando a docenas de empresas hasta la fecha, y la cifra sigue aumentando.

Aun así, la publicación de la víctima proporcionaba muy poca información; simplemente enumeraba la sede y la dirección de Oracle, el número de teléfono, el sitio web, los ingresos anuales de 59 mil millones de dólares y el sector industrial. En letras rojas, Cl0p también dejó su firma, que suele encontrarse al final de cada publicación: "¡A la empresa no le importan sus clientes! ¡Ignoró su seguridad!".

Pero todo el escenario parece ser efímero. Una vez que se difundió la noticia del ataque, y para cuando se revisó el sitio web de Cl0p para verificar la publicación, la entrada de Oracle sobre la víctima no aparecía por ningún lado.

Por suerte, un analista de inteligencia Dominic Alvieri capturó la publicación de Cl0p sobre Oracle y la republicó en X. "Oracle ha sido vulnerada por el ransomware Cl0p a través de la vulnerabilidad de día cero CVE-2025-61882 de Oracle E-Business Suite".

Esta publicación faltante lleva a suponer que representantes de Oracle al menos se han puesto en contacto con el grupo, o podrían haber empezado a negociar una exigencia de rescate, aunque solo sea para que el nombre de su empresa desaparezca del sitio de la filtración y sea de conocimiento público.

Decenas de organizaciones ya han sido víctimas de la campaña de hackeo de día cero de Cl0p contra EBS, que, según los investigadores de Google, se remonta a julio. El conjunto de aplicaciones de productividad, utilizado por miles de empresas y organizaciones en todo el mundo, permite a los clientes gestionar clientes, proveedores, fabricación, logística y otros procesos empresariales.

El exploit Cl0p, que según Google encadena con éxito múltiples vulnerabilidades, incluida la de día cero CVE-2025-61882, permite la ejecución remota de código (RCE) sin autenticación en Oracle EBS, lo que permite al grupo robar grandes cantidades de datos de clientes.

Según lo informado por primera vez por Oracle el 2 de octubre, la mayoría de las empresas desconocían el día cero durante meses, lo que las dejaba vulnerables a ataques. Muchas descubrieron su vulnerabilidad en agosto, tras recibir un correo electrónico sorpresa de la banda exigiendo un rescate.

Si las víctimas ignoran el correo electrónico o deciden no pagar, Cl0p publica los datos robados para su descarga en la dark web.

Para agravar la situación de Oracle, el primer parche de emergencia lanzado por la compañía falló, lo que provocó un segundo parche crítico, dejando a los clientes expuestos al día cero durante seis días más, después de meses de exposición.

Entre las empresas de alto perfil mencionadas esta semana se encuentran el Sistema Nacional de Salud (NHS) del Reino Unido (datos publicados), Humana, Mazda, Mazda USA y la Universidad Phoenix. La ola de ataques Cl0p también afectó a The Washington Post este mes, y el diario de Washington D. C. tuvo que alertar a miles de clientes de WoPo sobre la filtración de sus datos personales.

Otras víctimas de Oracle EBS incluyen: la Universidad de Harvard; la mayor aerolínea regional de American Airlines, Envoy Air; el proveedor multinacional de servicios críticos de TI DXC Technology; y el cuarto distrito escolar más grande de EE.UU., las Escuelas Públicas de Chicago.

Mientras tanto, el cártel Cl0p, conocido por su estrategia a largo plazo, también es conocido por provocar a sus víctimas con mensajes crípticos, muchos de ellos cargados de ironía; y Oracle, obviamente, no es la excepción.

En funcionamiento desde al menos 2020, las campañas anteriores de Cl0p —explotando los programas de transferencia de archivos MOVEit, Fortra GoAnywhere, y Cleo, siendo la más reciente— han comprometido a casi 3000 importantes organizaciones, recaudando cientos de millones de dólares.

El exploit MOVEIT, ocurrido en 2023, fue una de las campañas de hacking más extensas de la historia, afectando a más de 2600 organizaciones y casi 90 millones de personas.

Fuente: Cybernews