Un defecto de seguridad en snap-confine, una pieza interna de snapd, deja la puerta abierta a una escalada local de privilegios hasta root en equipos con Ubuntu Desktop. El fallo, registrado como CVE-2026-8933 y catalogado con severidad alta, afecta de forma directa a instalaciones por defecto de Ubuntu Desktop 24.04, 25.10 y 26.04, un escenario común en portátiles corporativos, puestos de desarrolladores y estaciones de administración.

La debilidad no permite entrar desde Internet por sí sola. Exige presencia local previa, o que el atacante ya ejecute código con permisos de usuario. El problema es lo que ocurre después: esa intrusión limitada puede convertirse en control total del sistema. En la métrica CVSS, el fallo figura con 7.8 y un vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, lo que resume un riesgo alto en confidencialidad, integridad y disponibilidad una vez el atacante está dentro.

El origen se relaciona con un cambio de endurecimiento que sustituyó el modelo tradicional setuid root por otro basado en Linux capabilities. Ese rediseño reducía superficie de ataque en teoría, pero abrió una ventana delicada durante la inicialización del sandbox. La explotación se apoya en condiciones de carrera durante la creación de directorios y ficheros temporales en /tmp, combinando un montaje FUSE y enlaces simbólicos para redirigir escrituras hacia rutas sensibles.

Entre las técnicas descritas aparece una vía para sortear el confinamiento con AppArmor: dejar una regla udev maliciosa en /run/udev/rules.d/ y forzar que systemd-udevd ejecute comandos como root. Ese tipo de encadenado ilustra el riesgo real en endpoints, donde basta un primer paso, por ejemplo un binario no confiable ejecutado por un usuario, para terminar con un host completamente comprometido.

La corrección upstream llega con snapd 2.76.1. En Ubuntu, los paquetes corregidos incluyen 2.76+ubuntu22.04.1, 2.76+ubuntu24.04.1 y 2.76+ubuntu26.04.3, además de versiones bajo ESM para Ubuntu 16.04, 18.04 y 20.04. La recomendación práctica es doble: actualizar snapd cuanto antes y verificar versión equipo a equipo, sin dar por hecho que una actualización anterior o la antigüedad del sistema bastan para estar a salvo. En organizaciones, el despliegue debería priorizar estaciones de trabajo, equipos de desarrollo y cualquier endpoint con más probabilidad de ejecutar software con permisos de usuario.

Más allá del parche, conviene apretar el perímetro interno. Reducir la ejecución de binarios no confiables, reforzar controles de acceso local y mantener una buena higiene de hardening, con AppArmor activo y actualizaciones al día, ayuda a acotar el margen de maniobra que explotan este tipo de fallos locales.

Más información

• The Hacker News – Ubuntu snap-confine Flaw Could Give Local Users Root on Default Desktop Installs : https://thehackernews.com/2026/07/ubuntu-snap-confine-flaw-could-give.html
• NVD (NIST) – CVE-2026-8933 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-8933
• Infosecurity Magazine – Ubuntu snap-confine Vulnerability Enables Local Root Access : https://www.infosecurity-magazine.com/news/ubuntu-snap-confine-local-root-cve/
• oss-sec (seclists.org) – LPE in snapd and other vulnerabilities : https://seclists.org/oss-sec/2026/q3/191

La entrada Un fallo en snap-confine permite obtener root en Ubuntu Desktop con acceso local se publicó primero en Una Al Día.

Administradores de sitios con WordPress en versiones recientes se enfrentan estos días a una amenaza directa: una cadena de fallos críticos, conocida como wp2shell, permite tomar el control del servidor sin necesidad de credenciales y ya se utiliza en ataques reales para desplegar webshells y plugins maliciosos. El riesgo se concentra en instalaciones de WordPress Core 7.0.x anteriores a 7.0.2 y 6.9.x anteriores a 6.9.5, aunque también existe rama corregida en 6.8.6.

La clave técnica está en la API REST de WordPress y, en concreto, en su mecanismo de batch processing. Los atacantes encadenan dos vulnerabilidades, CVE-2026-63030 y CVE-2026-60137, para pasar de peticiones aparentemente legítimas a un escenario de RCE sin autenticación. La primera se apoya en una confusión de rutas en el endpoint de procesamiento por lotes; la segunda explota una inyección SQL en WP_Query vinculada al parámetro author__not_in. Juntas abren la puerta a escalar desde consultas manipuladas hasta ejecución de código en el servidor.

Los indicadores observados encajan con campañas automatizadas: escaneo masivo de instancias, consultas a la API REST para enumerar posibles administradores y recopilación de nombres de usuario y correos. En paralelo, aparecen intentos de inclusión local de ficheros orientados a leer wp-config.php y extraer credenciales de base de datos y claves de autenticación.

Cuando el ataque cuaja, el objetivo habitual consiste en dejar persistencia. Se han visto webshells PHP creadas en rutas como wp-content/cache, con nombres aleatorios y un mecanismo de acceso que devuelve un falso 404 si no se incluye el parámetro esperado. En algunas intrusiones, los atacantes también crean cuentas de administrador fraudulentas o añaden plugins que facilitan el control remoto.

La mitigación prioritaria pasa por actualizar ya a WordPress 7.0.2, 6.9.5 o 6.8.6, según la rama instalada, y comprobar que las actualizaciones automáticas de seguridad se han aplicado. A partir de ahí, conviene revisar logs de acceso y de aplicación en busca de peticiones anómalas hacia la API REST y sus endpoints de batch, inspeccionar los plugins instalados y eliminar cualquier alta reciente sin justificación operativa.

También resulta recomendable buscar ficheros PHP nuevos en ubicaciones inusuales dentro de wp-content, auditar usuarios con permisos elevados y borrar cuentas no autorizadas. Si existen indicios de acceso a wp-config.php, toca rotar credenciales de base de datos y claves, además de las contraseñas del panel. Si se confirma compromiso, la respuesta debe ser más contundente: contención, reinstalación desde una copia limpia y rotación completa de secretos para cortar la persistencia.

Más información

• BleepingComputer – Critical wp2shell WordPress flaws exploited to install webshells : https://www.bleepingcomputer.com/news/security/critical-wp2shell-wordpress-flaws-exploited-to-install-webshells/
• NVD (NIST) – CVE-2026-63030 : https://nvd.nist.gov/vuln/detail/CVE-2026-63030

La entrada Una cadena crítica en WordPress facilita la instalación de webshells sin contraseña se publicó primero en Una Al Día.

La campaña FakeGit ha convertido GitHub en un escaparate masivo de repositorios señuelo con un objetivo claro: empujar a usuarios y organizaciones a descargar e instalar SmartLoader, un loader que abre la puerta a implantes posteriores, incluido el ladrón de información StealC. La operación, activa al menos hasta julio de 2026, destaca por su escala, se habla de cerca de 7.600 repositorios creados o reutilizados con fines maliciosos, y por un cambio de guion que mezcla desarrollo, automatización y agentes de IA.

El truco no se limita a subir código sospechoso. Los atacantes copian proyectos reales, clonan estructuras y documentación, y montan perfiles de desarrollador que imitan identidades legítimas. El resultado son repositorios con README verosímiles que guían al visitante hacia la descarga de un ZIP desde GitHub Releases, un canal que muchos equipos tratan como ‘más confiable’ por su apariencia de entrega oficial. En alrededor de 200 repositorios de la campaña, esos assets han acumulado más de 14 millones de descargas, una cifra que ayuda a entender el alcance del problema.

Una parte especialmente delicada se camufla como utilidades relacionadas con IA, con más de 800 repositorios que se presentan como Skills o como servidores MCP (siglas de Model Context Protocol). Aquí entra en juego la táctica bautizada como AgentBaiting: el atacante no necesita enviar un enlace directo. Basta con provocar que un agente busque ‘una Skill gratuita’ o ‘un servidor MCP’ y, a partir de ahí, siga instrucciones de instalación que acaban ejecutando código. Se han observado pruebas internas en Anthropic Claude Code, Google Gemini y OpenAI ChatGPT en las que estos sistemas pueden devolver repositorios maliciosos durante el descubrimiento.

En la cadena de infección descrita, el ZIP inicia una carga por etapas que pasa por LuaJIT y termina ejecutando un script Lua ofuscado que instala SmartLoader. A partir de ahí, el loader se encarga de mantener persistencia y desplegar cargas secundarias. Se han visto técnicas típicas en Windows, como la persistencia mediante tareas programadas, y también un elemento más inusual: la resolución dinámica de infraestructura de mando y control mediante un dead drop apoyado en blockchain, con referencias a un contrato inteligente en Polygon.

La exposición crece cuando estas supuestas Skills o servidores MCP aparecen en registros públicos como LobeHub, Glama, MCP.so y MCP Market. Se han señalado más de 600 listados vinculados a la campaña en este tipo de directorios, lo que amplía el alcance más allá de GitHub y complica la higiene del descubrimiento automático.

Para mitigar el riesgo, las organizaciones empiezan por lo básico: no ejecutar ZIP, scripts o instaladores de repositorios no verificados, aunque la documentación parezca impecable. Ayuda crear un catálogo interno de Skills, servidores MCP y plugins aprobados, con responsables claros, y validar cualquier nueva capacidad de agente en un entorno aislado antes de llevarla a producción. En estaciones de trabajo conviene aplicar control de aplicaciones para bloquear intérpretes y scripts no autorizados, endurecer políticas en Windows, y restringir la ejecución desde rutas de escritura de usuario como Descargas o %TEMP%.

En paralelo, la defensa técnica pasa por reforzar EDR con reglas centradas en ejecución de LuaJIT, patrones de loaders y señales de exfiltración, además de correlacionar eventos con descargas desde GitHub Releases. En entornos Windows también resulta clave vigilar rutas de persistencia, especialmente la creación de tareas programadas desde directorios de usuario, y revisar tráfico saliente anómalo, incluidos accesos a endpoints RPC ligados a Polygon o comunicaciones con IP sin dominio, como peticiones POST a una IP desnuda. Y, sobre todo, formar a equipos de desarrollo y a quienes operan agentes de IA: la cadena de suministro ya no se rompe solo en una librería, también en un repositorio ‘útil’ que alguien, o algo, instala sin mirar dos veces.

Más información

• The Hacker News – FakeGit Campaign Uses 7,600 GitHub Repositories to Spread SmartLoader Malware : https://thehackernews.com/2026/07/fakegit-campaign-uses-7600-github.html
• Jamaica Cyber Incident Response Team (JaCIRT) – Fake GitHub Repositories Distribute SmartLoader and StealC Malware via Deceptive Open-Source Clones : https://cirt.gov.jm/advisory/fake-github-repositories-distribute-smartloader-and-stealc-malware-deceptive-open-source

La entrada La campaña FakeGit inunda GitHub con 7.600 repositorios trampa para distribuir SmartLoader se publicó primero en Una Al Día.

Hugging Face ha confirmado una intrusión en parte de su infraestructura de producción que permitió a un atacante ejecutar código dentro del canal de procesado de datasets, escalar privilegios y moverse por varios clústeres internos durante un fin de semana. El incidente, que la empresa atribuye a un sistema de agente autónomo, acabó con acceso no autorizado a un conjunto limitado de datasets internos y a varias credenciales usadas por servicios de la plataforma.

El punto de entrada no fue un modelo, sino los datos. Un dataset malicioso activó dos vías distintas para lograr ejecución de código en el pipeline: un loader de datasets que permitía ejecutar código de forma remota y un vector de inyección de plantilla en la configuración del propio dataset. A partir de ahí, el atacante elevó el nivel de acceso hasta el nodo, recopiló credenciales de nube y del clúster, y realizó movimiento lateral entre entornos internos.

Hugging Face sostiene que no ha encontrado evidencias de manipulación de modelos, datasets o Spaces públicos orientados a usuarios, ni señales de alteración en imágenes de contenedores o paquetes publicados. Queda por determinar si el acceso alcanzó información de partners o clientes; la compañía mantiene el compromiso de avisar de forma directa si confirma afectación.

La respuesta combinó contención y limpieza: se cerraron las rutas de ejecución de código utilizadas en el acceso inicial, se reconstruyeron los nodos comprometidos, y se revocaron y rotaron credenciales y tokens. También se endurecieron los controles de admisión en los clústeres para reducir la probabilidad de que artefactos similares vuelvan a colarse por el pipeline.

El análisis forense añadió un matiz llamativo. El equipo procesó más de 17.000 eventos del atacante con agentes de análisis basados en LLM para reconstruir la cronología, extraer indicadores y localizar credenciales afectadas. La investigación, además, terminó con un modelo open weight ejecutado en infraestructura propia, después de que modelos comerciales bloquearan parte del trabajo por sus salvaguardas al manejar comandos y artefactos reales de ataque.

Para usuarios y empresas, la recomendación práctica es inmediata: rotar los tokens de acceso de Hugging Face, sobre todo los integrados en CI/CD, automatizaciones o integraciones, y revisar el historial reciente en busca de usos inesperados. También conviene inventariar secretos que dependan de esos tokens, desde variables de entorno hasta gestores de secretos y credenciales incrustadas en repositorios y pipelines, y aplicar mínimo privilegio para limitar el alcance del daño si algo se filtra.

El caso deja una lección incómoda para el ecosistema de IA: la superficie de ataque no acaba en el modelo. Los pipelines de datos y el procesado de datasets se han convertido en una pieza crítica, y cualquier atajo que permita ejecutar código o interpretar plantillas puede convertirse en una autopista hacia credenciales y sistemas internos. Reforzar validaciones, monitorizar el uso de tokens con alertas por patrones anómalos y preparar capacidad de forense asistida por IA en entorno propio ya no suena a lujo, sino a medida defensiva razonable.

Más información

• The Hacker News – World’s Largest AI Model Repository Hugging Face Breached by Autonomous AI Agent : https://thehackernews.com/2026/07/worlds-largest-ai-model-repository.html
• Hugging Face – Security incident disclosure — July 2026 : https://huggingface.co/blog/security-incident-july-2026
• TechRepublic – Hugging Face Says Autonomous AI System Executed Multi-Stage Cyberattack : https://www.techrepublic.com/article/news-hugging-face-ai-agent-cyberattack-production-systems/

La entrada Hugging Face confirma una intrusión en producción y pide rotar tokens tras un ataque con un agente autónomo se publicó primero en Una Al Día.

SonicWall ha activado el modo emergencia tras detectar intrusiones reales que aprovechan dos vulnerabilidades zero-day en la serie SonicWall SMA1000, un tipo de appliance que suele vivir en el perímetro y da acceso remoto a redes corporativas. El problema no se queda en una prueba de concepto: la explotación ya está en marcha y eleva el riesgo para cualquier organización con estos equipos expuestos a Internet.

La primera vulnerabilidad, CVE-2026-15409, alcanza un CVSS 10.0 y encaja en el patrón más temido en dispositivos perimetrales: una SSRF sin autenticación en la interfaz SMA1000 Appliance Work Place. En la práctica, permite que un atacante remoto fuerce al appliance a realizar peticiones hacia destinos no previstos, un punto de apoyo habitual para pivotar hacia servicios internos o encadenar pasos posteriores.

La segunda, CVE-2026-15410, baja a CVSS 7.2 pero no es menor en consecuencias. Afecta a SMA1000 Appliance Management Console y permite inyección de código tras autenticación, con capacidad para que un administrador autenticado ejecute comandos del sistema operativo. En ataques avanzados, este tipo de fallo se usa para consolidar el control, abrir persistencia o manipular la configuración del equipo.

Los modelos citados como afectados incluyen SMA6210, SMA7210 y SMA8200v. Entre las versiones vulnerables aparecen platform hotfix 12.4.3-03245, 12.4.3-03387, 12.4.3-03434, 12.5.0-02283, 12.5.0-02624 y 12.5.0-02800. SonicWall ya ofrece versiones corregidas, con los hotfix 12.4.3-03453 y 12.5.0-02835, además de posteriores. La compañía no contempla mitigaciones equivalentes que sustituyan a instalar estas correcciones.

El escenario se complica porque se han observado ataques que podrían encadenar ambos fallos, aunque no todas las fuentes lo dan aún por confirmado. Aun así, el mensaje operativo no cambia: parchear no basta si existe la sospecha de acceso previo. Los indicadores de compromiso incluyen peticiones en extraweb_access.log a /api/login o /api/logout con HTTP 200, llamadas a /wsproxy con parámetros host sospechosos con HTTP 101, posibles rollbacks de hotfix con nombres vinculados a traversal en ctrl-service.log, y rutas anómalas para /api/login o /api/logout en /var/lib/unit/conf.json.

En paralelo, CISA ya ha añadido CVE-2026-15409 y CVE-2026-15410 al catálogo Known Exploited Vulnerabilities, con una fecha límite clara: el 17 de julio de 2026 para que las agencias federales aseguren los sistemas afectados o los retiren si no pueden aplicar la corrección. Conviene subrayar también lo que no entra en el alcance: los fallos no afectan al SSL VPN de los firewalls SonicWall ni a la línea SonicWall SMA 100 Series.

Para las organizaciones, la lista de tareas es directa y urgente: actualizar de inmediato a 12.4.3-03453 o 12.5.0-02835 en cualquier SMA1000 accesible desde Internet, inventariar equipos SMA6210, SMA7210 y SMA8200v y priorizar los que tengan más exposición administrativa. Después toca revisar logs y configuración en busca de IOCs y preservar evidencias si se necesita análisis forense. Si aparecen señales de intrusión, la recomendación pasa por reimaginar appliances físicos o redesplegar los virtuales antes de volver a producción, rotar contraseñas de usuarios y administradores, y restablecer tokens TOTP.

Como medida de contención, muchas empresas optarán por aislar temporalmente el appliance del plano de gestión y restringir el acceso administrativo a redes de administración y bastiones. También conviene validar que nadie ha aplicado rollbacks no autorizados y bloquear los downgrades salvo bajo control de cambios formal. En la monitorización, merece la pena añadir detecciones específicas para /wsproxy con parámetros host anómalos y para accesos a /api/login y /api/logout, ya que esos rastros aparecen entre los patrones más útiles para identificar actividad maliciosa en estos equipos.

Más información

• BleepingComputer – SonicWall warns of SMA1000 flaws exploited in zero-day attacks, patch now : https://www.bleepingcomputer.com/news/security/sonicwall-warns-of-sma1000-flaws-exploited-in-zero-day-attacks-patch-now/
• Help Net Security – SonicWall SMA appliances targeted in zero-day attacks (CVE-2026-15409, CVE-2026-15410) : https://www.helpnetsecurity.com/2026/07/14/sonicwall-sma-attacks-via-cve-2026-15409-cve-2026-15410/
• The Hacker News – Two SonicWall SMA 1000 Zero-Days Exploited, One Could Enable Admin Commands : https://thehackernews.com/

La entrada SonicWall publica hotfixes tras detectar ataques reales contra dos zero-days en SMA1000 se publicó primero en Una Al Día.

El problema no está en un bug exótico del kernel ni en una cadena de exploits sofisticada, sino en algo más incómodo: binarios viejos que siguen siendo válidos por la firma que llevan. Un total de once UEFI shim antiguos, en versiones 0.9 o anteriores, pueden usarse para saltarse UEFI Secure Boot en sistemas cuyo firmware todavía confía en el certificado Microsoft Corporation UEFI CA 2011. El riesgo aparece cuando un atacante consigue colocar uno de esos shims vulnerables en la ruta de arranque y logra ejecutar código antes de que arranque el sistema operativo.

La técnica se parece a un BYOVD llevado a la fase pre OS: en vez de ‘traer tu propio driver vulnerable’, el atacante aporta un cargador vulnerable pero correctamente firmado. Eso cambia la lógica de defensa. No hace falta que el equipo tenga instalado el software original que incluyó ese shim, basta con que el firmware acepte la firma y el atacante pueda modificar el proceso de arranque, por ejemplo tocando el disco, una partición EFI o un medio de arranque.

El alcance es especialmente delicado porque el código se ejecuta antes del SO. Ahí resulta más fácil lograr persistencia, desplegar un bootkit UEFI o colar componentes maliciosos que acaben en el kernel. También se reduce la visibilidad: parte de la telemetría típica de un EDR empieza a funcionar cuando el sistema ya está en marcha, no cuando el firmware decide qué binario considera ‘de confianza’.

Las referencias públicas reparten el conjunto de shims entre varias entradas, con CVE-2026-8863 y CVE-2026-10797 cubriendo distintas porciones del problema. En la lista aparecen implementaciones asociadas a Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE, y también herramientas de terceros como baramundi Management Suite hasta 2024R1, WipeDrive 8.0.0 a 8.1.3, PC Doctor Service Center o Abitti 1.

La mitigación principal ya está encima de la mesa: revocar esos shims mediante actualizaciones de la lista DBX de Microsoft. Tras aplicar la revocación, el firmware deja de considerarlos válidos durante el arranque, aunque estén firmados. Esto también aclara una confusión habitual: la caducidad del certificado Microsoft UEFI CA 2011, fechada el 27 de junio de 2026, no invalida automáticamente los binarios firmados en el pasado. Mientras el certificado siga presente en la base DB y el hash no entre en DBX, el arranque puede aceptarlos.

Aquí viene la parte delicada para administradores: tocar DBX puede dejar equipos sin arrancar si conviven componentes antiguos. La receta prudente pasa por actualizar primero shim, GRUB y el resto de piezas de la cadena de arranque a versiones actuales con protecciones SBAT, y después desplegar las revocaciones. Conviene probar antes en un subconjunto representativo, verificar el estado final de DBX con utilidades como Check UEFISecureBootVariables en Windows o uefi dbx audit en Linux, e inventariar medios de rescate y USB de mantenimiento. Si esos soportes usan shims antiguos, pueden quedar inservibles justo cuando más falta hacen.

Más información

• The Hacker News – 11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot : https://thehackernews.com/2026/07/11-old-microsoft-signed-linux.html
• CERT Coordination Center – VU#616257: Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass : https://www.kb.cert.org/vuls/id/616257
• NIST NVD – CVE-2026-8863 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-8863
• Help Net Security – No one knows how many old shims can still bypass UEFI Secure Boot : https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/

La entrada Once shims antiguos firmados por Microsoft abren la puerta a saltarse UEFI Secure Boot en Linux se publicó primero en Una Al Día.

La exposición accidental de un servidor web ha dejado al descubierto tres operaciones activas de phishing dirigidas a cuentas de Microsoft 365, con suficiente información como para reconstruir su infraestructura, sus herramientas y parte de su operativa. El fallo no vino de una vulnerabilidad sofisticada, sino de una mala práctica básica: levantar un servicio con python3 -m http.server 8080 y permitir listados de directorios. A partir de ahí, el acceso a artefactos y a un archivo tan revelador como .bash_history facilitó seguir el rastro técnico de las campañas.

El material apuntó a tres actores distintos, identificados como codemado, mail-argenta y saroula01, que trabajaban de forma independiente con bifurcaciones de Evilginx sacadas de repositorios públicos. Dos técnicas concentraron el grueso del riesgo. La primera, el phishing AiTM con proxy inverso, sirve para interponerse entre la víctima y el servicio real, capturar cookies de sesión y sortear la MFA tradicional en flujos interactivos. La segunda, más silenciosa, explota el flujo OAuth Device Code, el que utiliza microsoft.com/devicelogin, para conseguir tokens sin necesidad de clonar la pantalla de inicio de sesión ni robar la contraseña en una página señuelo.

En una variante apodada red-queen, los operadores retocaron atributos HTML para esquivar Subresource Integrity, añadieron reescritura de URL y fijaron un TTL de un año para cookies capturadas. En los artefactos analizados aparecieron cookies con caducidad tan lejana como el 30 de junio de 2027, un recordatorio incómodo de cuánto puede durar una sesión si el entorno no aplica controles adicionales. En paralelo, la campaña basada en Device Code acumuló 218 víctimas confirmadas en 12 países entre junio de 2025 y julio de 2026, con predominio de buzones corporativos. También se recuperaron tokens con autoRefresh y renovaciones repetidas, una pista de automatización para mantener sesiones vivas en segundo plano.

El caso también ilustra el salto del robo de credenciales al control continuado. El actor codemado desplegó herramientas RMM para persistencia y gestión posterior, entre ellas SimpleHelp, ScreenConnect y XEOX, además de droppers y robacredenciales. Cuando un atacante consigue un token reutilizable, el correo corporativo deja de ser solo un objetivo, se convierte en una plataforma para moverse por la organización.

En defensa, las prioridades se reparten por vectores. Para el phishing con proxy inverso, la MFA resistente al phishing, como FIDO2 o passkeys, reduce de forma drástica la eficacia de la captura de cookies en inicios de sesión interactivos. Para el abuso de Device Code, el enfoque cambia: conviene bloquear el flujo en Microsoft Entra ID siempre que no exista una necesidad operativa real y dejar excepciones mínimas, acotadas a dispositivos o herramientas que lo requieran.

A partir de ahí, la higiene pasa por políticas sólidas de Acceso Condicional, restricciones por ubicación e IP, y la activación de Continuous Access Evaluation para recortar la vida útil efectiva de tokens robados en cargas compatibles. La telemetría también ayuda: resulta clave auditar concesiones de tokens vinculadas a Device Code, buscar sesiones cuyo origen refleje ese método, y vigilar en los registros de Entra las concesiones de refresh token asociadas al client ID d3590ed6-52b3-4102-aeff-aad2292ab01c cuando no sea esperable el uso del cliente de Office de escritorio, cruzándolo con IPs o ASN inusuales.

Si aparece actividad sospechosa, la respuesta no debería quedarse en cambiar contraseñas. Hace falta una contención orientada a tokens: revocar sesiones y refresh tokens, forzar reautenticación con Acceso Condicional y acortar tiempos de reacción cuando se detecte Device Code en una cuenta comprometida. Y en los endpoints, conviene buscar RMM no autorizadas, en especial XEOX, con indicadores como C:\Program Files (x86)\XEOX\xeox-agent_x64.exe y tareas programadas compatibles con *XEOX*Agent*Watchdog*. La filtración de un servidor ha expuesto algo más que una campaña, ha enseñado cómo se encadenan hoy el engaño, los tokens y la persistencia en entornos cloud.

Más información

• The Hacker News – Misconfigured Server Reveals Three Evilginx Phishing Operations Targeting Microsoft 365 : https://thehackernews.com/2026/07/misconfigured-server-reveals-three.html
• Lexfo – One Misconfigured Server, Three Active Campaigns: Full exposure of three AiTM Phishing Operators : https://blog.lexfo.fr/opendir-to-phishing-operator.html
• Microsoft Security Blog – Inside an AI-enabled device code phishing campaign : https://www.microsoft.com/en-us/security/blog/2026/04/06/ai-enabled-device-code-phishing-campaign-april-2026/

La entrada Un servidor mal configurado destapa tres campañas de phishing que burlan el acceso a Microsoft 365 se publicó primero en Una Al Día.

Un atacante logró colar una versión maliciosa del SDK de Injective Labs en npm y la usó para robar credenciales de criptowallets. La pieza clave del incidente fue @injectivelabs/sdk-ts 1.20.21, un paquete muy habitual en proyectos que interactúan con el ecosistema Injective desde TypeScript. El riesgo no se limita al código, afecta a fondos: si un desarrollador generó o importó una wallet con esa versión, la frase mnemónica y la clave privada pudieron salir del equipo.

El compromiso empezó con la toma de control de una cuenta de GitHub perteneciente a un colaborador legítimo. A partir de ahí, el atacante introdujo commits sospechosos el 8 de junio de 2026 y terminó publicando la release contaminada en el registro de npm. Además, no se conformó con un solo paquete: publicó la misma versión 1.20.21 para otros 17 paquetes vinculados al proyecto y los dejó fijados a la dependencia comprometida, una táctica que multiplica el alcance cuando otros repositorios instalan el ‘pack’ completo.

El comportamiento del malware resulta especialmente incómodo para los equipos que confían en escaneos básicos de instalación. No se ejecuta al hacer npm install. Se activa cuando el código invoca funciones del SDK para crear o importar claves. En ese momento, el código captura la frase semilla completa y la private key, las codifica en base64 y las exfiltra mediante una petición HTTP POST.

La filtración, además, puede pasar desapercibida: el envío se dirige a un endpoint dentro de infraestructura pública de Injective Labs, lo que puede camuflar el tráfico como si fuera telemetría legítima. La lógica agrupa durante alrededor de dos segundos varias claves y mnemónicos antes de enviarlos, y lo hace en la cabecera de la petición, algo poco habitual en integraciones normales y que puede delatarse por cabeceras anormalmente grandes.

El paquete malicioso se descargó al menos 310 veces antes de que lo marcasen como deprecated, aunque los artefactos de esa release siguen disponibles. El problema escala por dependencia: el SDK arrastra 87 dependencias directas y su ecosistema suma más de 112.000 descargas, así que el impacto potencial se extiende a cadenas de builds y entornos de CI/CD que se actualizan de forma automática.

Injective revirtió los cambios en cuestión de minutos y publicó una versión limpia, 1.20.23. Aun así, la mitigación no se limita a actualizar. Los equipos deben localizar y eliminar @injectivelabs/sdk-ts 1.20.21 en repositorios, imágenes y artefactos de build, revisar lockfiles y logs de CI para confirmar si se instaló, y asumir exposición si se ejecutaron rutas de código de creación o importación de wallets.

Si existe la mínima sospecha de uso real, la recomendación práctica es drástica: mover los fondos a nuevas wallets y tratar las antiguas como quemadas. Conviene rotar también secretos que pudieran convivir en las máquinas afectadas, como tokens, API keys o credenciales de despliegue, porque un atacante que ya robó claves de wallet suele buscar un segundo golpe. En paralelo, resulta razonable revisar el tráfico saliente de runners y estaciones de trabajo en busca de POST anómalos ligados a la supuesta telemetría del SDK.

Este caso vuelve a señalar el punto débil de siempre: la cadena de suministro en JavaScript. Endurecerla pasa por fijar versiones con rigor, añadir verificación de integridad en el pipeline, revisar dependencias de forma sistemática y reforzar la publicación con MFA en cuentas de GitHub y npm. También ayuda aislar los entornos de build y limitar el acceso a secretos en CI con mínimo privilegio y credenciales efímeras cuando sea viable.

Más información

• BleepingComputer – Injective SDK on npm infected with cryptocurrency wallet stealer : https://www.bleepingcomputer.com/news/security/injective-sdk-on-npm-infected-with-cryptocurrency-wallet-stealer/
• Snyk – @injectivelabs/sdk-ts : https://security.snyk.io/package/npm/%40injectivelabs%2Fsdk-ts

La entrada Un SDK de Injective en npm distribuye un ladrón de claves para criptowallets se publicó primero en Una Al Día.

Microsoft ha lanzado un parche para RoguePlanet, una vulnerabilidad zero-day de elevación local de privilegios en Microsoft Defender que permite a un atacante ejecutar código con permisos SYSTEM en Windows 10 y Windows 11. La corrección llega después de que circulase una prueba de concepto pública que demuestra la escalada incluso en equipos con las actualizaciones acumulativas de junio de 2026 ya instaladas, un matiz importante porque subraya que el problema no dependía del Patch Tuesday, sino de la capa de seguridad del propio Defender.

El fallo, registrado como CVE-2026-50656, afecta al Microsoft Malware Protection Engine, el motor que se encarga del análisis antimalware y que opera muy cerca del sistema. La vulnerabilidad se apoya en una condición de carrera que, en determinados escenarios, permite a un usuario local pasar de permisos limitados a control total del equipo. En la práctica, ese salto a SYSTEM suele servir para desactivar defensas, manipular servicios, persistir en la máquina y moverse con más facilidad por un entorno corporativo.

Uno de los detalles más incómodos del caso es que la explotación puede funcionar aunque la protección en tiempo real de Defender esté desactivada. También se ha señalado que podría afectar a configuraciones en modo pasivo, algo que todavía requiere verificación pública completa. Para organizaciones que confían en Defender como parte del stack de seguridad, esto refuerza una idea que a veces se pasa por alto: Defender se actualiza por su propia vía, y no basta con mantener Windows ‘al día’ si el motor y las definiciones no se renuevan con la misma disciplina.

La puntuación asociada, CVSS 7.8, coloca el problema en severidad alta. Microsoft asignó el identificador el 16 de junio de 2026 y actualizó el registro el 8 de julio de 2026. Aun así, no han trascendido una lista completa de versiones afectadas, ni indicadores de compromiso, ni detalles técnicos exhaustivos, y tampoco existe confirmación pública de explotación activa en ataques reales.

Para mitigar el riesgo, las prioridades son claras: actualizar de inmediato el motor y las definiciones de Microsoft Defender en toda la flota, incluidos servidores y entornos VDI, y comprobar desde la gestión centralizada que esas actualizaciones de plataforma se aplican de verdad. También conviene reforzar la monitorización de señales típicas de escalada local, como procesos inusuales lanzados por MsMpEng.exe o actividad anómala con privilegios SYSTEM. Y, como casi siempre en este tipo de fallos, el endurecimiento de accesos locales importa: una elevación de privilegios rara vez es el primer paso, suele ser la palanca tras una intrusión inicial.

Más información

• BleepingComputer – Microsoft patches RoguePlanet Defender zero-day vulnerability : https://www.bleepingcomputer.com/news/security/microsoft-patches-rogueplanet-defender-zero-day-vulnerability/
• SecurityWeek – Microsoft Working on Patch for ‘RoguePlanet’ Zero-Day : https://www.securityweek.com/microsoft-working-on-patch-for-rogueplanet-zero-day/amp/
• NVD (NIST) – CVE-2026-50656 : https://nvd.nist.gov/vuln/detail/CVE-2026-50656

La entrada Microsoft corrige RoguePlanet, un zero-day en Defender que permitía obtener permisos SYSTEM se publicó primero en Una Al Día.

La vulnerabilidad GhostLock ( CVE-2026-43499 ) ha puesto en guardia a administradores y equipos de seguridad por un motivo poco habitual: el fallo lleva presente en el kernel de Linux desde 2011 y afecta de forma transversal a gran parte del ecosistema. El escenario es especialmente delicado en servidores compartidos y plataformas con contenedores, porque la debilidad permite a un usuario local sin privilegios acabar con permisos de root y, en los entornos probados, romper el aislamiento del contenedor.

El problema se esconde en la lógica de rtmutex, en concreto en la función remove_waiter(). Cuando el kernel gestiona el rollback de un proxy lock a través de futex_requeue(), puede dejar referencias inconsistentes que terminan en punteros colgantes y desembocan en un use after free. Es el tipo de fallo que, bien encadenado, convierte un acceso local limitado en control total del sistema.

El riesgo operativo ha subido varios peldaños porque Nebula Security publicó código de explotación funcional y habla de una fiabilidad del 97% en sus pruebas. Aun así, no existe constancia pública de explotación activa en campañas reales. Eso no reduce la urgencia: con un exploit disponible, bastan credenciales de baja confianza, un usuario en una máquina multiusuario o un proceso dentro de un contenedor para que el incidente pase de ‘molesto’ a ‘crítico’.

La corrección principal entró en abril de 2026, pero el camino no ha sido limpio. Se recomendó evitar quedarse en la primera compilación que incorporó el arreglo inicial, porque apareció un problema adicional de estabilidad, CVE-2026-53166, que podía provocar caídas. Traducido al día a día: no basta con ‘parchear’, hay que comprobar la versión exacta del paquete y confirmar que incluye el fix final y no un build intermedio.

En cuanto a severidad, Ubuntu la clasifica como High y refleja un CVSS 3.1 de 7.8, una puntuación coherente con un fallo de escalada local que además puede facilitar container escape. La recomendación es clara: actualizar a un kernel corregido, revisar los avisos de cada distribución, priorizar nodos con CI runners, clusters con alta rotación de cargas y cualquier host multiinquilino, y mantener activas mitigaciones de compilación como RANDOMIZE_KSTACK_OFFSET y STATIC_USERMODE_HELPER cuando estén disponibles. Ayudan a dificultar la explotación, pero no sustituyen el parche.

Más información

• The Hacker News – 15-Year-Old GhostLock Flaw Enables Root and Container Escape on Most Linux Distros : https://thehackernews.com/2026/07/15-year-old-ghostlock-flaw-enables-root.html
• Nebula Security – IonStack part II: GhostLock, a stack-UAF that has existed in ALL Linux distributions for 15 years : https://nebusec.ai/research/ionstack-part-2/
• Ubuntu Security – CVE-2026-43499 : https://ubuntu.com/security/CVE-2026-43499
• NIST NVD – CVE-2026-43499 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-43499

La entrada Un fallo de 15 años en el kernel de Linux permite hacerse root y escapar de contenedores se publicó primero en Una Al Día.