La agencia federal CISA ha puesto el foco en CVE-2026-45659, un fallo de ejecución remota de código (RCE) en Microsoft SharePoint Server que ya se utiliza en ataques reales y que afecta a instalaciones sin parchear. El problema se apoya en deserialización de datos no confiables, una clase de vulnerabilidad especialmente delicada en entornos corporativos porque puede abrir la puerta a la ejecución de código en el servidor.

El matiz técnico importa. La explotación requiere autenticación, pero no privilegios elevados: basta una cuenta con permisos mínimos comparables al rol de miembro del sitio. A partir de ahí, el atacante puede forzar el procesamiento de datos serializados de forma insegura y llegar a ejecutar código en el servidor. Además, el ataque no necesita interacción de usuario y se considera de baja complejidad, un cóctel que suele favorecer intentos de automatización cuando el servicio se expone a Internet.

Microsoft publicó actualizaciones de seguridad el 21 de mayo de 2026 para SharePoint Enterprise Server 2016, SharePoint Server 2019 y SharePoint Server Subscription Edition. La compañía también reconoció un error de documentación: el CVE no apareció en la lista de ese ciclo de parches, aunque los entornos con las actualizaciones de mayo instaladas por completo no deberían requerir medidas adicionales más allá de confirmar niveles de parche.

La urgencia crece por un dato que retrata el riesgo potencial: se han observado más de 10.000 servidores SharePoint expuestos a Internet en telemetría pública, sin que esa cifra permita inferir cuántos están al día. En paralelo, CISA ha fijado el sábado 4 de julio de 2026 como fecha límite de remediación para organismos federales dentro de la directiva BOD 26-04, una señal habitual de priorización operativa cuando existe explotación activa.

En la práctica, la respuesta pasa por tres frentes. Primero, aplicar los parches de mayo de 2026 o posteriores y verificar que la corrección está realmente desplegada en todas las granjas. Segundo, inventariar instancias y reducir exposición, revisando publicación, segmentación y accesos, porque un servidor accesible desde fuera multiplica el riesgo. Tercero, revisar logs y telemetría para buscar indicios de compromiso y activar respuesta a incidentes ante cualquier anomalía. Por ahora no hay detalles públicos confirmados sobre campañas concretas, actores o indicadores de compromiso, lo que hace aún más importante tratar cualquier instancia anterior al 21 de mayo como de alto riesgo y acelerar contención y validación de integridad.

Más información

• BleepingComputer – CISA: Microsoft SharePoint RCE flaw now actively exploited : https://www.bleepingcomputer.com/news/security/cisa-microsoft-sharepoint-rce-flaw-now-actively-exploited/
• Computer Weekly – US cyber agency warns over forgotten SharePoint flaw : https://www.computerweekly.com/news/366645307/US-cyber-agency-warns-over-forgotten-SharePoint-flaw

La entrada CISA alerta de ataques activos contra un fallo grave en Microsoft SharePoint Server se publicó primero en Una Al Día.

Los equipos que usan Progress Kemp LoadMaster como balanceador o ADC en el perímetro afrontan estos días una amenaza inmediata: una vulnerabilidad crítica permite ejecutar comandos de forma remota sin autenticación cuando la API del dispositivo está activada. Los primeros intentos de explotación se observaron el 29 de junio de 2026 y, aunque no hay confirmación de compromisos culminados, la combinación de severidad, exposición y herramientas públicas eleva el riesgo.

El fallo, registrado como CVE-2026-8037, encaja en el patrón más temido para infraestructuras de entrada: pre-auth RCE por command injection. En la práctica, un atacante puede forzar la ejecución de comandos con privilegios de root en el appliance, algo especialmente delicado en un componente que suele situarse delante de aplicaciones internas, portales corporativos o servicios publicados a Internet.

La explotación pasa por peticiones manipuladas contra el endpoint /accessv2, con un cuerpo JSON construido para desencadenar la inyección. En el trasfondo técnico aparece un manejo incorrecto de cadenas saneadas que no terminan en null, un detalle que puede derivar en lecturas fuera de límites y que, en determinadas condiciones, acaba llevando parte de la carga controlada por el atacante a una shell. No es un matiz menor: convierte una entrada ‘validada’ en una vía de ejecución.

La vulnerabilidad afecta a LoadMaster GA v7.2.63.1 y anteriores, y a LoadMaster LTSF v7.2.54.17 y anteriores, siempre que la API esté habilitada. Las versiones corregidas ya existen, GA v7.2.63.2 y LTSF v7.2.54.18, y conviene tratarlas como actualización prioritaria. La puntuación de severidad se ha movido entre 9.6 y 9.8 en distintas comunicaciones, pero el mensaje operativo es el mismo: es crítica.

Los intentos detectados se asociaron a tráfico desde 192.42.116.58, 192.42.116.105 y 146.70.139.154. Bloquear y vigilar esas direcciones ayuda, aunque no resuelve el problema de fondo: cualquiera puede replicar el patrón con un PoC público y el escaneo masivo suele llegar rápido cuando hay dispositivos expuestos.

Además, el aviso de seguridad que trata CVE-2026-8037 también aborda CVE-2026-33691, una elusión de WAF que permite saltarse comprobaciones de extensión en subidas de ficheros mediante espacios en blanco en nombres de archivo. Quien use funciones de firewall de aplicaciones y subida de archivos debe aplicar también esas correcciones para no dejar una vía alternativa abierta.

En el corto plazo, la recomendación práctica pasa por confirmar si la API está activa y, si no resulta imprescindible, deshabilitarla o restringirla a redes de administración. Si debe seguir operativa, conviene limitar el acceso a los endpoints con ACL, reglas en firewall y segmentación, además de revisar logs en busca de actividad anómala dirigida a /accessv2 y de cuerpos JSON con múltiples claves y patrones compatibles con inyección de comandos. Este incidente vuelve a subrayar una idea incómoda: los balanceadores y ADC, por su posición, necesitan un inventario propio y un ciclo de parches igual de estricto que el de cualquier servidor crítico.

Más información

• The Hacker News – Progress Kemp LoadMaster Pre-Auth RCE Flaw Faces Active Exploitation Attempts : https://thehackernews.com/2026/07/latest-progress-kemp-loadmaster-pre.html
• The Hacker News – Progress Kemp LoadMaster Flaw Could Let Attackers Run Root Commands Pre-Auth : https://thehackernews.com/2026/06/progress-kemp-loadmaster-flaw-could-let.html
• AHA, H-ISAC – Observed Exploitation Attempts Targeting Critical Progress Kemp LoadMaster Vulnerability : https://www.aha.org/h-isac-white-reports/2026-07-01-h-isac-tlp-white-threat-bulletin-observed-exploitation-attempts-targeting-critical-progress

La entrada Detectan intentos de explotación de una vulnerabilidad crítica en Progress Kemp LoadMaster se publicó primero en Una Al Día.

Entre el 12 y el 26 de junio de 2026, una campaña de password spraying puso contra las cuerdas la autenticación asociada a Azure CLI y terminó con al menos 78 cuentas comprometidas en 64 organizaciones. El volumen impresiona: más de 81 millones de intentos en apenas dos semanas. No se trató de un ataque de fuerza bruta clásico, sino de una estrategia pensada para pasar más desapercibida, con pocos intentos por cuenta y una distribución masiva entre identidades.

El patrón encaja con el uso de listas de combinaciones usuario y contraseña procedentes de filtraciones previas. Ese detalle cambia el tablero: cuando un atacante no ‘adivina’ contraseñas, sino que prueba credenciales ya expuestas, la defensa depende mucho más de MFA, de políticas consistentes y de señales de detección temprana.

La clave técnica estuvo en el abuso del flujo OAuth Resource Owner Password Credentials (ROPC), un mecanismo heredado que OAuth 2.1 desaconseja. ROPC permite validar credenciales y emitir tokens sin pasar por experiencias interactivas donde suelen aplicarse controles más estrictos. En escenarios habituales, además, choca con la MFA. Resultado: organizaciones con medidas activadas se vieron igualmente expuestas si sus reglas no cubrían este tipo de inicio de sesión o los tipos de cliente que permiten autenticación programática.

La campaña mostró compromisos diarios entre el 12 y el 21 de junio, con una media de 2 a 4 cuentas por día y un pico el 19 de junio con 12 identidades. El 22 de junio llegó el salto, con 30 identidades afectadas en 23 empresas, una señal de que los atacantes ajustaron su cadencia o ampliaron la lista de objetivos.

La infraestructura apuntó principalmente a IPv6, con actividad concentrada en el rango 2a0a:d683::/32, vinculado al ASN AS32167 y a LSHIY LLC. Este tipo de huella no identifica por sí sola a un responsable, pero sí ofrece un punto práctico para enriquecer alertas, correlacionar eventos y priorizar investigaciones.

El episodio también deja lecciones incómodas sobre la realidad de las políticas de acceso. Se detectaron casos en los que la MFA solo se exigía para aplicaciones concretas, para grupos específicos o solo fuera de ubicaciones de confianza. Ese enfoque crea huecos previsibles, justo los que explotan campañas como esta. En paralelo, al menos ocho organizaciones afectadas no tenían ninguna política de MFA configurada.

En términos defensivos, conviene exigir MFA para todos los usuarios y todas las aplicaciones en la nube, y comprobar que la política cubre los flujos y clientes que usan autenticación no interactiva. También resulta crítico reducir al mínimo ROPC, bloquearlo cuando se pueda y migrar a flujos modernos compatibles con controles de sesión. Otra medida con impacto directo pasa por restringir Azure CLI a quien realmente lo necesite, especialmente entre usuarios no administradores.

Si un equipo de seguridad detecta un inicio de sesión exitoso tras un patrón de spraying, debe tratarlo como posible compromiso: iniciar respuesta a incidentes, invalidar sesiones y tokens, y forzar un cambio de credenciales. A partir de ahí, toca rotar contraseñas reutilizadas, reforzar políticas de contraseña y activar mecanismos de bloqueo inteligente. Y, sobre todo, vigilar picos de fallos ligados a Azure CLI, a endpoints de emisión de tokens y a rangos IPv6 o ASNs anómalos, con alertas que identifiquen el reparto de intentos entre muchas cuentas con pocos intentos por identidad.

La campaña se enmarca en un repunte más amplio del credential spraying, con un incremento superior a 155 veces en volumen observado en los últimos meses en una base de clientes. El mensaje es claro: en la nube, el perímetro es la identidad. Y los atacantes lo saben.

Más información

• The Hacker News – Azure CLI Password Spray Hits at Least 78 Microsoft Accounts in 81M+ Attempts : https://thehackernews.com/2026/07/azure-cli-password-spray-hits-at-least.html
• SecurityWeek – Massive Password Spray Campaign Targeting Azure CLI : https://www.securityweek.com/massive-password-spray-campaign-targeting-azure-cli/

La entrada Una oleada de password spraying contra Azure CLI supera 81 millones de intentos y compromete al menos 78 cuentas se publicó primero en Una Al Día.

La vulnerabilidad CVE-2026-55200 pone en jaque a libssh2, una biblioteca muy usada para añadir soporte de SSH-2 a aplicaciones y servicios. El problema afecta a libssh2 hasta la versión 1.11.1 incluida y permite que un atacante remoto provoque corrupción de memoria y llegue a ejecutar código en el sistema que procese tráfico SSH especialmente manipulado.

El origen del fallo está en la función ssh2_transport_read(), dentro de la capa de transporte. Al leer paquetes SSH, el código acepta un valor packet_length sin imponer un límite superior estricto. Ese detalle, que parece menor, tiene consecuencias serias: un valor desmesurado puede desencadenar una escritura fuera de límites en el heap, con el riesgo clásico de que el proceso se bloquee o, en el peor escenario, ejecute instrucciones controladas por el atacante.

La debilidad encaja en CWE-680, un desbordamiento de entero que acaba derivando en un desbordamiento de búfer. La entrada se mueve en cifras propias de un incidente grave: NVD publica una puntuación CVSS v3.1 de 9.8, mientras que VulnCheck refleja 9.2 en CVSS v4.0. Además, ya existe una prueba de concepto pública referenciada en GitHub, un factor que suele acelerar las pruebas por parte de atacantes y también la reacción de equipos defensivos.

La corrección llega en el commit 97acf3df del repositorio de libssh2. El parche refuerza las comprobaciones del tamaño de los paquetes y rechaza longitudes por encima de LIBSSH2_PACKET_MAXPAYLOAD, cerrando la puerta a ese procesamiento inseguro de datos.

Para reducir el riesgo, conviene actualizar libssh2 a una revisión que incluya el commit 97acf3df o aplicar el parche equivalente en la distribución correspondiente. También toca hacer inventario: libssh2 puede aparecer como dependencia indirecta, y el orden de prioridad debería favorecer a componentes que acepten tráfico SSH desde la red o que se conecten a servidores no confiables. En entornos donde sea posible, limitar el alcance de red ayuda a contener daños. Y en paralelo, resulta prudente reforzar registros y alertas ante patrones anómalos de negociación o tráfico SSH, porque este tipo de ataques suele dejar señales en la capa de transporte.

Un último matiz práctico: la mitigación real depende de la versión concreta que integre cada producto. No basta con ‘tener SSH’. Hay que confirmar que los paquetes del sistema operativo o de la cadena de suministro ya arrastran la corrección.

Más información

• nvd.nist.gov – CVE-2026-55200 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-55200
• VulnCheck – libssh2 – Out-of-Bounds Write via Unchecked packet_length in transport.c : https://www.vulncheck.com/advisories/libssh2-out-of-bounds-write-via-unchecked-packet-length-in-transport-c
• GitHub – transport.c: Additional boundary checks for packet length (#2052) · libssh2/libssh2@97acf3d : https://github.com/libssh2/libssh2/commit/97acf3dfda80c91c3a8c9f2372546301d4a1a7a8

La entrada Un fallo crítico en libssh2 permite ejecutar código remoto con paquetes SSH manipulados se publicó primero en Una Al Día.

Un bloqueador de anuncios para YouTube muy instalado en Google Chrome concentra el foco de la comunidad de seguridad por una capacidad de inyección de JavaScript que puede activarse desde el lado servidor. La extensión se llama Adblock for YouTube y aparece en la Chrome Web Store con el identificador cmedhionkhpnakcndndgjdbohmhepckk, superando los 10 millones de instalaciones.

El problema no reside en un exploit puntual, sino en una combinación de decisiones de diseño. La extensión pide permisos de host para , lo que le permite interactuar con cualquier web que visite el usuario, pese a presentarse como una herramienta centrada en un único servicio. Ese nivel de alcance se vuelve especialmente delicado cuando el navegador se usa para entrar en correo, SSO, paneles de administración o aplicaciones SaaS.

La propia lógica que intenta limitar su actuación a YouTube también resulta frágil. En lugar de validar el hostname o el origen real del contenido, la extensión comprueba si la cadena ‘youtube.com‘ aparece en la URL completa. Eso se puede sortear con facilidad añadiendo ese texto como parámetro o parte de la ruta en cualquier dominio, lo que abre la puerta a que las reglas se apliquen fuera del contexto previsto.

A partir de ahí entra el otro componente clave: la descarga periódica de reglas desde infraestructura remota. Esas reglas pueden incluir instrucciones para ejecutar scriptlets, pequeños fragmentos que modifican la página. Entre ellos figura trusted-create-element, capaz de crear elementos HTML, incluido un script, con contenido controlado por la configuración recibida. En la práctica, ese patrón habilita una vía para inyectar código en el contexto de la web que el usuario tiene abierta.

La capacidad se describe como latente porque, en el momento del análisis, el servidor no devolvía la opción activada. Aun así, el riesgo se mantiene: un cambio en la configuración remota podría alterar de forma sustancial el comportamiento de la extensión sin pasar por una actualización visible ni por una nueva revisión de la tienda. No se ha confirmado la distribución de payload malicioso a usuarios, pero el planteamiento encaja con escenarios clásicos de cadena de suministro.

El contexto no ayuda. En el ecosistema de Chrome, la retirada de extensiones relacionadas con malware se ha repetido en otras ocasiones, y se han citado identificadores de complementos que acabaron fuera de la tienda, como onomjaelhagjjojbkcafidnepbfkpnee, ogcaehilgakehloljjmajoempaflmdci y gekoepiplklhniacchbbgbhilidiojmb. En la ficha pública, Adblock for YouTube figura en la versión 7.2.2 y muestra una actualización fechada el 19 de mayo de 2026.

Para organizaciones, el consejo práctico es claro: conviene bloquear o poner en cuarentena esta extensión mediante políticas corporativas hasta completar una revisión interna. También merece la pena auditar complementos con permisos , vigilar los que dependen de configuración remota para decidir qué inyectan en la página y retirar bloqueadores no gestionados en equipos con acceso a sistemas sensibles. La estrategia más efectiva sigue siendo el allowlisting de extensiones, con evaluación previa cuando cambian propietarios, se amplían permisos o aparece código que permite ejecutar instrucciones controladas desde fuera.

Más información

• The Hacker News – Chrome Ad Blocker with 10M+ Installs Found with Dormant Script Injection Capability : https://thehackernews.com/2026/06/chrome-ad-blocker-with-10m-installs.html
• Island – BadBlocker: 11 Million Users, One Server Call Away from Compromise : https://www.island.io/blog/badblocker-11-million-users-one-server-call-away-from-compromise
• Chrome Web Store – Adblock for YoutubeTM : https://chromewebstore.google.com/detail/adblock-for-youtube/cmedhionkhpnakcndndgjdbohmhepckk?hl=en

La entrada Un popular bloqueador de anuncios en Chrome expone una vía latente para inyectar JavaScript se publicó primero en Una Al Día.

Una campaña bautizada como FortiBleed ha colocado a los dispositivos perimetrales de Fortinet, en especial FortiGate y sus servicios de VPN, en el centro de una operación de robo de credenciales a gran escala. La actividad se concentra en equipos expuestos a Internet y persigue un objetivo muy concreto: conseguir usuarios y contraseñas con los que entrar por la puerta principal, sin necesidad de malware sofisticado ni técnicas especialmente ruidosas.

El patrón que describen las alertas encaja con lo que más teme cualquier equipo de respuesta a incidentes cuando mira al perímetro: oleadas de intentos de acceso automatizados que mezclan fuerza bruta, diccionario y credential stuffing contra portales accesibles desde fuera. En la práctica, los atacantes prueban combinaciones de credenciales de forma masiva, a menudo reutilizando pares de usuario y contraseña procedentes de filtraciones previas, hasta dar con un acceso válido a la SSL VPN o, en el peor escenario, al plano de administración.

El riesgo no termina en el inicio de sesión. Si una cuenta funciona en el firewall o la pasarela VPN y esa contraseña se repite en otros sistemas, el atacante puede saltar a servicios internos y avanzar con movimiento lateral. También preocupa la persistencia: tras un acceso inicial, lo habitual es ver cambios de configuración, creación de usuarios o nuevas reglas que facilitan volver a entrar.

La prioridad defensiva pasa por cortar esa cadena cuanto antes. Conviene rotar de inmediato las contraseñas asociadas a administración, VPN y cuentas de servicio vinculadas a FortiGate y a pasarelas VPN, y activar MFA en cualquier acceso remoto que lo permita. Reducir superficie también ayuda: limitar la exposición a Internet de las interfaces de administración, restringir por ACL o usar una VPN de administración cuando sea viable.

En paralelo, toca mirar los logs con lupa. Hay que buscar picos de autenticaciones fallidas, patrones de credential stuffing y orígenes anómalos, y aplicar umbrales de bloqueo y rate limiting para frenar intentos automatizados. Deshabilitar cuentas que no se usan, eliminar credenciales compartidas y endurecer políticas de contraseña reduce el margen de maniobra del atacante.

Si existe la sospecha de reutilización, el alcance se amplía rápidamente. Un barrido de accesos remotos y credenciales filtradas dentro de la organización, seguido de un cambio forzado en sistemas internos, puede marcar la diferencia. Después, queda lo más ingrato: elevar la monitorización para detectar señales posteriores al acceso, como inicios de sesión desde ubicaciones inusuales, cambios no previstos en la configuración o alta de nuevos administradores.

Más información

• The Hacker News – FortiBleed Targeted FortiGate Firewalls in 110 Million-Credential Harvesting Operation : https://thehackernews.com/2026/06/fortibleed-targeted-fortigate.html
• Dark Reading – FortiBleed Attackers Turn Firewalls Into Credentials Stealers : https://www.darkreading.com/cyberattacks-data-breaches/fortibleed-attackers-firewalls-credentials-stealers
• UK National Cyber Security Centre (NCSC) – Alert: NCSC issues advice following global targeting of Fortinet firewalls and VPN gateways (PDF) : https://www.ncsc.gov.uk/sites/default/files/2026-06/Alert-NCSC-issues-advice-following-global-targeting-of-Fortinet-firewalls-and-VPN-gateways_3.pdf

La entrada FortiBleed pone en el punto de mira a FortiGate para robar credenciales a gran escala se publicó primero en Una Al Día.

Varias organizaciones que utilizan Cisco Unified Communications Manager (Unified CM), y su edición Cisco Unified Communications Manager Session Management Edition (Unified CM SME), afrontan estos días una prioridad clara: revisar si tienen activado WebDialer y aplicar las correcciones publicadas por Cisco. El motivo no es teórico. Ya se han visto intentos de explotación en campañas activas vinculadas a CVE-2026-20230, un fallo con severidad alta que el fabricante califica como Critical.

El defecto encaja en una categoría conocida pero muy peligrosa en entornos corporativos: SSRF (Server-Side Request Forgery). En la práctica, un atacante remoto sin autenticar puede forzar al servidor a realizar solicitudes HTTP manipuladas a destinos internos o controlados, debido a una validación insuficiente en peticiones concretas. En este caso el alcance va más allá de ‘mirar’ recursos internos: la cadena descrita permite escribir ficheros arbitrarios en el sistema operativo subyacente. Esa capacidad no equivale automáticamente a tomar el control total, pero sí deja el terreno preparado para una escalada de privilegios que acabe en ejecución como root.

El detalle que marca la diferencia en la exposición es WebDialer. La explotación depende de que el servicio esté habilitado, y en muchas instalaciones viene desactivado por defecto, lo que reduce el riesgo para parte del parque. Aun así, basta una configuración heredada o un despliegue con requisitos específicos para abrir la puerta. El interés de los atacantes crece cuando existe una prueba de concepto pública, y en este caso ya circula.

Cisco publicó actualizaciones el 3 de junio de 2026. No hay soluciones alternativas que mitiguen por completo el fallo sin actualizar, así que la recomendación pasa por parchear. Mientras llega la ventana de mantenimiento, deshabilitar WebDialer si no resulta imprescindible recorta superficie expuesta.

Para equipos de seguridad, la respuesta práctica empieza por localizar instancias de Unified CM y Unified CM SME con WebDialer activo, especialmente en entornos accesibles desde redes no confiables. Después toca aplicar las versiones corregidas: en Unified CM 14, la ruta indicada pasa por 14SU6. En Unified CM 15, conviene planificar la actualización a 15SU5, prevista para septiembre de 2026, o valorar COP1 si encaja con el entorno.

La parte menos visible, y a menudo la más útil, está en la verificación posterior. Conviene revisar registros y telemetría en busca de patrones compatibles con SSRF y con eventos de escritura de ficheros inusuales, además de elevar la monitorización en servidores de comunicaciones, que suelen quedar fuera del foco habitual. Y, como medida defensiva transversal, limitar el acceso de red a interfaces y servicios de administración, acotándolo a segmentos de gestión, reduce el margen de maniobra si alguien intenta repetir la jugada.

Más información

• BleepingComputer – Cisco Unified CM flaw CVE-2026-20230 now exploited in attacks : https://www.bleepingcomputer.com/news/security/cisco-unified-cm-flaw-cve-2026-20230-now-exploited-in-attacks/
• Cisco – Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-ssrf-cXPnHcW
• SecurityWeek – Hackers Exploiting Cisco Unified CM Vulnerability : https://www.securityweek.com/hackers-exploiting-cisco-unified-cm-vulnerability/

La entrada Explotan en ataques un fallo crítico en Cisco Unified CM con WebDialer habilitado se publicó primero en Una Al Día.

Varias organizaciones que utilizan Cisco Unified Communications Manager (Unified CM), y su edición Cisco Unified Communications Manager Session Management Edition (Unified CM SME), afrontan estos días una prioridad clara: revisar si tienen activado WebDialer y aplicar las correcciones publicadas por Cisco. El motivo no es teórico. Ya se han visto intentos de explotación en campañas activas vinculadas a CVE-2026-20230, un fallo con severidad alta que el fabricante califica como Critical.

El defecto encaja en una categoría conocida pero muy peligrosa en entornos corporativos: SSRF (Server-Side Request Forgery). En la práctica, un atacante remoto sin autenticar puede forzar al servidor a realizar solicitudes HTTP manipuladas a destinos internos o controlados, debido a una validación insuficiente en peticiones concretas. En este caso el alcance va más allá de ‘mirar’ recursos internos: la cadena descrita permite escribir ficheros arbitrarios en el sistema operativo subyacente. Esa capacidad no equivale automáticamente a tomar el control total, pero sí deja el terreno preparado para una escalada de privilegios que acabe en ejecución como root.

El detalle que marca la diferencia en la exposición es WebDialer. La explotación depende de que el servicio esté habilitado, y en muchas instalaciones viene desactivado por defecto, lo que reduce el riesgo para parte del parque. Aun así, basta una configuración heredada o un despliegue con requisitos específicos para abrir la puerta. El interés de los atacantes crece cuando existe una prueba de concepto pública, y en este caso ya circula.

Cisco publicó actualizaciones el 3 de junio de 2026. No hay soluciones alternativas que mitiguen por completo el fallo sin actualizar, así que la recomendación pasa por parchear. Mientras llega la ventana de mantenimiento, deshabilitar WebDialer si no resulta imprescindible recorta superficie expuesta.

Para equipos de seguridad, la respuesta práctica empieza por localizar instancias de Unified CM y Unified CM SME con WebDialer activo, especialmente en entornos accesibles desde redes no confiables. Después toca aplicar las versiones corregidas: en Unified CM 14, la ruta indicada pasa por 14SU6. En Unified CM 15, conviene planificar la actualización a 15SU5, prevista para septiembre de 2026, o valorar COP1 si encaja con el entorno.

La parte menos visible, y a menudo la más útil, está en la verificación posterior. Conviene revisar registros y telemetría en busca de patrones compatibles con SSRF y con eventos de escritura de ficheros inusuales, además de elevar la monitorización en servidores de comunicaciones, que suelen quedar fuera del foco habitual. Y, como medida defensiva transversal, limitar el acceso de red a interfaces y servicios de administración, acotándolo a segmentos de gestión, reduce el margen de maniobra si alguien intenta repetir la jugada.

Más información

• BleepingComputer – Cisco Unified CM flaw CVE-2026-20230 now exploited in attacks : https://www.bleepingcomputer.com/news/security/cisco-unified-cm-flaw-cve-2026-20230-now-exploited-in-attacks/
• Cisco – Cisco Unified Communications Manager Server-Side Request Forgery Vulnerability : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-ssrf-cXPnHcW
• SecurityWeek – Hackers Exploiting Cisco Unified CM Vulnerability : https://www.securityweek.com/hackers-exploiting-cisco-unified-cm-vulnerability/

La entrada Explotan en ataques un fallo crítico en Cisco Unified CM con WebDialer habilitado se publicó primero en Una Al Día.

Una nueva campaña de cadena de suministro ha puesto el foco en npm con paquetes maliciosos que se camuflan como utilidades relacionadas con PostCSS y activan su carga durante un gesto tan cotidiano como un npm install. El gancho no está en un exploit sofisticado, sino en una práctica habitual del ecosistema: los scripts de ciclo de vida, como postinstall, que pueden ejecutarse automáticamente al instalar dependencias.

El patrón encaja con ataques recientes contra repositorios de paquetes: el código se dispara en el momento de la instalación, contacta con una infraestructura de mando y control (C2) y baja una segunda fase adaptada al sistema operativo. En este caso, el objetivo principal se concentra en Windows, donde la cadena de infección suele apoyarse en PowerShell para descargar componentes, lanzar la carga útil y preparar mecanismos de persistencia. El resultado es un troyano de acceso remoto (RAT), una herramienta que permite al atacante controlar el equipo, ejecutar comandos y moverse por el sistema con discreción.

El impacto no se limita al portátil del desarrollador. Los entornos de CI/CD también quedan en la diana porque instalan dependencias de forma desatendida y suelen manejar tokens, credenciales de despliegue y accesos a servicios internos. Un único paquete contaminado en el árbol de dependencias puede convertir un pipeline en un punto de entrada, con capacidad para escalar el incidente hacia repositorios, artefactos de compilación o infraestructura.

Los análisis describen además rutinas pensadas para complicar el trabajo posterior: tras ejecutarse, algunos paquetes eliminan o sustituyen metadatos y señales visibles para pasar más desapercibidos en node_modules. Aun así, la campaña deja rastros aprovechables para caza proactiva, como dominios, IPs, rutas de descarga y ficheros temporales asociados al descargador y a la carga final.

La respuesta defensiva pasa por medidas poco glamurosas, pero eficaces. Conviene inventariar dependencias y revisar el árbol en busca de nombres que imiten librerías populares o incorporaciones recientes sin justificación técnica. También ayuda fijar versiones exactas en package.json y evitar rangos con ^ o ~, que abren la puerta a actualizaciones automáticas no revisadas. Cuando el proyecto lo permita, se puede desactivar la ejecución de scripts durante la instalación con opciones como ignore-scripts, y reforzar dependencias transitivas con overrides.

En paralelo, las organizaciones deberían revisar logs de estaciones y pipelines para detectar instalaciones sospechosas, controlar el tráfico saliente hacia infraestructura asociada a campañas de npm, y, si existe la sospecha de ejecución, aislar equipos y rotar secretos. En ataques de este tipo, el coste real suele llegar después: cuando el atacante ya ha tenido tiempo de leer tokens, moverse por la red y persistir donde menos se mira.

Más información

• The Hacker News – Google Attributes Axios npm Supply Chain Attack to North Korean Group UNC1069 : https://thehackernews.com/2026/04/google-attributes-axios-npm-supply.html
• Microsoft Security Blog – Mitigating the Axios npm supply chain compromise : https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/
• ReversingLabs – Malicious npm packages use fake install logs to load RAT : https://www.reversinglabs.com/blog/npm-fake-install-logs-rat

La entrada Paquetes maliciosos en npm se hacen pasar por herramientas de PostCSS para instalar un RAT en Windows se publicó primero en Una Al Día.

La campaña AryStinger ha puesto en el punto de mira a routers domésticos descatalogados, y también a algunos NAS, para convertirlos en una infraestructura distribuida de reconocimiento y proxy que sirve de apoyo a ataques posteriores. No se trata del patrón clásico de botnet enfocada al DDoS. Aquí el valor está en otro sitio: ocultar el origen del tráfico, escanear Internet con miles de direcciones residenciales y preparar el terreno antes de una intrusión.

Los equipos más afectados comparten un denominador común: chips Realtek RTL819X, muy extendidos en el mercado entre 2012 y 2015. Dentro de ese grupo, los routers D-Link dominan el recuento, con el DIR-850L como protagonista claro, alrededor del 75% de los dispositivos comprometidos. También aparecen otros modelos de la familia DIR, como DIR-817L(W), DIR-818L(W), DIR-822, DIR-823, DIR-868L, DIR-880L, DIR-885L, DIR-890L y DIR-895L. La distribución geográfica se concentra en Corea del Sur y China, seguida a cierta distancia por Suecia, Malasia y Singapur.

La cadena de infección inicial aprovecha vulnerabilidades antiguas de ejecución remota de código. En el ecosistema Linksys aparece CVE-2013-3307, y en varios routers D-Link destaca CVE-2016-5681, un fallo documentado hace años en la superficie web de administración de estos equipos. Ese detalle explica la escala: muchos de estos dispositivos ya no reciben firmware actualizado, o directamente siguen expuestos a Internet con la administración remota activa.

Una vez dentro, los nodos comprometidos ejecutan tareas a demanda: escaneo masivo de DNS, enumeración de servicios, descubrimiento de activos y tunelización de tráfico para actuar como trampolín. Los resultados acaban en manos del operador, que puede usar esa información como fase previa para ataques más selectivos. La comunicación con el servidor de mando y control se apoya en HTTP/HTTPS y utiliza datos en Protobuf ofuscados con XOR. En otra variante, escrita en Go, el malware añade compresión gzip.

La persistencia también deja pistas. En routers se ha visto la instalación de Dropbear SSH escuchando en un puerto fijo, el 2332, una forma de mantener acceso incluso si el usuario reinicia el dispositivo. En el caso de QNAP, se observó una segunda variante que intenta aprovechar CVE-2025-11837, una inyección de código vinculada a QNAP Malware Remover y corregida en noviembre de 2025, además de la presencia de herramientas como gs-netcat.

Para usuarios y pequeñas oficinas, las medidas pasan menos por milagros y más por higiene básica: sustituir routers en fin de vida, desactivar la administración remota si no resulta imprescindible y vigilar conexiones salientes a dominios asociados a la campaña, como ajb8.com. En entornos con algo más de control, conviene buscar binarios no autorizados en /tmp/bin, comprobar procesos con nombres como syswapd0h o syswapd0w, y verificar si aparece un Dropbear inesperado en el puerto 2332. En los modelos D-Link compatibles con parches, actualizar el firmware sigue siendo la barrera más directa frente a CVE-2016-5681. Y en QNAP, mantener al día Malware Remover resulta clave para cerrar la puerta a CVE-2025-11837.

Más información

• thehackernews.com – AryStinger Malware Infects 4,300 Legacy Routers to Build Reconnaissance Proxy Network : https://thehackernews.com/2026/06/arystinger-malware-infects-4300-legacy.html
• QiAnXin XLab – More Than 4,000 Legacy Routers Compromised by AryStinger, Turned into Global Attack Proxies for Hackers : https://blog.xlab.qianxin.com/arystinger-botnet-hijacks-legacy-routers-for-global-attacks-en/
• NIST NVD – CVE-2016-5681 Detail : https://nvd.nist.gov/vuln/detail/CVE-2016-5681
• CERT/CC – VU#332115 – D-Link routers contain buffer overflow vulnerability : https://www.kb.cert.org/vuls/id/332115
• SecurityWeek – D-Link Patches Critical Flaw in DIR Routers : https://www.securityweek.com/d-link-patches-critical-flaw-dir-routers/

La entrada AryStinger convierte 4.300 routers antiguos en una red de reconocimiento y proxies para ataques se publicó primero en Una Al Día.