La oleada de pruebas de concepto filtradas en torno a Windows y Microsoft Defender ha pasado de ser un problema teórico a convertirse en un riesgo operativo real. En ataques recientes se han observado intrusiones que combinan acceso inicial y acciones manuales posteriores para aprovechar técnicas conocidas como BlueHammer, RedSun y UnDefend, con un objetivo común: ganar control local elevando privilegios y, de paso, debilitar las defensas del propio sistema.

El patrón descrito encaja con intrusiones ‘hands-on-keyboard‘, donde tras conseguir una primera entrada los atacantes empiezan a ejecutar pasos interactivos para afianzar el acceso. En uno de los escenarios observados, el punto de partida fue una cuenta de usuario de SSVPN comprometida, lo que subraya la importancia de vigilar credenciales expuestas, reutilizadas o robadas y de endurecer los accesos remotos con medidas como MFA, rotación y detección de comportamientos anómalos.

De las tres técnicas, BlueHammer destaca por contar ya con un identificador formal, CVE-2026-33825, y por haber sido corregida en las actualizaciones de seguridad de abril de 2026. Se trata de un vector de elevación de privilegios que permite avanzar hacia permisos de administrador o SYSTEM, un paso crítico porque abre la puerta a acciones de alto impacto: manipular servicios, desactivar controles, persistir en el equipo o preparar movimiento lateral dentro del entorno. Además, se indica que su explotación se habría visto al menos desde el 10 de abril de 2026, por lo que no se trata de una amenaza hipotética para ‘algún día’, sino de una ventana de exposición ya en curso.

RedSun, por su parte, se describe como una elevación de privilegios local relacionada con el comportamiento de Microsoft Defender al manejar archivos detectados como maliciosos con una etiqueta de nube. El abuso se apoya en la posibilidad de forzar una reescritura hacia su ubicación original, lo que, en manos de un atacante, puede derivar en sobrescritura de archivos del sistema y culminar en ejecución con privilegios SYSTEM. El alcance es especialmente delicado porque afecta a Windows 10, Windows 11 y Windows Server 2019 y posteriores siempre que Windows Defender esté habilitado, es decir, una base instalada enorme.

La tercera técnica, UnDefend, apunta a una táctica más silenciosa pero igual de peligrosa: permitir que un usuario estándar consiga bloquear las actualizaciones de definiciones de Microsoft Defender. Si el motor antimalware deja de recibir firmas y mejoras, la detección se degrada de forma progresiva, lo que favorece la permanencia y reduce las probabilidades de que se identifique malware nuevo o variantes adaptadas.

A nivel defensivo, la prioridad inmediata pasa por aplicar el parche de abril de 2026 para CVE-2026-33825 y acelerar el ciclo de actualización allí donde haya retardos. En paralelo, conviene intensificar la caza de indicios en endpoints: cadenas de ejecución inusuales que terminen en SYSTEM, eventos compatibles con sobrescritura o cambios inesperados en archivos críticos, y señales de fallos repetidos o bloqueos anómalos al actualizar definiciones de Defender, que podrían encajar con UnDefend. Por último, reforzar el perímetro de acceso remoto –especialmente SSVPN— ayuda a cortar la fase inicial que permite que estas técnicas locales se conviertan en un incidente mayor.

Más información

• BleepingComputer – Recently leaked Windows zero-days now exploited in attacks : https://www.bleepingcomputer.com/news/security/recently-leaked-windows-zero-days-now-exploited-in-attacks/
• CVE: https://www.cve.org/CVERecord?id=CVE-2026-33825

La entrada Explotación activa de vulnerabilidades en Windows permite escalar privilegios y afectar a Defender se publicó primero en Una Al Día.

La entrada Microsoft corrige un zero-day en SharePoint y parchea 169 vulnerabilidades se publicó primero en Una Al Día.

La seguridad del software moderno ya no depende solo de proteger servidores y endpoints: también se juega en los procesos automatizados que compilan, empaquetan y publican aplicaciones. En ese contexto, un incidente en la cadena de suministro ha llevado a OpenAI a tomar una medida preventiva de alto impacto operativo: la rotación y revocación de certificados de code signing usados para distribuir software en macOS, con una fecha límite que puede afectar directamente a usuarios y a organizaciones que gestionan flotas de Macs.

El detonante fue la ejecución, el 31 de marzo de 2026, de un paquete npm comprometido identificado como Axios v1.14.1 dentro de un workflow legítimo de GitHub Actions. Ese job, además de resolver dependencias, tenía acceso a secretos especialmente sensibles: los certificados utilizados para firmar aplicaciones de OpenAI en macOS. Aunque no se ha observado evidencia de que el certificado haya sido robado o utilizado de forma indebida, la combinación de ‘código de terceros ejecutándose en CI’ y ‘material criptográfico de firma disponible’ se considera un escenario de riesgo suficiente como para actuar como si la exposición pudiera haber ocurrido.

Como consecuencia, OpenAI está rotando los certificados y revocará plenamente el anterior el 8 de mayo de 2026. En macOS, la revocación puede traducirse en un problema tangible: las protecciones de la plataforma pueden bloquear la ejecución de binarios firmados con un certificado revocado. En la práctica, esto significa que algunas versiones antiguas de aplicaciones de OpenAI podrían dejar de abrirse a partir de esa fecha, incluso aunque el software no esté alterado, simplemente por la verificación de confianza del sistema.

El cambio afecta al ecosistema de productos de OpenAI en macOS dentro del alcance del certificado anterior, incluyendo ChatGPT Desktop, Codex, Codex CLI y Atlas. En cambio, no se consideran afectados los servicios web ni las apps en iOS, Android, Windows o Linux. Tampoco se han identificado indicios de acceso a datos de usuarios, manipulación de software distribuido, compromiso de sistemas internos o exposición de propiedad intelectual. Del mismo modo, no hay señales de impacto sobre cuentas, contraseñas o API keys, un matiz importante para acotar el incidente a la superficie de CI y firma.

El episodio se enmarca en un patrón recurrente: ataques dirigidos a dependencias populares para colarse en entornos de construcción. En este caso, el paquete malicioso incorporaba una dependencia diseñada para desplegar un RAT (Remote Access Trojan) con capacidad de afectar a macOS, Windows y Linux. La campaña se ha vinculado a actores norcoreanos identificados como UNC1069, presuntamente mediante ingeniería social contra un mantenedor, un recordatorio de que la seguridad de librerías críticas también depende de proteger a las personas que las mantienen.

Para usuarios y equipos de IT, la prioridad es simple: actualizar las apps de OpenAI en macOS a versiones firmadas con el nuevo certificado antes del 8 de mayo de 2026, idealmente usando el mecanismo de actualización integrado o las páginas oficiales de descarga, evitando enlaces de terceros. Para organizaciones con MDM o gestión centralizada, conviene auditar qué versiones están desplegadas y planificar un rollout rápido para evitar interrupciones.

En paralelo, el incidente deja una lección defensiva clara para cualquier equipo con CI/CD: no conviene exponer certificados de firma o secretos de alto privilegio a jobs que ejecutan dependencias externas sin controles adicionales. Endurecer pipelines implica fijar versiones (evitar referencias ‘flotantes’), introducir verificaciones antes de ejecutar artefactos, limitar permisos por job y aplicar políticas como la ‘antigüedad mínima’ de dependencias para reducir el riesgo de que una publicación reciente y maliciosa se ejecute automáticamente. En un mundo donde la confianza se construye con criptografía y automatización, proteger el proceso de firma es tan crítico como proteger el producto final.

Más información

• BleepingComputer – OpenAI rotates macOS certs after Axios attack hit code-signing workflow : https://www.bleepingcomputer.com/news/security/openai-rotates-macos-certs-after-axios-attack-hit-code-signing-workflow/
• The Hacker News – OpenAI Revokes macOS App Certificate After Malicious Axios Supply Chain Incident: https://thehackernews.com/2026/04/openai-revokes-macos-app-certificate.html
• SC MEDIA – OpenAI’s macOS app-signing process hit by axios supply chain attack: https://www.scworld.com/news/openais-macos-app-signing-process-hit-by-axios-supply-chain-attack

La entrada OpenAI rota certificados de firma en macOS tras ejecutar Axios malicioso en su CI se publicó primero en Una Al Día.

Cuando una aplicación ofrece funciones ‘de conveniencia’ para depurar o trabajar de forma interactiva, cualquier error de control de acceso puede convertirse en una puerta directa a la máquina. En este caso, el impacto es especialmente delicado porque Marimo, como notebook reactivo en Python, suele ejecutarse cerca de código, datos y credenciales que abren la puerta a otros sistemas.

La vulnerabilidad CVE-2026-39987 permite ejecución remota de código (RCE) sin autenticación a través de un endpoint de WebSocket asociado a un terminal. En concreto, el servicio expone un terminal interactivo en la ruta /terminal/ws sin comprobaciones de autenticación adecuadas, lo que posibilita que un tercero establezca una sesión remota y obtenga una shell interactiva con los mismos privilegios que el proceso de Marimo. En la práctica, si la instancia está accesible desde Internet o desde una red compartida, un atacante puede pasar de ‘ver’ un servicio a ejecutar comandos en el sistema.

Las versiones afectadas incluyen Marimo 0.20.4 y anteriores. Tras la divulgación pública, la explotación se observó en un plazo muy corto (aproximadamente 10 horas), con actividad de reconocimiento intensa en la primera mitad del día: se registraron intentos desde más de un centenar de direcciones, lo que encaja con patrones habituales de escaneo automatizado que buscan servicios expuestos y vulnerabilidades recientes.

Una vez dentro, el valor para el atacante no es solo ejecutar comandos puntuales, sino acceder a secretos operativos. En sesiones analizadas se vio interés por robo de credenciales, incluyendo lectura de ficheros como .env y búsqueda de claves SSH. Esto es crítico porque un notebook suele convivir con variables de entorno que contienen tokens de cloud, claves de API, credenciales de bases de datos o accesos a repositorios; con esos datos, un incidente puede evolucionar rápidamente hacia movimiento lateral y compromiso de entornos más amplios. En las observaciones descritas no se apreció instalación de persistencia, ni despliegue de cryptominers o backdoors, pero eso no reduce el riesgo: el acceso interactivo ya es suficiente para extraer secretos y reutilizarlos fuera del host.

El riesgo se dispara en despliegues configurados para escuchar en todas las interfaces, por ejemplo con –host 0.0.0.0, especialmente si se utiliza el modo de edición o se ofrece el servicio como notebook editable en entornos no aislados. La corrección está disponible actualizando a Marimo 0.23.0. Además de aplicar el parche, resulta prudente rotar secretos potencialmente expuestos (tokens, credenciales y claves), revisar registros de acceso y monitorizar conexiones WebSocket hacia /terminal/ws. Si no es posible actualizar de inmediato, conviene restringir el acceso con firewall y bloquear o deshabilitar por completo el endpoint del terminal para cortar el vector de entrada.

Más información

• • BleepingComputer – Critical Marimo pre-auth RCE flaw now under active exploitation : https://www.bleepingcomputer.com/news/security/critical-marimo-pre-auth-rce-flaw-now-under-active-exploitation/
  • eSECURITY PLANET – Marimo RCE Flaw Exploited Within Hours of Disclosure : https://www.esecurityplanet.com/threats/marimo-rce-flaw-exploited-within-hours-of-disclosure/
  • CVE – CVE-2026-39987 : https://www.cve.org/CVERecord?id=CVE-2026-39987

La entrada Explotación activa de un RCE crítico en Marimo se publicó primero en Una Al Día.

Las utilidades de diagnóstico de hardware suelen considerarse ‘de bajo riesgo’ por su aparente simplicidad, pero su popularidad y el hecho de ejecutarse con frecuencia en equipos de soporte y administración las convierte en un objetivo atractivo. En este contexto, un incidente reciente afectó a CPUID: no se trató de un fallo en el motor de CPU-Z o HWMonitor en sí, sino de una manipulación de la forma en la que los usuarios obtenían los instaladores desde cpuid.com, elevando el impacto potencial al terreno de la cadena de suministro.

La intrusión se centró en una funcionalidad secundaria tipo API dentro del entorno de CPUID que permitió alterar los enlaces de descarga publicados en su web. En lugar de entregar los instaladores legítimos desde la infraestructura esperada, durante un intervalo limitado los enlaces redirigían a ejecutables maliciosos alojados en un almacenamiento externo, concretamente Cloudflare R2. La ventana de exposición se acota a unas horas entre el 9 y el 10 de abril de 2026; distintas mediciones sitúan la actividad en un rango aproximado entre el 9 de abril 15:00 UTC y el 10 de abril 10:00 UTC, con un periodo de mayor concentración de alrededor de seis horas.

Un elemento clave para entender el alcance es que los binarios originales firmados de CPUID no fueron modificados: el problema estuvo en la cadena de distribución y en los paquetes efectivamente entregados a quienes descargaron en ese intervalo. Entre las versiones afectadas se citan CPU-Z 2.19, HWMonitor 1.63, HWMonitor Pro 1.57 y PerfMonitor 2.04. Los instaladores troyanizados se construyeron combinando un ejecutable legítimo firmado con una biblioteca dinámica maliciosa llamada CRYPTBASE.dll, diseñada para ejecutarse mediante DLL sideloading. Esta técnica aprovecha cómo ciertas aplicaciones cargan DLLs desde su propio directorio o rutas previsibles, permitiendo que una DLL ‘plantada’ se cargue antes que la legítima.

Una vez cargada, CRYPTBASE.dll realiza comprobaciones de anti-sandbox para dificultar el análisis automatizado y, si el entorno parece ‘real’, establece comunicación con infraestructura de C2 (command and control) para recibir instrucciones o descargar componentes adicionales. La carga final identificada fue STX RAT, una familia con capacidades típicas de RAT e infostealer, orientada a obtener información del sistema y credenciales u otros datos útiles para el atacante. Este tipo de resultado es especialmente preocupante en equipos donde se inician sesiones de VPN, se accede a SSO, se usan gestores de contraseñas o se administran sistemas, porque un robo de credenciales puede escalar rápidamente a accesos no autorizados a servicios críticos.

El análisis técnico también apunta a solapamientos de infraestructura y configuración con campañas anteriores, incluyendo una que utilizó un sitio falso relacionado con FileZilla para distribuir descargas maliciosas. Esa reutilización sugiere un actor con ‘recetas’ de operación repetibles, capaz de adaptar el mismo patrón (web de descargas popular, empaquetado con sideloading, entrega de RAT) a distintos objetivos. Se documentaron más de 150 descargas de variantes maliciosas y se observaron víctimas en sectores como retail, manufactura, consultoría, telecomunicaciones y agricultura, con mayor concentración reportada en Brasil, Rusia y China.

Para respuesta a incidentes, lo prioritario es identificar endpoints que descargaron o instalaron las versiones afectadas durante la ventana del 9-10 de abril de 2026 y tratarlos como potencialmente comprometidos. En esos equipos conviene buscar evidencias de CRYPTBASE.dll, rastros de DLL sideloading asociados al instalador, y telemetría de red con conexiones salientes hacia infraestructura de C2 y IOCs publicados (hashes y URLs). Si hay indicios de ejecución, es recomendable aislar el equipo, recoger artefactos para análisis forense, y asumir exposición de secretos: rotar credenciales (incluidas sesiones en navegadores, tokens y accesos a herramientas corporativas), además de validar la integridad antes de reintroducir el sistema en producción. A medio plazo, el caso refuerza la necesidad de controles sobre software ‘auxiliar’: allowlisting, verificación de firmas, control del origen de instaladores y monitorización de cambios inusuales en cadenas de descarga, incluso cuando se trate de herramientas muy conocidas.

Más información

• BleepingComputer – CPUID hacked to deliver malware via CPU-Z, HWMonitor downloads : https://www.bleepingcomputer.com/news/security/supply-chain-attack-at-cpuid-pushes-malware-with-cpu-z-hwmonitor/
• Kaspersky Securelist – CPU-Z / HWMonitor watering hole infection – a copy-pasted attack : https://securelist.com/

La entrada Ataque a la cadena de suministro en CPUID distribuye instaladores troyanizados de CPU-Z y HWMonitor se publicó primero en Una Al Día.

El PDF sigue siendo uno de los formatos más aprovechados para atacar a usuarios y organizaciones porque se percibe como ‘inofensivo’, circula a diario por correo y mensajería corporativa, y suele abrirse con herramientas muy extendidas. Ese contexto es especialmente preocupante cuando el punto de entrada es un fallo no corregido públicamente en un lector tan ubicuo como Adobe Acrobat Reader, ya que reduce la fricción del ataque a un gesto rutinario: abrir un archivo.

La actividad observada gira en torno a un zero-day presuntamente sin parche confirmado y que estaría siendo explotado ‘en la naturaleza’ desde, como mínimo, diciembre. El vector es un documento PDF manipulado de forma específica, y el escenario descrito no requiere más interacción que la apertura del fichero por parte de la víctima. Además, se menciona que el ataque funciona incluso en la versión más reciente del producto, lo que apunta a un riesgo amplio en entornos donde Reader/Acrobat está instalado por defecto.

Uno de los elementos técnicos relevantes es el uso de fingerprinting para adaptar el comportamiento del exploit al entorno, una táctica habitual cuando el atacante quiere aumentar la fiabilidad y reducir fallos visibles. Tras la ejecución inicial, se ha observado robo de información local, apoyado en el abuso de APIs con privilegios dentro de Acrobat. En concreto, aparecen llamadas a util.readFileIntoStream y RSS.addFeed, que pueden emplearse para acceder a contenido del sistema y facilitar la extracción de datos. Este tipo de abuso es especialmente sensible porque combina capacidades ‘legítimas’ del software con una intención claramente maliciosa.

También hay indicios de que, tras la fase de recopilación, se podrían desplegar exploits o cargas adicionales. Esa secuencia encaja con cadenas de ataque donde primero se valida el objetivo y se extraen datos de interés, y después se intenta ampliar el control, con el riesgo potencial de ejecución remota de código (RCE) y ataques orientados a romper o eludir el sandbox (SBX). Si el encadenamiento culmina con éxito, el impacto podría escalar desde la exposición de ficheros locales hasta el control completo del equipo.

En la parte de ingeniería social, se han visto señuelos de phishing en ruso vinculados a eventos del sector de petróleo y gas en Rusia, lo que sugiere una campaña con objetivos concretos, aunque el mecanismo técnico puede reutilizarse fácilmente en otras temáticas y regiones.

Mientras se clarifica el estado de un parche, la prioridad defensiva es reducir superficie de ataque y aumentar la visibilidad. A nivel práctico, conviene endurecer el manejo de PDFs (especialmente los no solicitados), abrirlos en visores alternativos o entornos aislados cuando sea viable, y elevar la monitorización de procesos y conexiones salientes asociadas a Acrobat/Reader. Como mitigación de red específica, resulta útil vigilar o bloquear tráfico HTTP/HTTPS cuyo User-Agent contenga la cadena ‘Adobe Synchronizer’, además de alertar por uso anómalo de util.readFileIntoStream y RSS.addFeed en telemetría de endpoints. Complementariamente, reforzar controles anti-phishing y la concienciación interna reduce la probabilidad de que el primer paso –abrir el PDF– llegue a producirse.

Más información

• BleepingComputer – Hackers exploiting Acrobat Reader zero-day flaw since December : https://www.bleepingcomputer.com/news/security/hackers-exploiting-acrobat-reader-zero-day-flaw-since-december/

La entrada Adobe Acrobat Reader bajo ataque: explotan una vulnerabilidad zero-day mediante PDFs maliciosos se publicó primero en Una Al Día.

El ecosistema de WordPress vuelve a demostrar por qué los componentes de terceros, especialmente los que gestionan entrada de usuarios, son un objetivo prioritario para atacantes. Los formularios con capacidad de adjuntar ficheros son un vector especialmente atractivo: cuando un sitio permite subir documentos, imágenes o cualquier otro archivo, un fallo en la validación puede convertir una función legítima en una puerta de entrada directa al servidor.

En este caso, la vulnerabilidad CVE-2026-0740 afecta al add-on premium Ninja Forms File Uploads, una extensión asociada a Ninja Forms que añade campos de subida de archivos a formularios. El problema es crítico porque permite una subida arbitraria de archivos sin autenticación, es decir, un atacante no necesita credenciales para interactuar con el flujo vulnerable. Si la instalación está expuesta y utiliza versiones afectadas, el atacante puede intentar colar un archivo malicioso haciéndolo pasar por un adjunto permitido.

El riesgo se dispara porque el fallo no se limita a aceptar ficheros no deseados: abre la posibilidad de cargar scripts PHP y conseguir RCE al ejecutar ese archivo desde el navegador. Además, la debilidad incluye problemas de validación del destino del archivo y de sanitización del nombre, lo que facilita técnicas de path traversal para colocar el fichero en una ruta más peligrosa, potencialmente dentro del webroot. En términos prácticos, esto puede derivar en el despliegue de web shells, la modificación de contenido, la creación de cuentas persistentes o el uso del sitio como plataforma para ataques adicionales.

La severidad asignada es CVSS 9.8, coherente con una cadena de ataque que no requiere autenticación y que puede terminar en ejecución de código. La corrección completa está disponible en Ninja Forms File Uploads 3.3.27 (publicada el 19 de marzo), mientras que las versiones hasta la 3.3.26 permanecen expuestas. La actividad observada indica que no es un escenario teórico: se han detectado miles de intentos en un periodo corto, lo que encaja con campañas automatizadas que rastrean internet en busca de sitios vulnerables.

La respuesta defensiva debe priorizar la actualización inmediata a 3.3.27 o superior. En paralelo, conviene revisar el servidor en busca de archivos PHP inesperados y artefactos recientes en rutas accesibles desde la web, especialmente en directorios de subidas. Si existen indicios de compromiso, es prudente rotar credenciales y claves asociadas al sitio y comprobar integridad de ficheros. Como mitigación adicional, resulta recomendable reforzar el perímetro con reglas de WAF/Firewall que bloqueen patrones de subida no autorizada y de path traversal, y, cuando sea viable, configurar el servidor para impedir la ejecución de PHP en directorios de subida como uploads. Estas medidas no sustituyen el parche, pero pueden reducir de forma significativa la ventana de exposición en entornos donde la actualización no sea inmediata.

Más información

• BleepingComputer – Hackers exploit critical flaw in Ninja Forms WordPress plugin : https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-flaw-in-ninja-forms-wordpress-plugin/

La entrada Explotación activa de CVE-2026-0740 en Ninja Forms File Uploads pone en riesgo miles de WordPress se publicó primero en Una Al Día.

Flowise se ha popularizado como una pieza práctica para equipos que quieren montar rápidamente workflows y aplicaciones con LLM y agentes, a menudo integrándolo en laboratorios, entornos internos o incluso despliegues accesibles desde fuera para facilitar pruebas y demostraciones. Ese patrón –herramientas de orquestación de IA desplegadas con prisas y con poca fricción– convierte cualquier fallo crítico en un problema inmediato: un servicio que controla conexiones, credenciales y llamadas a sistemas externos puede pasar de ser un acelerador de productividad a una puerta de entrada.

En ese contexto, se ha detectado explotación real de CVE-2025-59528, una vulnerabilidad de severidad máxima (CVSS 10) que afecta a Flowise y permite llegar a RCE mediante inyección de JavaScript. El punto especialmente delicado es el nodo CustomMCP: el tratamiento de la configuración mcpServerConfig puede evaluarse de forma insegura cuando proviene de entrada controlada por el usuario. En la práctica, esto abre la posibilidad de ejecutar código arbitrario en el servidor que aloja Flowise, con capacidad potencial para lanzar comandos y acceder al sistema de archivos.

La actividad observada en ataques parece, por el momento, limitada y concentrada, pero el riesgo operativo no depende del volumen: basta un único actor automatizando búsquedas de servicios expuestos para comprometer instancias sin parchear. Además, el impacto puede ser especialmente alto en entornos donde Flowise esté conectado a recursos internos (por ejemplo, repositorios, almacenes de secretos, bases de datos o herramientas de despliegue), porque una RCE puede convertirse rápidamente en movimiento lateral o robo de información.

El problema se agrava por la superficie expuesta: se estima que hay entre 12.000 y 15.000 instancias de Flowise accesibles desde Internet, sin que esté claro cuántas siguen en versiones vulnerables. En paralelo, también se menciona explotación activa asociada a CVE-2025-8943 y CVE-2025-26319, lo que refuerza la necesidad de tratar Flowise como un componente de alto riesgo cuando está publicado.

La corrección para CVE-2025-59528 está disponible desde Flowise 3.0.6, y la recomendación más segura es actualizar a Flowise 3.1.1. A nivel defensivo, conviene priorizar un inventario rápido de instancias, validar versión y estado de parcheado, y retirar de la exposición pública aquellas que no necesiten acceso externo. Como medidas complementarias, es razonable reforzar la monitorización en host y perímetro en busca de señales compatibles con ejecución de comandos, lecturas/escrituras anómalas en disco y procesos inusuales asociados al servicio, especialmente en servidores donde Flowise conviva con otros componentes críticos.

Más información

• BleepingComputer – Max severity Flowise RCE vulnerability now exploited in attacks : https://www.bleepingcomputer.com/news/security/max-severity-flowise-rce-vulnerability-now-exploited-in-attacks/amp/

La entrada Explotación activa de una RCE crítica en Flowise pone en riesgo instancias expuestas se publicó primero en Una Al Día.

El aumento de campañas que explotan el inicio de sesión mediante código de dispositivo refleja un cambio importante en el phishing: ya no siempre se persigue la contraseña, sino la autorización y los tokens que sostienen una sesión moderna en servicios SaaS. Esta técnica se apoya en un mecanismo legítimo, el OAuth 2.0 Device Authorization Grant (conocido como Device Code Flow), pensado para situaciones en las que el dispositivo o la aplicación que solicita acceso no puede mostrar un navegador completo, como ciertas CLI, equipos con entrada limitada o flujos de incorporación en entornos corporativos.

El patrón del ataque es especialmente eficaz porque utiliza páginas reales del proveedor. La víctima recibe un mensaje (correo, chat o notificación) con una instrucción urgente y un código. El texto la guía para abrir un portal legítimo de ‘device login’ e introducir el user_code. En apariencia, el usuario está iniciando sesión ‘de forma segura’ en un sitio auténtico; el truco es que en realidad está autorizando una sesión iniciada por el atacante en un dispositivo o aplicación bajo su control. Una vez completada la autorización, el sistema emite access tokens para acceder a recursos, y si se solicita el permiso offline_access, también refresh tokens que permiten mantener el acceso y renovar la sesión sin pedir credenciales de nuevo.

Esa persistencia es una de las razones por las que el impacto puede ser mayor de lo que muchos esperan. En entornos como Microsoft Entra ID y Microsoft 365, la obtención de tokens puede traducirse en acceso inmediato a correo, archivos o aplicaciones internas, y el control puede sobrevivir a un cambio de contraseña si no se revocan sesiones y tokens de forma adecuada. Además, en la práctica, el flujo puede ‘parecer’ compatible con MFA a ojos del usuario, porque la interacción ocurre en un dominio legítimo y el paso de verificación no suena a phishing tradicional.

El crecimiento de aproximadamente 37,5x en páginas y kits relacionados con este tipo de fraude durante 2026 se ha visto impulsado por la industrialización del modelo: kits de phishing-as-a-service (PhaaS) como EvilTokens y otras familias con señuelos realistas orientados a SaaS. Se han identificado múltiples plantillas y variantes con temáticas habituales en empresas, incluyendo lures que imitan flujos de DocuSign, Adobe, SharePoint, Teams o Citrix ShareFile, además de nombres de kits como VENOM, SHAREFILE, CLURE, LINKID, AUTHOV, DOCUPOLL, FLOW_TOKEN, PAPRIKA, DCSTATUS y DOLCE. A esto se suma el uso de alojamiento en servicios cloud y plataformas de edge hosting para desplegar infraestructura con rapidez y rotación, incluyendo workers.dev, GitHub Pages, AWS S3, DigitalOcean y Microsoft PowerApps.

La defensa pasa por tratar el Device Code Flow como una capacidad de alto riesgo: bloquearlo o restringirlo donde no sea imprescindible, y hacerlo primero en modo auditoría (por ejemplo, report-only) para localizar dependencias legítimas antes de aplicar una prohibición completa. También es clave reforzar la detección en telemetría de autenticación: alertar cuando aparezcan eventos de inicio por device code en usuarios que no lo usan, cuando la IP o la geografía resulten anómalas, o cuando haya discrepancias entre la autorización del código y la actividad posterior. En caso de sospecha, la respuesta no debe limitarse a resetear contraseñas: conviene revocar sesiones activas y forzar la invalidación de refresh tokens cuando la plataforma lo permita, además de revisar consentimientos y accesos a aplicaciones que puedan facilitar nuevos abusos. Por último, la concienciación debe ser muy concreta: ningún usuario debería introducir un código de ‘device login’ recibido por correo o chat salvo en procesos internos verificados y documentados.

Más información

• BleepingComputer – Device code phishing attacks surge 37x as new kits spread online : https://www.bleepingcomputer.com/news/security/device-code-phishing-attacks-surge-37x-as-new-kits-spread-online/

La entrada El ‘device code phishing’ se dispara: 37 veces más campañas y nuevos kits para robar tokens OAuth se publicó primero en Una Al Día.

El ecosistema de aplicaciones modernas basadas en Node.js, Next.js y React suele concentrar en el runtime una cantidad significativa de secretos operativos: desde API tokens para servicios externos hasta credenciales de bases de datos, accesos a cloud y claves usadas por automatizaciones. Esa realidad convierte a los fallos que permiten ejecutar código en el servidor en una vía especialmente rentable para atacantes: no buscan solo tumbar servicios, sino convertir el servidor en una aspiradora de credenciales con impacto inmediato en cuentas, datos y facturación.

En ese contexto, una campaña activa está abusando de React2Shell (CVE-2025-55182) para conseguir Remote Code Execution (RCE) sin autenticación contra aplicaciones Next.js vulnerables, en particular escenarios ligados a React Server Components (RSC) y Server Functions expuestas. El vector se apoya en el procesamiento de payloads enviados a endpoints del lado servidor, donde el manejo inseguro permite encadenar la ejecución de comandos dentro del proceso Node.js que atiende la aplicación. Una vez obtenido el control, el objetivo no se limita a la persistencia: el foco principal es el robo sistemático de secretos y material de acceso.

La operativa observada destaca por su automatización. En un intervalo de 24 horas se identificaron al menos 766 hosts comprometidos, repartidos entre distintas regiones y proveedores. Tras la intrusión, se ejecutan scripts lanzados con nohup, habitualmente desde /tmp y con nombres aleatorios u ocultos, para mantener la recolección en segundo plano y por fases. Esa ejecución por etapas facilita que el atacante vaya ampliando el inventario de credenciales: primero obtiene información básica del sistema y variables relevantes, después profundiza en llaves, tokens y configuraciones, y finalmente empaqueta y envía los hallazgos.

La extracción incluye variables de entorno y secretos de runtime donde suelen vivir credenciales de PostgreSQL/MySQL, claves de servicios externos y tokens de desarrollo como GitHub o GitLab. También se buscan y copian claves privadas SSH (formatos ED25519 y RSA) y ficheros como authorized_keys, lo que abre la puerta a movimiento lateral hacia otros servidores si existe reutilización de claves o confianza implícita entre máquinas. En entornos con contenedores, se intenta enumerar configuraciones de Docker y, cuando hay orquestación, se prueban rutas habituales para obtener Kubernetes service account tokens, con el riesgo de escalar desde un pod a recursos del clúster si los permisos están sobredimensionados.

Una parte especialmente crítica es el robo de credenciales cloud mediante consultas a APIs de metadatos en AWS, GCP y Azure. En el caso de AWS, el abuso de Instance Metadata Service (IMDS) puede proporcionar credenciales temporales asociadas a IAM roles, suficientes para listar recursos, extraer datos o incluso modificar infraestructura si el rol no sigue el principio de mínimo privilegio. En paralelo, se han visto intentos de localizar secretos de terceros de alto impacto económico, como claves en vivo de Stripe (patrones sk_live_), además de credenciales para plataformas de correo y mensajería como SendGrid o bots de Telegram, y tokens de servicios de IA como OpenAI o Anthropic*, que pueden derivar en fraude, abuso de cuota o exposición de datos.

La exfiltración se realiza mediante peticiones HTTP hacia infraestructura de C2, con tráfico que con frecuencia aparece por el puerto 8080 y con identificadores que reflejan el host y la fase de recolección. La campaña se apoya en un framework con interfaz web denominado NEXUS Listener, asociado a un clúster rastreado como UAT-10608, diseñado para gestionar en volumen la captura de secretos y su clasificación.

La implicación práctica es clara: si una app expuesta era vulnerable, no basta con parchear. Cualquier token, API key, credencial de base de datos, clave SSH o secreto accesible desde el proceso comprometido debe tratarse como filtrado. La respuesta debe combinar actualización o mitigación de CVE-2025-55182, rotación inmediata de credenciales, revisión de authorized_keys, endurecimiento de metadatos (por ejemplo, forzar IMDSv2 en EC2), auditoría de permisos IAM y RBAC en Kubernetes, y vigilancia de indicadores como ejecuciones anómalas desde /tmp, procesos persistentes con nohup y conexiones salientes inusuales hacia destinos externos.

Más información

• BleepingComputer – Hackers exploit React2Shell in automated credential theft campaign
  https://www.bleepingcomputer.com/news/security/hackers-exploit-react2shell-in-automated-credential-theft-campaign/
• Cisco Talos – UAT-10608: Inside a large-scale automated credential harvesting operation targeting web applications
  https://blog.talosintelligence.com/uat-10608-inside-a-large-scale-automated-credential-harvesting-operation-targeting-web-applications/

La entrada React2Shell (CVE-2025-55182) se explota para robar secretos en masa en apps Next.js se publicó primero en Una Al Día.