La infraestructura de Awesome Motive distribuyó JavaScript manipulado a sitios WordPress que cargaban recursos de OptinMonster y TrustPulse durante una período concreto del 12 de junio de 2026, y también a instalaciones de PushEngage durante un periodo más amplio. El incidente se enmarca en un ataque de cadena de suministro vía CDN: el código se servía desde dominios legítimos del proveedor, así que muchos sitios lo cargaron sin sospechar.

El comportamiento malicioso no apuntó al visitante común. Solo se activaba cuando un administrador de WordPress navegaba por una página del sitio con la sesión iniciada. En ese escenario, el script intentaba recolectar tokens de autenticación y nonces del CMS, piezas clave para autorizar acciones sensibles. Con ese material, el atacante podía crear una cuenta de administrador fraudulenta y abrir la puerta a un control persistente.

La intrusión no se quedaba en una simple cuenta nueva. La cadena de ataque incluía la instalación de un plugin de backdoor con capacidad de ocultarse dentro del panel de WordPress, lo que complica la detección para quien solo revise la lista de extensiones desde la interfaz. Ese componente ofrecía control remoto del sitio, con web shell y posibilidad de ejecución arbitraria de código PHP, un escenario especialmente serio porque permite modificar contenido, robar datos o pivotar hacia otros sistemas.

Entre los indicios observados figuran nombres de cuentas como developer_api1 y usuarios con patrón dev_xxxxxx. En paralelo, el plugin malicioso se camufló con etiquetas creíbles, como Content Delivery Helper (content-delivery-helper, v2.7.1) o Database Optimizer (database-optimizer, v2.9.4). También se vio infraestructura que imitaba servicios legítimos, con el dominio tidio.cc como posible destino de exfiltración de credenciales y detalles del sitio.

Los ficheros señalados como alterados incluyen api.min.js, servidos desde dominios como a.omappapi.com, a.opmnstr.com y a.optnmstr.com en el caso de OptinMonster, además de a.trstplse.com para TrustPulse. La exposición confirmada para OptinMonster y TrustPulse se concentró entre las 22:17 UTC y las 22:42 UTC del 12 de junio de 2026. En PushEngage, las evidencias apuntan a que el JavaScript malicioso se sirvió al menos hasta el 13 de junio, y podría haber llegado al 14 de junio.

El proveedor limpió la CDN y rotó credenciales, pero ese paso no basta para quien ya haya caído: si el sitio llegó a crear la cuenta y a instalar el plugin oculto, el compromiso permanece aunque el script ya no se sirva. Por eso, la recomendación práctica pasa por tratar como potencialmente comprometido cualquier WordPress con OptinMonster o TrustPulse activo si un administrador inició sesión durante el 12 de junio.

La respuesta a incidente debería incluir una revisión de usuarios administradores para eliminar altas no autorizadas, y una inspección directa del sistema de ficheros en wp-content/plugins para localizar content-delivery-helper o database-optimizer, aunque no aparezcan en el panel. Conviene ejecutar un escaneo antimalware del lado del servidor y auditar persistencias habituales, como mu-plugins, tareas de cron y ficheros PHP modificados.

En paralelo, toca rotar contraseñas de administradores, claves API, credenciales de base de datos y las keys y salts de WordPress en wp-config.php. Revisar registros de DNS, proxy y tráfico saliente para detectar comunicaciones con tidio.cc puede aportar pistas sobre si se produjo exfiltración. Y, como medida de contención a futuro, actualizar WordPress y plugins, endurecer la configuración y activar MFA en cuentas administrativas reduce mucho el margen de maniobra de ataques similares.

El punto de entrada, según la información disponible, partió del entorno del sitio de marketing del proveedor tras explotar una vulnerabilidad conocida en el plugin UpdraftPlus. Desde ahí, los atacantes habrían sustraído una clave API del CDN, un recordatorio de que la seguridad no termina en el código del plugin: también depende, y mucho, de cómo se protegen las llaves y los sistemas que distribuyen recursos a millones de webs.

Más información

• bleepingcomputer.com – OptinMonster WordPress plugin hacked in CDN supply-chain attack : https://www.bleepingcomputer.com/news/security/optinmonster-wordpress-plugin-hacked-in-cdn-supply-chain-attack/
• trustpulse.com – Security Incident: Tampered Script Served via TrustPulse and OptinMonster : https://trustpulse.com/2026/06/14/security-incident-tampered-script-served-via-trustpulse-and-optinmonster/
• Infosecurity Magazine – Attackers Hijack Popular WordPress Plugins to Deploy Backdoors : https://www.infosecurity-magazine.com/news/wordpress-plugin-supply-chain/

La entrada Un ataque a la CDN de Awesome Motive inyecta JavaScript malicioso en OptinMonster y otros plugins de WordPress se publicó primero en Una Al Día.

La vulnerabilidad CVE-2026-20253 pone en alerta a quienes operan Splunk Enterprise en entornos propios, especialmente si exponen servicios a redes no confiables. El fallo permite a un atacante sin autenticación crear o truncar ficheros arbitrarios en el sistema objetivo mediante un endpoint asociado a un sidecar de PostgreSQL, un componente auxiliar que Splunk utiliza en determinadas configuraciones. El riesgo no es menor: la puntuación alcanza CVSS 9.8 y el escenario encaja con una ausencia de autenticación en una función crítica, catalogada como CWE-306.

El problema nace en la falta de controles de acceso del endpoint del sidecar. En la práctica, cualquier actor con conectividad de red hacia ese servicio puede invocarlo sin pasar por credenciales. La gravedad se dispara porque esa capacidad de escritura, aunque empiece como una operación de fichero, se puede transformar en algo mucho más serio. La propia cadena de ataque descrita se apoya en los endpoints /v1/postgres/recovery/backup y /v1/postgres/recovery/restore, que permiten volcar y restaurar datos. Si el atacante logra que el proceso consuma un volcado controlado, puede ejecutar SQL durante la restauración.

A partir de ahí, el salto a RCE resulta plausible al sobrescribir scripts que Splunk ejecuta de forma recurrente, por ejemplo ficheros Python dentro de rutas como /opt/splunk/etc/apps/. Ese tipo de manipulación encaja con ataques que buscan persistencia y control, con un impacto potencial alto en confidencialidad, integridad y disponibilidad, justo lo que refleja el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Las versiones afectadas abarcan Splunk Enterprise 10.0.0 a 10.0.6 y 10.2.0 a 10.2.3. Splunk corrigió el fallo en 10.0.7 y 10.2.4, y aclara que Splunk Enterprise 10.4 no se ve afectado. También insiste en un matiz relevante para muchas empresas: Splunk Cloud no entra en el alcance porque no utiliza estos Postgres sidecars.

En el momento de la publicación no se ha confirmado explotación activa en ataques reales, pero el fabricante no ofrece mitigaciones temporales: la vía recomendada pasa por actualizar. Además de aplicar los parches, conviene priorizar las instancias expuestas a redes no confiables, revisar la integridad de ficheros y scripts en la instalación de Splunk, y vigilar llamadas anómalas a /v1/postgres/recovery/backup y /v1/postgres/recovery/restore para detectar intentos de abuso antes de que escalen.

Más información

• thehackernews.com – Critical Splunk Enterprise Flaw Lets Attackers Run Code Without Authentication : https://thehackernews.com/2026/06/critical-splunk-enterprise-flaw-lets.html
• Splunk Advisory – SVD-2026-0603: Unauthenticated Arbitrary File Creation and Truncation in a PostgreSQL Sidecar Service Endpoint in Splunk Enterprise : https://advisory.splunk.com/advisories/SVD-2026-0603
• Orca Security – CVE-2026-20253: Splunk Enterprise RCE & Unauthenticated File Operation Flaws : https://orca.security/resources/blog/cve-2026-20253-splunk-enterprise-rce-unauthenticated-file-operations/

La entrada Splunk corrige un fallo crítico en Splunk Enterprise que abre la puerta a ejecución remota de código sin autenticación se publicó primero en Una Al Día.

La CISA añadió el 9 de junio de 2026 tres vulnerabilidades al catálogo Known Exploited Vulnerabilities (KEV) después de detectar que los atacantes ya las usan en campañas reales. La medida pone el foco en entornos muy distintos, desde la infraestructura de red hasta el navegador, y fija para las agencias federales incluidas en el programa FCEB una fecha límite de mitigación: el 23 de junio de 2026.

La primera, CVE-2026-20245, afecta a Cisco Catalyst SD-WAN Manager. El fallo permite que un atacante con acceso autenticado y local ejecute comandos arbitrarios con privilegios de root. El vector pasa por suministrar un fichero manipulado al sistema, un detalle que vuelve especialmente relevante el control de qué archivos se suben, se importan o se procesan en la plataforma de administración.

La segunda, CVE-2026-11645, golpea al motor V8 de Google Chrome. El escenario es el clásico que preocupa a cualquier organización: un atacante remoto puede preparar una página HTML manipulada para lograr ejecución de código dentro del sandbox del navegador. Google ya corrigió el problema en Chrome Stable Desktop para Windows, macOS y Linux, y mantuvo restringidos varios detalles técnicos mientras la actualización llega a la mayoría de usuarios. La recomendación práctica es inmediata: actualizar al menos a 149.0.7827.103 y comprobarlo desde chrome://settings/help.

El tercer caso, CVE-2026-7473, afecta a Arista EOS y abre la puerta a un procesamiento inesperado de tráfico tunelizado que el equipo no tiene configurado, siempre que actúe como endpoint de túnel con una IP de desencapsulación. El riesgo se concentra en familias como Arista 7020R, 7280R/7280R2 y 7500R/7500R2, sobre todo si existe configuración como VXLAN VTEP, decap groups o una interfaz GRE.

Aquí hay un matiz importante: Arista no prevé publicar un parche para esta vulnerabilidad y apuesta por mitigaciones. La vía recomendada pasa por aplicar ACL en los propios equipos o en dispositivos situados aguas arriba para permitir solo el tráfico de túnel legítimo y bloquear el malicioso. También conviene inventariar qué switches actúan como endpoints con desencapsulación, revisar si esa función debe permanecer expuesta y reforzar segmentación y filtrados en redes de administración.

Para organizaciones fuera del ámbito federal estadounidense, el catálogo KEV funciona como termómetro fiable de prioridad: si una debilidad entra ahí, no espera. Parchear Chrome, endurecer el acceso a la CLI y a redes de gestión en Cisco, y aplicar controles de tráfico en Arista marca la diferencia entre una incidencia contenida y una intrusión con recorrido.

Más información

• The Hacker News – CISA Adds Cisco, Chrome, and Arista Flaws to KEV Catalog Amid Active Exploitation : https://thehackernews.com/2026/06/cisa-adds-cisco-chrome-and-arista-flaws.html
• TechRadar – Update Chrome now — Google patches new zero-day flaw already being exploited : https://www.techradar.com/pro/security/update-chrome-now-google-patches-new-zero-day-flaw-already-being-exploited

La entrada CISA incorpora fallos explotados en Cisco, Chrome y Arista a su catálogo KEV se publicó primero en Una Al Día.

La tanda de parches de Microsoft del 9 de junio de 2026 llega con un volumen poco cómodo incluso para los equipos acostumbrados al Patch Tuesday: corrige alrededor de 200 vulnerabilidades y mete en el mismo paquete seis zero-day, cinco ya divulgadas públicamente y una con explotación activa. La actualización afecta a Windows en varios componentes y también a Microsoft Exchange Server, con implicaciones claras para organizaciones con servidores expuestos a Internet.

El balance técnico incluye 33 fallos críticos. Dentro de ese grupo aparecen 28 vulnerabilidades de ejecución remota de código, además de errores de elevación de privilegios y divulgación de información. Es el tipo de boletín que obliga a priorizar, porque mezcla problemas explotables a distancia con otros que facilitan pasar de un acceso limitado a control total del sistema.

El caso más delicado se centra en CVE-2026-42897, un fallo de suplantación en Microsoft Exchange Server 2016, 2019 y Subscription Edition (SE). Permite ejecutar JavaScript en el navegador dentro de Outlook Web Access (OWA) cuando el usuario abre un correo manipulado. Se ha visto en ataques reales y, de hecho, CISA lo incorporó a su catálogo de vulnerabilidades explotadas conocidas a mediados de mayo, elevando la presión sobre los administradores de correo.

Otra corrección sensible apunta a HTTP.sys con CVE-2026-49160, un DoS asociado al patrón HTTP/2 Bomb. El ataque dispara el consumo de recursos forzando un uso desproporcionado de memoria mediante cabeceras HTTP/2 y parámetros de flow control. Microsoft añadió el ajuste de registro MaxHeadersCount para limitar el número de cabeceras aceptadas en peticiones HTTP/2 y HTTP/3, con instrucciones específicas en KB5102602, una medida práctica para servidores expuestos.

El boletín también toca el cifrado. CVE-2026-45585, vinculada al alias YellowKey, permite saltarse BitLocker con acceso físico, un riesgo especialmente relevante en equipos con Windows 11 configurados en modo solo TPM, y en Windows Server 2022 y Windows Server 2025. A esto se suma CVE-2026-50507, otro bypass asociado al nombre bitskrieg, que llega con una advertencia operativa: en algunos equipos pueden aparecer problemas de arranque ligados a la carga de la clave de BitLocker.

En el terreno de privilegios, Microsoft corrige CVE-2020-17103 en Windows Cloud Files Mini Filter Driver, asociada a Mini Plasma, y CVE-2026-45586 en Windows Collaborative Translation Framework, relacionada con GreenPlasma. En ambos casos la preocupación es clara: estos fallos pueden convertir una intrusión limitada en una shell con permisos SYSTEM, el punto en el que el atacante ya juega con ventaja.

La recomendación para administradores y responsables de seguridad pasa por actuar en dos velocidades. Primero, desplegar con prioridad los parches de junio en servidores expuestos a Internet y en sistemas con datos sensibles. En Exchange, conviene instalar la actualización cuanto antes y mantener habilitado Exchange Emergency Mitigation Service, conservando la mitigación aplicada para CVE-2026-42897 como una capa adicional. En servidores que dependan de HTTP.sys, la configuración de MaxHeadersCount ayuda a reducir la superficie ante ataques de tipo HTTP/2 Bomb.

Para entornos con exigencias de protección física, merece la pena revisar BitLocker y evitar el modo solo TPM cuando proceda, migrando a TPM+PIN. Y si tras parchear CVE-2026-50507 aparece el error de BitLocker relacionado con la carga de clave, Microsoft apunta una salida práctica: reinicializar WinRE desactivándolo y activándolo de nuevo con reagentc en una consola con privilegios elevados. Como siempre en parches que tocan el arranque, lo sensato es validar primero en preproducción y vigilar de cerca los equipos más críticos.

Más información

• BleepingComputer – Microsoft June 2026 Patch Tuesday fixes 6 zero-days, 200 flaws : https://www.bleepingcomputer.com/news/microsoft/microsoft-june-2026-patch-tuesday-fixes-6-zero-days-200-flaws/
• BleepingComputer – Microsoft patches Exchange Server zero-day exploited in attacks : https://www.bleepingcomputer.com/news/microsoft/microsoft-patches-exchange-server-zero-day-exploited-in-attacks/

La entrada Microsoft tapa 200 fallos en Windows y Exchange con seis vulnerabilidades zero-day se publicó primero en Una Al Día.

La CISA ha activado el modo urgencia con Check Point: la agencia estadounidense ha metido CVE-2026-50751 en el catálogo KEV de vulnerabilidades explotadas y ha ordenado a las agencias federales que lo remedien antes del 11 de junio de 2026, un margen inusualmente corto. El movimiento no responde a un riesgo teórico. La explotación se ha observado en ataques reales y, al menos en un incidente, se ha vinculado la actividad posterior a la intrusión con un afiliado de ransomware Qilin, con una atribución de confianza media.

El problema afecta al perímetro, justo donde más duele. CVE-2026-50751 permite que un atacante remoto no autenticado se salte la autenticación y levante una sesión de VPN de acceso remoto. La condición clave aparece en despliegues de Check Point Remote Access VPN y Mobile Access que todavía aceptan IKEv1, un protocolo obsoleto que muchas organizaciones mantienen por compatibilidad con clientes antiguos. El escenario se agrava cuando el gateway admite clientes heredados y no exige certificado de máquina para conectar.

A nivel técnico, el fallo encaja en CWE-287 por autenticación incorrecta y alcanza una puntuación CVSS 9,3. La debilidad nace de una lógica defectuosa en la validación de certificados durante el intercambio IKEv1 en componentes de acceso remoto. Tras el bypass, el atacante aún necesita acciones adicionales para moverse por la red, acceder a recursos internos o escalar privilegios, pero la puerta de entrada queda abierta en un servicio expuesto.

La actividad se detecta desde, al menos, el 7 de mayo de 2026, con un repunte a principios de junio. Se describe como una campaña de alcance limitado, con varias decenas de organizaciones afectadas en distintos países, pero el patrón encaja con lo que más buscan hoy los grupos de extorsión: credenciales y sesiones en el borde para colarse sin levantar demasiadas alarmas.

Check Point publicó hotfixes el 8 de junio de 2026 para múltiples ramas, entre ellas R80.20.X, R80.40, R81, R81.10, R81.10.X, R81.20, R82, R82.00.X y R82.10. El detalle incómodo es que varias de esas ramas ya han llegado a fin de soporte, como R80.20.X, R80.40, R81 y R81.10, lo que complica el mantenimiento y reduce el margen de maniobra ante incidentes.

En paralelo, la compañía ha identificado CVE-2026-50752 con CVSS 7,4 en el mismo camino de código de IKEv1, potencialmente útil para ataques de tipo intermediario en túneles site to site bajo ciertas configuraciones, sin señales de explotación activa.

La lista de prioridades para equipos de seguridad es clara: aplicar ya los hotfix, desactivar IKEv1 y forzar IKEv2, retirar el soporte de cliente heredado cuando sea viable y obligar al certificado de máquina en las conexiones. También conviene activar IPS y actualizar firmas, además de auditar logs y cambios de configuración desde el 7 de mayo para detectar accesos anómalos y rastros de movimiento lateral. Incluso tras parchear, la recomendación operativa pasa por una búsqueda proactiva de compromiso, con especial atención a posibles mecanismos de persistencia y herramientas de exfiltración. Si la infraestructura sigue en ramas fuera de soporte, toca acelerar la migración a versiones mantenidas: en el perímetro, la deuda técnica se paga con intereses.

Más información

• SC Media – CISA adds Check Point VPN bug to list of exploited vulnerabilities : https://www.scworld.com/news/cisa-adds-check-point-vpn-bug-to-list-of-exploited-vulnerabilities
• Rapid7 – Critical Check Point VPN Zero-Day Exploited in the Wild (CVE-2026-50751) : https://www.rapid7.com/blog/post/etr-critical-check-point-vpn-zero-day-exploited-in-the-wild-cve-2026-50751/

La entrada CISA impone un parche exprés para un fallo crítico en la VPN de Check Point explotado por Qilin se publicó primero en Una Al Día.

El kernel de Linux arrastra un fallo de seguridad relevante en nf_tables, la pieza del subsistema netfilter que permite a nftables gestionar filtrado y reglas de red. El problema abre la puerta a una escalada local de privilegios hasta root cuando el sistema permite a usuarios sin privilegios crear user namespaces y usar nftables, una combinación habitual en muchos entornos modernos y, sobre todo, en máquinas multiusuario o con servicios donde conviven cuentas con distintos niveles de confianza.

La vulnerabilidad se encuadra en un use after free, un tipo de error especialmente delicado porque deja al kernel usando memoria que ya se ha liberado. Aquí la causa está en una comprobación con lógica invertida dentro de nft_map_catchall_activate(), durante el camino de abortado de una transacción. Cuando el kernel intenta reactivar elementos catchall en mapas de veredictos, la condición mal planteada hace que se salten elementos inactivos que deberían restaurarse.

Esa omisión no es un detalle menor: impide recomponer correctamente el contador chain->use de una cadena que sigue referenciada por veredictos NFT_GOTO o NFT_JUMP. Tras repetir abortos de transacciones, el contador puede bajar a cero aunque todavía existan referencias válidas. En ese punto, el sistema permite borrar la cadena y liberar memoria que el kernel aún considera accesible. El resultado es el use after free y, con suficiente control, la posibilidad de tomar el mando.

La investigación pública describe una cadena de explotación completa: incluye fugas de direcciones del kernel para sortear KASLR, filtrado de direcciones en el heap y un secuestro del flujo de ejecución mediante ROP. En pruebas controladas, el exploit supera el 99 por ciento de estabilidad en condiciones ociosas, aunque la tasa cae aproximadamente al 80 por ciento cuando se somete al sistema a una presión intensa de asignaciones de memoria.

El parche se incorporó al proyecto original el 5 de febrero de 2026 y el seguimiento se ha consolidado como CVE-2026-23111, con clasificaciones de severidad altas en distribuciones populares. Ubuntu lo marca como alta prioridad y le asigna una CVSS v3.1 de 7.8, con vector local, baja complejidad y sin necesidad de interacción del usuario.

La mitigación pasa por algo poco glamuroso pero urgente: actualizar. Conviene aplicar los kernels corregidos cuanto antes, priorizando servidores y equipos multiusuario. También resulta sensato revisar el hardening de user namespaces donde no aporten valor operativo, limitar quién puede gestionar reglas de nftables y vigilar el despliegue de kernels en ramas LTS y variantes específicas de proveedores cloud, donde los desfases de versión suelen convertirse en la grieta por la que se cuelan este tipo de escaladas.

Más información

• blog.exodusintel.com – Off By !: Exploiting a Use-after-Free in the Linux Kernel : https://blog.exodusintel.com/2026/06/08/off-by-exploiting-a-use-after-free-in-the-linux-kernel/
• The Hacker News – One-Character Linux Kernel Flaw Enables Local Root Access, Exploits Now Public : https://thehackernews.com/2026/06/one-character-linux-kernel-flaw-enables.html
• Ubuntu Security – CVE-2026-23111 : https://ubuntu.com/security/CVE-2026-23111
• Debian Security Tracker – CVE-2026-23111 : https://security-tracker.debian.org/tracker/CVE-2026-23111

La entrada Un fallo en nftables permite escalar a root en Linux con un exploit estable se publicó primero en Una Al Día.

La campaña Miasma ha sacudido el ecosistema de desarrollo de Microsoft tras comprometer 73 repositorios públicos alojados en GitHub. La plataforma los deshabilitó en bloque y el incidente se extendió por varias organizaciones, entre ellas Azure, Azure Samples, Microsoft y MicrosoftDocs, con un efecto colateral especialmente incómodo: la interrupción de flujos de trabajo que dependían de Azure/functions-action, una GitHub Action oficial utilizada para desplegar Azure Functions.

El punto de partida se localizó en un commit malicioso dentro de Azure/durabletask. Los atacantes lograron introducirlo mediante una cuenta de colaborador comprometida, un detalle clave porque desplaza el foco desde las vulnerabilidades tradicionales hacia algo más difícil de frenar: la confianza depositada en el modelo de mantenimiento y en las credenciales válidas. El cambio buscó pasar desapercibido. Incluyó la marca skip ci, un sello temporal retrodatado y evitó tocar ficheros de código fuente para no levantar sospechas inmediatas.

El mecanismo de ejecución también resulta revelador. En vez de inyectar backdoors en librerías, el ataque añadió ficheros de configuración pensados para disparar auto-ejecución al abrir el repositorio en herramientas de desarrollo. Ahí entran desde Visual Studio Code, mediante tareas que se activan al abrir una carpeta, hasta agentes y entornos populares como Claude Code y Gemini CLI, con hooks de SessionStart, o Cursor, donde se observaron reglas y técnicas de prompt injection orientadas a activar comportamiento no deseado.

La carga maliciosa residía en un script JavaScript ubicado como .github/setup.js. Aparecía ofuscado y con un tamaño de varios megabytes, un patrón compatible con intentos de dificultar el análisis, y apuntaba al robo de credenciales. En paralelo, el caso mostró conexiones con la recomprometida del paquete durabletask en PyPI, que semanas antes ya se había usado para distribuir un ladrón de información en sistemas Linux, lo que refuerza la lectura de una campaña persistente centrada en cadena de suministro.

Para equipos de seguridad y desarrollo, las prioridades se parecen más a una respuesta a incidente clásica que a una simple revisión de dependencias. La recomendación pasa por tratar como potencialmente comprometido cualquier equipo que haya abierto repositorios afectados en VS Code, Claude Code, Cursor o Gemini CLI, y rotar cuanto antes credenciales accesibles desde ese entorno: tokens de GitHub, credenciales de Azure, AWS y GCP, claves SSH, secretos de Kubernetes, tokens de npm y credenciales guardadas en ficheros de configuración.

Conviene también auditar repositorios propios en busca de rutas y artefactos típicos de esta intrusión, como .claude/, .gemini/, .cursor/, .vscode/tasks.json y .github/setup.js. En red, se han señalado indicadores vinculados a la infraestructura de la campaña, incluidos los dominios check.git-service[.]com y t.m-kosche[.]com, útiles para búsquedas en logs y posibles bloqueos.

En el plano operativo, el incidente vuelve a poner el foco en una práctica que muchos equipos todavía dejan para más adelante: fijar GitHub Actions a un SHA de commit en vez de depender de etiquetas mutables como v1. Y, si un pipeline depende de Azure/functions-action@v1, se recomienda migrar temporalmente a alternativas como Azure CLI o Azure DevOps Pipelines. A partir de ahí, protecciones de rama, revisiones obligatorias por pull request y controles sobre el tráfico saliente desde runners de CI/CD completan el cinturón de seguridad frente a un gusano que no necesitó explotar un bug para colarse, le bastó con parecer legítimo.

Más información

• The Hacker News – Miasma Worm Hits 73 Microsoft GitHub Repositories in Major Supply Chain Attack : https://thehackernews.com/2026/06/miasma-worm-hits-73-microsoft-github.html
• StepSecurity – Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents : https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-again-azure-functions-action-and-72-other-repositories-disabled-after-supply-chain-attack-targeting-ai-coding-agents

La entrada El gusano Miasma compromete 73 repositorios de Microsoft en GitHub y fuerza su desactivación se publicó primero en Una Al Día.

La Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) de Estados Unidos ha lanzado una alerta por ataques en curso contra sistemas Automatic Tank Gauge (ATG) que permanecen expuestos directamente a Internet. Este tipo de equipos, habituales en entornos de tecnología operacional (OT), se usan para monitorizar niveles, temperatura y posibles fugas en tanques que almacenan combustible y otros líquidos. Cuando alguien los deja accesibles desde fuera, un incidente ya no se queda en la pantalla de un panel de control: puede trasladarse al terreno, con consecuencias físicas y ambientales.

Los ATG aparecen en sectores catalogados como infraestructuras críticas, desde energía y químico hasta alimentación, agricultura y transporte. La advertencia no habla de una única debilidad concreta, sino de un patrón que se repite en sistemas industriales conectados sin la debida protección: acceso inicial mediante elusión de autenticación, uso de credenciales codificadas de forma fija o contraseñas triviales, explotación de fallos de ejecución de comandos del sistema operativo, inyección SQL y posteriores técnicas de escalada de privilegios.

Una vez dentro, el problema cambia de escala. Los atacantes pueden tocar ajustes que condicionan la operación diaria: configuración de red, identificadores de producto, volúmenes del tanque o incluso controles de bombeo. La manipulación resulta especialmente delicada cuando desactiva alertas o altera la supervisión del llenado, porque dificulta detectar a tiempo una fuga o un fallo de equipo. En un entorno industrial, retrasar una alarma no es un detalle menor.

Por ahora, la actividad no se atribuye a un actor o país concreto, y la autoría sigue sin verificación. También se ha relacionado este tipo de intrusiones con episodios en gasolineras de varios estados, donde se habrían manipulado lecturas en pantalla sin que cambiasen los niveles reales, una afirmación que todavía requiere confirmación definitiva.

El mensaje defensivo es directo: sacar los ATG de la exposición a Internet y tratar el acceso remoto como una excepción, no como la norma. La recomendación pasa por limitar conexiones con cortafuegos, VPN o listas de control de acceso, sustituir contraseñas por defecto por claves robustas y únicas, y activar autenticación multifactor cuando el producto y la operativa lo permitan. A esto se suma lo de siempre, que en OT suele llegar tarde: aplicar parches del fabricante y vigilar registros y cambios de configuración.

En la práctica, conviene afinar la monitorización para detectar señales típicas de manipulación, como la desactivación de alertas, cambios inesperados en parámetros de red o modificaciones en valores operativos críticos, por ejemplo volúmenes y controles de bombeo. En sistemas que miden y previenen fugas, la integridad de los datos es casi tan importante como la propia seguridad perimetral.

Más información

• BleepingComputer – CISA warns of cyberattacks targeting fuel tank monitoring systems : https://www.bleepingcomputer.com/news/security/cisa-warns-of-cyberattacks-targeting-fuel-tank-monitoring-systems/amp/
• Homeland Security Today – Cybersecurity and Infrastructure Security Agency Urges Stronger Security for Automatic Tank Gauge Systems : https://www.hstoday.us/subject-matter-areas/cybersecurity/cybersecurity-and-infrastructure-security-agency-urges-stronger-security-for-automatic-tank-gauge-systems/

La entrada CISA alerta de ataques activos contra sistemas de medición de tanques de combustible expuestos a Internet se publicó primero en Una Al Día.

Un ataque de denegación de servicio remoto, conocido como HTTP/2 Bomb, está poniendo contra las cuerdas a varias implementaciones de HTTP/2 capaces de caer en menos de un minuto por agotamiento de memoria. El fallo se ha asociado a CVE-2026-49975 en el entorno de Apache HTTP Server, pero la técnica no se queda ahí: pruebas públicas muestran caídas rápidas también en nginx, Envoy y hasta Microsoft IIS en Windows Server 2025.

La idea no consiste en enviar cabeceras enormes, que es lo que muchos sistemas ya vigilan. El truco combina dos abusos de HTTP/2 que, juntos, resultan explosivos. Primero, una ‘bomba’ basada en HPACK, el mecanismo de compresión de cabeceras, fuerza al servidor a realizar asignaciones internas desproporcionadas mediante referencias indexadas. Después, el atacante bloquea el control de flujo llevando la ventana a cero, de forma que el servidor no termina de enviar la respuesta ni libera recursos. La petición queda ‘viva’ y la memoria, retenida.

Las cifras impresionan porque rebajan la barrera de entrada. Un único cliente con una conexión de unos 100 Mbps puede disparar el consumo hasta decenas de gigabytes en segundos. En las demostraciones publicadas, un entorno con Envoy 1.37.2 agota 32 GB en torno a 10 segundos; Apache httpd 2.4.67 tarda unos 18; nginx 1.29.7 ronda los 45. En IIS sobre Windows Server 2025, la prueba llega a vaciar 64 GB en aproximadamente 45 segundos.

El ataque, además, sortea defensas que solo miran el tamaño total de cabeceras ya decodificadas. La amplificación nace de la contabilidad por campo y de asignaciones internas del servidor, no de valores especialmente grandes en texto plano. Por eso, imponer límites únicamente por bytes puede no frenar la caída.

Las correcciones ya están sobre la mesa. nginx 1.29.8 introduce la directiva max_headers, con un límite por defecto de 1.000 cabeceras, para cortar el abuso por número de campos. En Apache, mod_http2 2.0.41 ajusta el recuento para que las cabeceras Cookie, incluidas las ‘migas’ cuando se reparten en varios campos, computen contra LimitRequestFields, una diferencia clave en escenarios reales.

Para quienes operan servicios expuestos y no pueden parchear de inmediato, la recomendación práctica pasa por reducir superficie: desactivar HTTP/2 temporalmente, por ejemplo con http2 off en nginx o forzando Protocols http/1.1 en Apache. Otra opción razonable consiste en colocar un proxy inverso o un terminador HTTP/2 delante, con límites estrictos al número de cabeceras por solicitud, contando también fragmentos de Cookie.

En paralelo, conviene separar límites, uno para el tamaño total de cabeceras decodificadas y otro para el número de campos, sin fiarlo todo a una sola métrica. También ayuda acotar la vida máxima de streams bloqueados para evitar retenciones indefinidas, y fijar topes de memoria por proceso o worker con cgroups, ulimit o límites del contenedor, para que un único worker caído no arrastre toda la máquina por swapping.

El riesgo crece porque ya circulan pruebas de concepto y laboratorios de demostración, lo que suele acelerar la adopción en campañas. Envoy ha publicado parches que parecen mitigar la técnica, aunque la validación completa de cobertura figura como pendiente. En un protocolo tan extendido como HTTP/2, la rapidez al desplegar actualizaciones y límites sensatos marca la diferencia entre una caída puntual y una interrupción sistemática del servicio.

Más información

• BleepingComputer – New ‘HTTP/2 Bomb’ DoS attack crashes web servers in under a minute : https://www.bleepingcomputer.com/news/security/new-http-2-bomb-dos-attack-crashes-web-servers-in-under-a-minute/
• Calif – Codex Discovered a Hidden HTTP/2 Bomb : https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
• seclists.org (oss-sec) – HTTP/2 Bomb affects Apache httpd, nginx, envoy, & pingora : https://seclists.org/oss-sec/2026/q2/790

La entrada Un ataque HTTP/2 Bomb tumba servidores web al agotar la memoria se publicó primero en Una Al Día.

Un ataque de denegación de servicio remoto, conocido como HTTP/2 Bomb, está poniendo contra las cuerdas a varias implementaciones de HTTP/2 capaces de caer en menos de un minuto por agotamiento de memoria. El fallo se ha asociado a CVE-2026-49975 en el entorno de Apache HTTP Server, pero la técnica no se queda ahí: pruebas públicas muestran caídas rápidas también en nginx, Envoy y hasta Microsoft IIS en Windows Server 2025.

La idea no consiste en enviar cabeceras enormes, que es lo que muchos sistemas ya vigilan. El truco combina dos abusos de HTTP/2 que, juntos, resultan explosivos. Primero, una ‘bomba’ basada en HPACK, el mecanismo de compresión de cabeceras, fuerza al servidor a realizar asignaciones internas desproporcionadas mediante referencias indexadas. Después, el atacante bloquea el control de flujo llevando la ventana a cero, de forma que el servidor no termina de enviar la respuesta ni libera recursos. La petición queda ‘viva’ y la memoria, retenida.

Las cifras impresionan porque rebajan la barrera de entrada. Un único cliente con una conexión de unos 100 Mbps puede disparar el consumo hasta decenas de gigabytes en segundos. En las demostraciones publicadas, un entorno con Envoy 1.37.2 agota 32 GB en torno a 10 segundos; Apache httpd 2.4.67 tarda unos 18; nginx 1.29.7 ronda los 45. En IIS sobre Windows Server 2025, la prueba llega a vaciar 64 GB en aproximadamente 45 segundos.

El ataque, además, sortea defensas que solo miran el tamaño total de cabeceras ya decodificadas. La amplificación nace de la contabilidad por campo y de asignaciones internas del servidor, no de valores especialmente grandes en texto plano. Por eso, imponer límites únicamente por bytes puede no frenar la caída.

Las correcciones ya están sobre la mesa. nginx 1.29.8 introduce la directiva max_headers, con un límite por defecto de 1.000 cabeceras, para cortar el abuso por número de campos. En Apache, mod_http2 2.0.41 ajusta el recuento para que las cabeceras Cookie, incluidas las ‘migas’ cuando se reparten en varios campos, computen contra LimitRequestFields, una diferencia clave en escenarios reales.

Para quienes operan servicios expuestos y no pueden parchear de inmediato, la recomendación práctica pasa por reducir superficie: desactivar HTTP/2 temporalmente, por ejemplo con http2 off en nginx o forzando Protocols http/1.1 en Apache. Otra opción razonable consiste en colocar un proxy inverso o un terminador HTTP/2 delante, con límites estrictos al número de cabeceras por solicitud, contando también fragmentos de Cookie.

En paralelo, conviene separar límites, uno para el tamaño total de cabeceras decodificadas y otro para el número de campos, sin fiarlo todo a una sola métrica. También ayuda acotar la vida máxima de streams bloqueados para evitar retenciones indefinidas, y fijar topes de memoria por proceso o worker con cgroups, ulimit o límites del contenedor, para que un único worker caído no arrastre toda la máquina por swapping.

El riesgo crece porque ya circulan pruebas de concepto y laboratorios de demostración, lo que suele acelerar la adopción en campañas. Envoy ha publicado parches que parecen mitigar la técnica, aunque la validación completa de cobertura figura como pendiente. En un protocolo tan extendido como HTTP/2, la rapidez al desplegar actualizaciones y límites sensatos marca la diferencia entre una caída puntual y una interrupción sistemática del servicio.

Más información

• BleepingComputer – New ‘HTTP/2 Bomb’ DoS attack crashes web servers in under a minute : https://www.bleepingcomputer.com/news/security/new-http-2-bomb-dos-attack-crashes-web-servers-in-under-a-minute/
• Calif – Codex Discovered a Hidden HTTP/2 Bomb : https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb
• seclists.org (oss-sec) – HTTP/2 Bomb affects Apache httpd, nginx, envoy, & pingora : https://seclists.org/oss-sec/2026/q2/790

La entrada Un ataque HTTP/2 Bomb tumba servidores web al agotar la memoria se publicó primero en Una Al Día.