Los equipos que operan resolutores DNS con validación DNSSEC tienen una actualización prioritaria sobre la mesa: NLnet Labs ha corregido en Unbound 1.26.1 una vulnerabilidad crítica, identificada como CVE-2026-81642, que puede tumbar el servicio y, en determinadas condiciones, permitir ejecución remota de código. El problema afecta a Unbound en todas sus versiones hasta la 1.26.0 inclusive, un rango amplio para un componente habitual en infraestructura y servicios internos.

El fallo reside en el validador DNSSEC al procesar registros DNSKEY. En concreto, el código puede sufrir un desbordamiento de búfer durante el manejo de datos que llegan desde respuestas DNS, un escenario delicado porque el tráfico entra por red y el proceso suele ejecutarse de forma continua. El fabricante ha asignado a la vulnerabilidad una puntuación CVSS 4.0 de 9.1, con vector de red, sin privilegios y sin interacción del usuario, un perfil típico de defectos que conviene cerrar cuanto antes.

El ataque requiere que el adversario controle una zona DNS maliciosa y consiga que el resolutor vulnerable la consulte. Eso puede ocurrir si el resolutor acepta consultas desde redes no confiables, si resuelve para usuarios externos, o si un atacante logra inducir consultas hacia su dominio. En el peor caso, la entrada manipulada no solo provoca denegación de servicio, también deja abierta la posibilidad de RCE mediante datos que controla el atacante. Aun así, en el momento de la divulgación no constaba explotación pública activa en ataques reales.

Unbound 1.26.1 introduce una corrección concreta: añade una comprobación adecuada de la capacidad del búfer después de la descompresión y antes de escribir, un punto crítico para evitar que los datos sobrepasen los límites de memoria. El mismo lanzamiento agrupa además otras ocho correcciones de seguridad, entre ellas CVE-2026-82717, con corrupción de heap al sintetizar CNAME, y CVE-2026-81634, con posible desbordamiento de heap durante la canonización DNSSEC. En conjunto, el paquete no solo apunta a evitar caídas, también a reducir superficies de ataque que podrían degradar el servicio o derivar en comportamientos inesperados.

La recomendación operativa es directa: actualizar a Unbound 1.26.1. Si la ventana de mantenimiento no permite hacerlo de inmediato, conviene aplicar el parche oficial de CVE-2026-81642 sobre el árbol de fuentes con patch -p1, recompilar e instalar, y planificar cuanto antes la adopción del conjunto completo de correcciones. También merece la pena inventariar instancias de Unbound integradas en appliances, contenedores o paquetes de distribución, porque no siempre resulta evidente qué versión corre realmente y si incluye el parche equivalente.

Más información

• The Hacker News – Critical Unbound DNSSEC Validator Flaw Could Allow RCE via a Malicious DNS Zone : https://thehackernews.com/2026/09/critical-unbound-dnssec-validator-flaw.html
• NLnet Labs – Unbound Security Advisories : https://nlnetlabs.nl/projects/unbound/security-advisories/
• Openwall oss-security – Unbound: 1.26.1 addresses multiple CVE items : https://www.openwall.com/lists/oss-security/2026/09/16/3

La entrada Unbound corrige un fallo crítico en DNSSEC que puede abrir la puerta a ejecución remota de código se publicó primero en Una Al Día.

Cisco ha publicado correcciones urgentes para Cisco Identity Services Engine (ISE) y Cisco ISE Passive Identity Connector (ISE-PIC) tras detectar un zero-day de severidad máxima que ya se explota en ataques reales. El problema, registrado como CVE-2026-76460 y puntuado con CVSS 10.0, afecta a infraestructuras que muchas organizaciones usan como pieza central para controlar quién entra en la red, con qué permisos y desde qué dispositivo.

La vulnerabilidad nace en un control de autenticación insuficiente en un endpoint del API. En la práctica, un atacante remoto puede entrar sin credenciales y saltarse la autenticación en el API gateway, con la posibilidad de obtener acceso no autorizado al sistema y eludir la interfaz de administración web. A partir de ahí, el escenario se complica: si el atacante encadena la intrusión con acciones posteriores, puede llegar a ejecutar comandos con privilegios de root, un nivel de control que facilita borrar huellas, ocultar indicadores de compromiso y manipular la plataforma.

El alcance no depende de ajustes concretos. Cisco reconoce que el fallo afecta a ISE y ISE-PIC independientemente de la configuración, y también deja claro un punto incómodo para los equipos de seguridad: no existen soluciones alternativas que eliminen el riesgo. La mitigación real pasa por instalar versiones corregidas.

Cisco ya ha publicado parches para varias ramas: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 y 3.5 Patch 4. La rama Cisco ISE 3.0 ha llegado al fin de mantenimiento de software, así que quienes sigan en esa versión deben planificar una migración a una rama soportada que incluya la corrección.

Mientras se completa la actualización, la compañía recomienda medidas de contención y, sobre todo, verificación. Conviene revisar el ise-kong access.log y los access.log de cada nodo para localizar nombres de usuario sospechosos en peticiones al gateway del API. Esa revisión gana valor cuando se cruza con logs externos, como los del perímetro de red y el firewall, porque ayudan a detectar cargas y descargas inesperadas hacia direcciones IP externas.

Si aparecen indicios sólidos de explotación o compromiso, la respuesta recomendada sube de nivel: reinstalar los nodos afectados y restaurar la configuración desde copias de seguridad. Además, Cisco plantea aplicar iACLs para limitar al mínimo el tráfico de gestión y del plano de control, una forma de reducir superficie de ataque mientras los parches se despliegan en entornos donde parar servicios no siempre resulta trivial.

Más información

• BleepingComputer – Cisco warns of max severity ISE zero-day exploited in attacks : https://www.bleepingcomputer.com/news/security/cisco-warns-of-identity-service-engine-zero-day-exploited-in-attacks/
• Cisco – Cisco Identity Services Engine Authentication Bypass Vulnerability : https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html

La entrada Cisco corrige un zero-day crítico en ISE que ya se explota en ataques se publicó primero en Una Al Día.

Los atacantes están aprovechando una vulnerabilidad crítica en el plugin premium WooCommerce Wholesale Lead Capture para comprometer sitios WordPress y tomar control del servidor. El fallo, identificado como CVE-2026-27540 y valorado como crítico (CVSS 9.8), permite la subida arbitraria de archivos sin necesidad de autenticación, un punto de entrada perfecto para plantar una web shell PHP y ejecutar comandos de forma remota.

El alcance es claro: quedan expuestas las instalaciones con WooCommerce Wholesale Lead Capture 2.0.3.1 y versiones anteriores. La corrección ya existe, porque el desarrollador publicó WooCommerce Wholesale Lead Capture 2.0.3.2 el 20 de febrero de 2026, pero la actividad reciente muestra que muchos sitios siguen sin actualizar. En la práctica, un solo plugin desactualizado basta para abrir una puerta trasera en una web que, por lo demás, podría estar bien mantenida.

El vector técnico se apoya en una acción AJAX accesible sin iniciar sesión: wwlc_file_upload_handler. Ese endpoint valida extensiones con una lista permitida que el propio atacante puede manipular mediante el parámetro file_settings, lo que le permite colar php como tipo aceptado. A partir de ahí, el resto es rutina para un atacante: subir un archivo como shell.php, ejecutarlo desde el navegador y usarlo para desplegar más carga maliciosa, robar credenciales o instalar persistencia.

Los intentos de explotación no son anecdóticos. Se han registrado y bloqueado más de 100.000 intentos desde junio de 2026, con picos especialmente marcados entre el 4 y el 17 de junio, además del 1 de julio y el 30 de agosto. La telemetría también apunta a IPs reincidentes capaces de generar decenas de miles de solicitudes, un patrón típico de campañas automatizadas que barren Internet a la caza de instalaciones vulnerables.

La prioridad pasa por actualizar de inmediato a 2.0.3.2 o posterior. Si no es posible, conviene desactivar o retirar el plugin hasta aplicar el parche, porque el fallo permite entrar sin credenciales. También toca revisar el sistema de archivos en busca de .php inesperados o recientes, con especial atención a wp-content/uploads, una ruta donde no deberían aparecer scripts ejecutables. En paralelo, resulta útil auditar peticiones a /wp-admin/admin-ajax.php con action=wwlc_file_upload_handler y cruzarlas con picos de actividad, errores 200 inusuales o cargas con nombres sospechosos.

En el perímetro, un WAF puede frenar parte del ruido si se aplican reglas específicas contra cargas maliciosas en admin-ajax.php y si se bloquean IPs con comportamiento repetitivo. Si ya hay indicios sólidos de intrusión, el problema casi nunca se resuelve borrando un archivo suelto: conviene comprobar si existen cuentas de administrador desconocidas, rotar credenciales y, en escenarios de compromiso claro, restaurar desde una copia de seguridad verificada tras endurecer la instalación, porque las backdoors pueden quedar ocultas en múltiples ubicaciones.

Más información

• The Hacker News – Attackers Exploit WooCommerce Wholesale Lead Capture Flaw to Plant PHP Web Shells : https://thehackernews.com/2026/09/attackers-exploit-woocommerce-wholesale.html?m=1
• BleepingComputer – Hackers target WordPress sites via third-party WooCommerce plugin : https://www.bleepingcomputer.com/news/security/hackers-target-wordpress-sites-via-third-party-woocommerce-plugin/

La entrada Atacan webs WordPress con un fallo crítico en WooCommerce Wholesale Lead Capture se publicó primero en Una Al Día.

Entre el 15 de agosto y el 8 de septiembre de 2026, varias instancias autoalojadas de JFrog Artifactory han recibido ataques que terminan con control administrativo, creación de cuentas persistentes y despliegue de backdoors. La ventana temporal importa porque no hablamos de una prueba de concepto aislada, sino de intrusiones completas que, en algunos casos, han pasado del acceso inicial a un nuevo administrador en menos de cinco minutos.

La primera vía se apoya en el encadenamiento de CVE-2026-42018 y CVE-2026-42016. El fallo CVE-2026-42018 permite obtener un token interno asociado al usuario anónimo sin iniciar sesión, incluso si el acceso anónimo está desactivado. Con ese punto de apoyo, CVE-2026-42016 facilita cambiar un token de bajo privilegio por otro con alcance de administrador: la validación comprueba firma y emisor, pero no el alcance real del token, un detalle que convierte un acceso mínimo en una llave maestra.

Ese salto tiene otra consecuencia incómoda: ciertas acciones administrativas pueden quedar reflejadas en los registros como token:anonymous, no como una cuenta nominal. Para los equipos de seguridad, eso complica el análisis forense y puede retrasar la detección, sobre todo si el servidor está expuesto a Internet y gestiona repositorios con alto valor para el desarrollo.

Los atacantes han usado después el propio ecosistema de Artifactory para afianzarse. Se han instalado plugins Groovy maliciosos mediante el framework de plugins, lo que habilita ejecución de código en el servidor. A partir de ahí, se han ejecutado comandos de shell mediante un endpoint de ejecución de plugins, con tareas típicas de reconocimiento y enumeración de ficheros. También aparece un dropper que descarga un binario por HTTP, lo escribe en rutas de escritura global como /tmp y abre un canal de mando y control. En varios casos, el despliegue culmina con un backdoor en Rust orientado a control remoto.

En paralelo, se ha explotado de forma independiente CVE-2026-82329 entre el 1 y el 8 de septiembre de 2026. Este fallo, catalogado como bypass de autenticación crítico con CVSS 9.8, permite obtener privilegios administrativos sin necesidad de encadenar otros defectos y afecta especialmente a configuraciones por defecto en Artifactory autoalojado. La explotación observada incluye la creación de tokens de administrador y la enumeración de usuarios, grupos y conjuntos de credenciales, un patrón que encaja con preparativos para persistencia y movimientos posteriores.

La prioridad pasa por actualizar. Los parches de CVE-2026-82329 llegan en 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 y 7.161.20, según la rama 7.x desplegada. En el caso de la cadena CVE-2026-42018 más CVE-2026-42016, basta con corregir al menos uno de los dos fallos para romper el ataque, aunque la recomendación práctica es aplicar todas las correcciones disponibles y priorizar las instancias expuestas a Internet.

Si actualizar no resulta inmediato, existe una contención rápida para CVE-2026-82329: configurar una extra join key aleatoria en system.yaml. Aun así, conviene actuar como si el servidor ya estuviera bajo presión: revisar los audit logs en busca de acciones administrativas asociadas a token:anonymous y a la creación de nuevas cuentas con privilegios elevados, rotar credenciales y tokens potencialmente expuestos, y auditar cambios en usuarios, grupos y topologías de acceso federado.

El control técnico no debe quedarse en la aplicación. Toca inspeccionar el entorno en busca de plugins Groovy no autorizados y eliminar extensiones sospechosas, además de comprobar el sistema de ficheros y tareas programadas para localizar binarios en rutas como /tmp y señales de persistencia o conexiones de mando y control. Y hay un último frente que preocupa especialmente en equipos DevOps: verificar la integridad de repositorios y artefactos críticos y reforzar controles de publicación y promoción en la cadena CI/CD, porque un Artifactory comprometido no solo expone secretos, también puede convertirse en un punto de inyección de componentes maliciosos en software legítimo.

Más información

• Securitydone – Attackers Chain JFrog Artifactory Flaws to Gain Admin Control and Plant Backdoors : https://securitydone.com/attackers-chain-jfrog-artifactory-flaws-to-gain-admin-control-and-plant-backdoors/
• The Hacker News – Attackers Exploit Critical JFrog Artifactory Flaw to Mint Admin Tokens Days After Disclosure : https://thehackernews.com/2026/09/attackers-exploit-critical-jfrog.html?m=1
• SecurityWeek – Critical JFrog Artifactory Vulnerability Reportedly Exploited in the Wild : https://www.securityweek.com/critical-jfrog-artifactory-vulnerability-reportedly-exploited-in-the-wild/
• JFrog – JFrog Security Advisories : https://docs.jfrog.com/releases/docs/jfrog-security-advisories

La entrada Una cadena de fallos en JFrog Artifactory da a atacantes control admin y puerta trasera en minutos se publicó primero en Una Al Día.

Trezor ha comunicado una intrusión en un proveedor externo de correo que utiliza para sus comunicaciones con clientes y la ha vinculado con una campaña de phishing dirigida a usuarios de sus hardware wallets. La compañía sostiene que los atacantes se apoyaron en infraestructura que aparentaba ser legítima para aumentar la credibilidad del mensaje y acelerar el clic, un riesgo especialmente delicado cuando el objetivo final suele ser la frase semilla.

Los correos maliciosos llegaron con el asunto ‘Critical Security Alert: STM32 Entropy Vulnerability’ y se presentaban como si fuesen avisos oficiales de soporte. El texto intentaba activar el modo pánico: aseguraba, de forma falsa, que existía una vulnerabilidad de hardware en los microcontroladores STM32 que reduciría la entropía y permitiría a un atacante reconstruir la semilla o facilitar ataques de fuerza bruta. No hay CVE publicados que respalden esa alerta tal y como se describe en el email, y el patrón encaja con la táctica clásica de suplantación de marca, miedo, urgencia y un enlace que lleva a una web preparada para robar secretos.

Trezor afirma que ya ha desactivado el dominio empleado en la campaña y mantiene la investigación para aclarar cómo se produjo el acceso y por qué el envío logró el nivel de ‘apariencia oficial’ que describen los usuarios. El caso ilustra un problema recurrente: cuando un incidente nace en un tercero, como un proveedor de email marketing o servicios de correo, el atacante puede enviar mensajes que pasan filtros habituales y que el usuario interpreta como parte del flujo normal de la marca.

La campaña también se beneficia del contexto. En el sector han circulado alertas recientes sobre problemas de generación de entropía en productos de otros fabricantes, y ese ruido informativo hace más verosímil un aviso técnico aunque sea falso. Investigadores de seguridad han señalado indicios de que correos similares podrían haber llegado a usuarios de BitBox, una pista que apunta a un posible patrón de compromiso en proveedores compartidos por varias compañías del ecosistema.

La recomendación práctica no cambia, pero conviene repetirla: no hay ninguna situación legítima en la que Trezor necesite tu seed phrase por correo ni en una web. Ante un mensaje no solicitado que exija actuar ‘ya’, lo sensato es no pinchar enlaces ni descargar adjuntos, verificar el aviso en los canales oficiales del fabricante y, si alguien ya introdujo credenciales o datos sensibles, actuar como si existiera compromiso, revocar accesos donde aplique y mover fondos solo mediante procedimientos verificados y desde interfaces oficiales. En empresas y equipos de seguridad, este incidente refuerza la necesidad de playbooks que contemplen fallos en terceros y controles antiphishing más agresivos, con filtrado por dominios, análisis de URLs y reglas que detecten asuntos y textos recurrentes de campañas como esta.

Más información

• BleepingComputer – Trezor warns users of email provider breach, phishing attacks : https://www.bleepingcomputer.com/news/security/trezor-warns-users-of-email-provider-breach-phishing-attacks/
• Decrypt – Bitcoin Wallet Maker Trezor Says Hackers Breached Its Email Provider : https://decrypt.co/377831/bitcoin-wallet-trezor-hackers-breach-email
• Trezor Blog – Coldcard vulnerability: Trezor devices are not affected : https://trezor.io/blog/news/coldcard-vulnerability-trezor-devices-are-not-affected

La entrada Trezor alerta de una brecha en su proveedor de correo y una oleada de phishing contra sus clientes se publicó primero en Una Al Día.

Google ha lanzado una actualización urgente para Chrome tras detectar la explotación activa de CVE-2026-85046, un día cero de severidad alta en V8, el motor de JavaScript y WebAssembly del navegador. El fallo permite que un atacante remoto ejecute código arbitrario dentro del sandbox si la víctima visita una página HTML manipulada, un escenario típico en campañas que combinan enlaces, malvertising o páginas comprometidas.

El defecto se encuadra en una confusión de tipos en V8, una clase de vulnerabilidad que suele abrir la puerta a primitivas peligrosas, como lectura y escritura arbitrarias en memoria dentro del heap de JavaScript. En este caso, el análisis técnico apunta al compilador Maglev y a optimizaciones asociadas a Array.prototype.sort, donde ciertas decisiones de inlining y especialización pueden dejar al motor en un estado inconsistente. Ese desajuste acaba traduciéndose en un comportamiento explotable, con el que un atacante puede construir una cadena de explotación fiable.

Google ha corregido el problema en la rama estable de escritorio con las versiones 152.0.7977.82 y 152.0.7977.83 para Windows y macOS, y 152.0.7977.82 para Linux. La actualización no solo tapa este agujero: también incluye correcciones para un total de 12 vulnerabilidades, lo que refuerza el carácter de parche recomendado cuanto antes.

La compañía mantiene su política de limitar los detalles de algunos fallos hasta que una mayoría de usuarios se actualiza, con el objetivo de frenar la explotación adicional. El investigador Salvatore Gulizia, conocido como Serotav, reportó el fallo el 4 de agosto de 2026 y recibió una recompensa de 1.000 dólares. El vector CVSS publicado marca 8.8, con interacción del usuario requerida, algo coherente con un ataque que necesita que la víctima cargue contenido web preparado.

Para los usuarios, la mitigación práctica es sencilla: actualizar Chrome y, sobre todo, reiniciar el navegador para que la versión parcheada quede realmente en ejecución. En entornos corporativos conviene acelerar la gestión de parches, comprobar el inventario de versiones desplegadas y priorizar equipos con mayor exposición. También deben estar atentos los navegadores basados en Chromium, como Microsoft Edge, Brave, Opera o Vivaldi, que necesitan integrar la corrección en sus propias actualizaciones cuando sus fabricantes las publiquen.

Más información

• The Hacker News – Google Releases Chrome Update to Patch Actively Exploited V8 Zero-Day : https://thehackernews.com/2026/09/google-releases-chrome-update-to-patch.html
• Chrome Releases (Google) – Stable Channel Update for Desktop (Thursday, September 3, 2026) : https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_01882797386.html
• OpenCVE – CVE-2026-85046 – V8 Type Confusion Allows Remote Code Execution in Google Chrome : https://opencve.alliance.unm.edu/cve/CVE-2026-85046
• Serotav Writeups – When Sorting Leads To Confusion : https://serotav.github.io/Writeups/v8/when-sorting-leads-to-confusion/

La entrada Google corrige un día cero de V8 en Chrome que se explota de forma activa se publicó primero en Una Al Día.

La vulnerabilidad crítica CVE-2026-82329 en JFrog Artifactory ya se explota en ataques reales y permite a un atacante no autenticado emitir o forjar tokens de administrador con solo tener acceso de red a la instancia. El problema afecta a instalaciones self managed cuando mantienen la configuración por defecto, una combinación habitual en entornos donde el repositorio se despliega con prisas y luego queda expuesto a Internet.

El fallo abre la puerta a un bypass de autenticación con resultado directo, privilegios de administrador. A partir de ahí, el intruso puede moverse con comodidad por el sistema: enumerar usuarios, grupos y conjuntos de credenciales, revisar configuraciones sensibles e incluso obtener visibilidad sobre topologías federadas. También puede leer artefactos almacenados y tocar ajustes de seguridad, un cóctel especialmente delicado en organizaciones que usan Artifactory como pieza central del ciclo de construcción y publicación de software.

El escenario más dañino llega cuando el repositorio alimenta de forma automática a herramientas de CI/CD y despliegue. Si un atacante sustituye un paquete interno, una imagen o una dependencia que la empresa considera confiable, el cambio puede propagarse aguas abajo: desde los runners de integración hasta entornos de producción. Es el patrón clásico de incidente en cadena de suministro, con un punto único de compromiso que contamina múltiples sistemas.

JFrog Cloud ya estaba protegido, pero en local la corrección exige actualizar a una de las versiones parcheadas en cada rama: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. Aun así, aplicar el parche no basta si el atacante ya emitió tokens, porque la validez, la caducidad y la revocación de esos tokens funcionan de forma independiente a la actualización del binario.

La respuesta recomendada pasa por priorizar las instancias expuestas a Internet y recortar superficie de ataque, limitando el acceso de red al servicio. Conviene revocar y reemitir tokens de administrador, revisar la política de caducidad, y rotar credenciales y secretos ligados a pipelines y sistemas que se autentican contra el repositorio. También toca mirar con lupa los registros de auditoría: generación anómala de tokens, enumeración masiva de usuarios y grupos, cambios de configuración y accesos atípicos a APIs administrativas.

En organizaciones que hayan mantenido el servicio expuesto durante la ventana vulnerable, lo prudente es tratar el entorno como potencialmente comprometido. Eso incluye validar la integridad de los artefactos publicados en ese periodo y comprobar si hubo sustituciones. En paralelo, se recomienda endurecer controles de supply chain en el despliegue, fijando imágenes a digests inmutables y verificando firmas y procedencia en el momento de desplegar, no solo cuando el artefacto se almacena. Por último, hay que extender la investigación a sistemas conectados, como runners de CI, gestores de despliegue y servidores de producción, para descartar persistencia o cambios maliciosos.

Más información

• BleepingComputer – Hackers exploit critical JFrog Artifactory flaw to forge admin tokens : https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-jfrog-artifactory-flaw-to-forge-admin-tokens/
• CSO Online – Exploited JFrog Artifactory bug puts software supply chain on alert : https://www.csoonline.com/article/4217534/exploited-jfrog-artifactory-bug-puts-software-supply-chain-on-alert.html

La entrada Atacantes aprovechan un fallo crítico en JFrog Artifactory para emitir tokens de administrador se publicó primero en Una Al Día.

Administradores de centralitas VoIP y responsables de sistemas tienen un nuevo frente urgente: una vulnerabilidad crítica en Sangoma Switchvox permite a un atacante ejecutar código de forma remota sin necesidad de credenciales y ya se ha detectado su uso en campañas activas desde el 30 de agosto de 2026. El fallo, identificado como CVE-2026-9586 y con una puntuación CVSS 9.3, afecta a despliegues expuestos a Internet y pone el foco en un producto muy común en entornos SMB.

El problema vive en el endpoint HTTP /pa, que acepta peticiones con XML. En ese flujo, el sistema incorpora el valor PhoneIP a consultas en PostgreSQL sin el saneado ni la parametrización adecuados, un patrón clásico de SQL injection catalogado como CWE-89. A partir de ahí, un atacante puede ejecutar consultas arbitrarias contra la base de datos y encadenar la intrusión hasta llegar a ejecución de comandos en el sistema, con el agravante de que la ruta técnica descrita otorga capacidad de actuar con privilegios de superusuario de PostgreSQL.

La actividad observada en ataques reales incluye la apertura de reverse shells y una fase de reconocimiento bastante directa: comandos codificados en Base64 para enumerar procesos y entender qué se ejecuta en el servidor. Entre los indicadores que se han vinculado a esta explotación aparece la dirección 176.65.148.184. También se han señalado trazas que pueden quedar reflejadas en /var/log/switchvox/db-quirks.log, un punto relevante para equipos que tengan acceso por SSH y necesiten confirmar si alguien intentó inyectar SQL o ejecutar acciones posteriores mediante técnicas habituales en estos escenarios.

La corrección no es nueva, pero el contexto sí lo es. Switchvox 8.4.0.2 incluye el parche y se publicó el 14 de julio de 2026, junto con otras correcciones adicionales en el portal web. La cronología conocida sitúa el aviso inicial al fabricante el 10 de abril de 2026, el lanzamiento del arreglo a mediados de julio y la explotación confirmada a finales de agosto. En paralelo, el alcance preocupa: se habla de miles de instancias accesibles desde Internet, con una concentración destacada en Estados Unidos.

La recomendación principal pasa por actualizar de inmediato a Switchvox 8.4.0.2 o superior y priorizar el parcheo en instalaciones expuestas a Internet, o en aquellas donde el servicio HTTP que incluye /pa resulte accesible desde redes no confiables. Hasta completar la actualización, conviene reducir superficie: restringir el acceso con listas de control, VPN o segmentación de red, y vigilar conexiones salientes anómalas, sobre todo intentos de reverse shell o tráfico hacia 176.65.148.184.

En paralelo, toca buscar señales de post explotación: procesos no habituales como nc, invocaciones de bash desde servicios web, o secuencias típicas de descarga y ejecución con curl. Si aparecen indicios de compromiso, la respuesta debe ir más allá del parche: rotación de secretos y credenciales asociados al sistema, incluidas credenciales que puedan facilitar suplantación de sesiones o acceso al portal de administración, y un análisis forense que determine hasta dónde llegó el atacante.

Más información

• The Hacker News – Attackers Exploit Critical Switchvox Flaw to Deploy Reverse Shells Without Credentials : https://thehackernews.com/2026/09/attackers-exploit-critical-switchvox.html
• Horizon3.ai – CVE-2026-9586: Sangoma Switchvox RCE : https://horizon3.ai/attack-research/disclosures/cve-2026-9586-sangoma-switchvox-rce/
• Sangoma Documentation – Switchvox Release Notes Version 8.4.0.2 (July 14, 2026) : https://sangomakb.atlassian.net/wiki/spaces/Switchvox/pages/1802371073/Switchvox%2B-%2BRelease+Notes+Version+8.4.0.2+July+14+2026
• OpenCVE – CVE-2026-9586 record : https://app.opencve.io/cve/CVE-2026-9586

La entrada Atacantes aprovechan un fallo crítico en Switchvox para abrir reverse shells sin credenciales se publicó primero en Una Al Día.

Los atacantes ya explotan de forma activa dos vulnerabilidades críticas en Langflow y Ruby on Rails, con un patrón claro: primero reconocimiento y robo de secretos, después movimientos para mantener el control del entorno con actividad de mando y control (C2). El problema no se limita a tumbar una aplicación. Estas plataformas suelen convivir con claves de cloud, tokens de API y accesos a servicios internos, así que un fallo expuesto a Internet puede abrir la puerta a un incidente mucho más amplio.

En Langflow, la vulnerabilidad CVE-2026-0768 permite ejecutar código Python arbitrario con permisos de root por una validación deficiente de la entrada. Las trazas observadas encajan con un actor que busca valor rápido: peticiones orientadas a volcar variables de entorno y a localizar credenciales. Aparecen consultas con nombres típicos de despliegues reales, como LANGFLOW_SUPERUSER, patrones del estilo OPENAI_API, y variables de AWS como AWS_ACCESS y AWS_SECRET. También se han visto intentos de lectura de rutas sensibles, como */root/.cache/langflow/secret_key, y comprobaciones de artefactos de acceso local, por ejemplo directorios .ssh o el tamaño de .bash_history.

El caso de Ruby on Rails resulta especialmente delicado por el encadenamiento posible hasta RCE. CVE-2026-66066, conocida como KindaRails2Shell, parte de una lectura arbitraria de ficheros que se activa cuando Active Storage procesa subidas de imágenes con libvips. La explotación exige dos condiciones: que la aplicación use Vips como procesador de variantes y que acepte subidas de imágenes de usuarios no confiables. El vector se apoya en discrepancias entre cómo interpreta ficheros Active Storage y cómo los procesa libvips, lo que puede terminar filtrando secretos del propio proceso de Rails.

Ese punto es crítico porque expone piezas que Rails usa para proteger sesiones y cifrar información. Entre los secretos potencialmente recuperables figuran secret_key_base, la Rails master key, credenciales de base de datos, claves de almacenamiento en la nube y tokens de servicios externos. Con ese material, un atacante puede pasar de leer ficheros a ejecutar código, pivotar hacia otros sistemas y persistir sin necesidad de credenciales válidas.

Los indicadores de campaña apuntan a una actividad distribuida. En Langflow se ha asociado tráfico principalmente a origen en Rusia, y se ha constatado afectación de canaries en Reino Unido. Para Rails, se ha observado actividad contra canaries en Singapur, Israel y Reino Unido, con indicios de C2 hacia un host en Israel desde una única IP localizada en Francia.

La respuesta defensiva pasa por priorizar inventario y exposición. Conviene identificar instancias públicas de Langflow y aplicaciones Rails con Active Storage, sobre todo si permiten subidas desde Internet. En Rails, la mitigación principal consiste en actualizar a 7.2.3.2, 8.0.5.1 o 8.1.3.1 según la rama, y revisar la cadena ruby-vips y libvips para asegurar el bloqueo de operaciones no seguras con contenido no confiable. Si la actualización no llega a tiempo, tiene sentido desactivar el procesado con Vips o restringir subidas de imágenes hasta completar el parcheado.

Dado el foco en secretos, también toca asumir posible exposición y actuar en consecuencia. Se recomienda rotar secret_key_base, la master key y cualquier credencial asociada a cloud, bases de datos o APIs. En paralelo, hay que revisar logs y telemetría en busca de lecturas sospechosas, como accesos a /proc/self/environ, config/master.key y rutas habituales de secretos, además de reforzar detección y respuesta ante comunicaciones de C2 y bloquear indicadores de infraestructura cuando se disponga de ellos.

Más información

• The Hacker News – Attackers Exploit Critical Langflow and Rails Flaws in Credential-Probing and C2 Activity : https://thehackernews.com/2026/09/attackers-exploit-critical-langflow-and.html
• Rapid7 – Rapid7 Analysis: KindaRails2Shell (CVE-2026-66066) : https://www.rapid7.com/blog/post/ra-kindarails2shell-technical-analysis-cve-2026-66066/

La entrada Explotan dos fallos críticos en Langflow y Ruby on Rails para robar secretos y desplegar mando y control se publicó primero en Una Al Día.

El ecosistema de Gitea, una de las plataformas más usadas para alojar repositorios Git en entornos propios, afronta un problema serio: a 27 de agosto de 2026 aún había 8.393 instancias expuestas a Internet que seguían vulnerables a CVE-2026-60004, una brecha crítica con capacidad de ejecución remota de comandos. La situación preocupa por una razón evidente: no hablamos de un fallo teórico, ya se ha observado explotación activa y la ventana para aplicar la corrección se ha estrechado.

El defecto combina dos piezas que, juntas, permiten al atacante ejecutar órdenes en el servidor. Por un lado, se puede abusar del endpoint diffpatch para inyectar contenido. Por otro, ese contenido puede desembocar en la instalación y ejecución de un Git hook controlado desde el propio repositorio. El resultado final es un servidor que ejecuta comandos sin que el atacante necesite acceso previo al sistema operativo.

La ejecución no ocurre con privilegios de administrador, pero sí con los permisos de la cuenta que lanza el servicio, es decir, el usuario del sistema con el que corre Gitea. En muchos despliegues eso basta para abrir una vía de exfiltración: secretos de configuración, credenciales de base de datos, tokens de integraciones, credenciales OAuth y variables sensibles del entorno. El alcance real depende del aislamiento del despliegue y del modelo de permisos, especialmente si la instancia corre en un host compartido o con permisos generosos.

La explotación exige acceso de escritura a un repositorio, aunque aquí aparece el punto débil habitual: el registro de usuarios abierto viene activado por defecto en muchas instalaciones. Eso permite que un atacante se registre, cree un repositorio y complete la cadena de ataque sin credenciales previas, más aún si la alta no pide confirmación por correo ni aplica controles anti automatización.

El proyecto corrigió CVE-2026-60004 en Gitea 1.27.1, publicada el 27 de julio de 2026. Aun así, el volumen de instancias sin actualizar sugiere una superficie de ataque amplia, con especial exposición en servicios que publican su forja directamente en la red. Además, CISA incorporó el fallo el 25 de agosto al catálogo Known Exploited Vulnerabilities (KEV), una señal clara de que la amenaza ya se mueve en campañas activas, y fijó el 28 de agosto como fecha límite de remediación para agencias federales de Estados Unidos.

En algunos incidentes descritos, los atacantes aprovecharon el acceso para desplegar software de minado de criptomonedas en instalaciones con Docker. Ese patrón encaja con lo habitual en servicios expuestos: una intrusión rápida, monetización inmediata y persistencia mínima. Aun así, no hay confirmación pública de un actor concreto o una campaña atribuida oficialmente.

La respuesta recomendada pasa por actualizar Gitea como mínimo a 1.27.1 y, si el entorno lo permite, priorizar 1.27.2 para reducir riesgo operativo. Conviene cerrar el registro abierto si no resulta imprescindible o endurecerlo con confirmación por correo y CAPTCHA. También toca revisar posibles indicadores de compromiso: creación o ejecución anómala de Git hooks, patrones inusuales en el endpoint diffpatch, procesos con consumo sostenido de CPU y descargas de binarios desde la propia instancia.

Si existe sospecha de intrusión, la higiene básica se vuelve urgente: rotación de credenciales y secretos, desde claves de configuración y credenciales de base de datos hasta tokens de integraciones y secretos OAuth. Y, para reducir exposición futura, lo sensato es limitar el acceso por red, permitir solo rangos necesarios y reforzar el control de permisos de escritura.

En despliegues con Docker, merece la pena revisar el aislamiento del contenedor, recortar conectividad saliente y ajustar redes y permisos, porque una ejecución de comandos dentro del contenedor puede convertirse en un problema mayor si el entorno deja puertas abiertas. Además, quienes usen cabeceras de autenticación de proxy inverso deben comprobar su configuración: la imagen oficial de Docker de Gitea también aparece vinculada a un bypass de autenticación distinto, CVE-2026-20896, cuando se habilitan cabeceras como X-WEBAUTH-USER. En una forja de código, una sola grieta puede bastar para convertir un repositorio en un punto de entrada a toda la infraestructura.

Más información

• BleepingComputer – Over 8,300 Gitea servers vulnerable to code execution attacks : https://www.bleepingcomputer.com/news/security/over-8-300-gitea-servers-vulnerable-to-code-execution-attacks/
• Help Net Security – Critical Gitea vulnerability now exploited in the wild (CVE-2026-60004) : https://www.helpnetsecurity.com/2026/08/26/gitea-cve-2026-60004-exploited-in-the-wild/
• OpenCVE – CVE-2026-60004 – Vulnerability Details : https://opencve.alliance.unm.edu/cve/CVE-2026-60004

La entrada Más de 8.300 servidores Gitea quedan expuestos a ataques de ejecución remota por CVE-2026-60004 se publicó primero en Una Al Día.