Administraciones y empresas que publican servicios cartográficos con OSGeo GeoServer afrontan un problema urgente: un fallo crítico permite a un atacante tomar el control del servidor sin credenciales si la instancia expone ciertos endpoints de OGC. La vulnerabilidad, registrada como CVE-2024-36401, ya aparece vinculada a intentos de explotación activa y a intrusiones confirmadas, un escenario especialmente delicado en entornos donde GeoServer sirve información geoespacial a través de Internet.

El defecto nace en el modo en que GeoServer y su biblioteca GeoTools interpretan determinados nombres de propiedades. En configuraciones por defecto, algunos parámetros pueden evaluarse como expresiones XPath, lo que abre la puerta a cadenas maliciosas capaces de desencadenar ejecución remota de código mediante commons jxpath. En la práctica, un atacante puede enviar peticiones construidas a propósito para forzar el comportamiento vulnerable y ejecutar instrucciones en el sistema.

La superficie de ataque no se limita a un único servicio. Entran en juego peticiones WFS como GetFeature y GetPropertyValue, funciones de WMS como GetMap, GetFeatureInfo y GetLegendGraphic, además de WPS Execute. Dicho de otro modo, basta con que el servidor publique estos endpoints y permanezca accesible desde Internet para que el riesgo se dispare.

Los incidentes documentados dibujan un patrón conocido: acceso inicial con CVE-2024-36401, reconocimiento dentro de la red, movimiento lateral y persistencia mediante web shells. Entre las herramientas observadas figura China Chopper, un clásico por su sencillez y por lo rápido que permite recuperar control remoto tras un reinicio o un cambio superficial en el servicio.

La corrección ya existe en varias ramas del proyecto. Las versiones que incluyen parche son GeoServer 2.22.6, 2.23.6, 2.24.4 y 2.25.2. La recomendación práctica es actualizar sin demora a una de esas versiones, o a una posterior, y tratar cualquier instancia expuesta como potencialmente comprometida si ha estado accesible sin parche.

Cuando el parche no llega a tiempo, se ha propuesto una mitigación operativa: retirar del despliegue el fichero gt-complex x.y.jar. Esa medida puede reducir el riesgo, pero también rompe funcionalidades y, en ciertos entornos, incluso puede impedir el arranque si el módulo resulta imprescindible. Conviene validarla antes en un entorno de pruebas y planificar un retorno rápido al estado anterior si el servicio queda inoperativo.

Más allá de parchear, la defensa pasa por recortar exposición. Limitar el acceso por IP, exigir VPN, colocar un proxy inverso con autenticación y reglas de filtrado mientras se completa la actualización reduce drásticamente la probabilidad de explotación. También toca revisar logs de GeoServer y del frontal web en busca de patrones anómalos en solicitudes WFS, WMS y WPS, especialmente filtros y parámetros inusuales.

Si el servidor ha estado expuesto, el trabajo no termina con el update. Hay que buscar indicios de compromiso en el host, como web shells, procesos inesperados o conexiones salientes extrañas, y rotar credenciales asociadas al sistema. Un plan de respuesta a incidentes probado y una monitorización continua ayudan a acortar el tiempo de detección, justo lo que marca la diferencia cuando hablamos de RCE sin autenticación.

Más información

• The Hacker News – Unpatched GeoServer Zero-Day Targeted in Active Exploitation Attempts, Can Lead to RCE : https://thehackernews.com/2026/08/unpatched-geoserver-zero-day.html
• NVD – CVE-2024-36401 : https://nvd.nist.gov/vuln/detail/CVE-2024-36401
• GeoServer Project – CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions : https://geoserver.org/vulnerability/2024/09/12/cve-2024-36401.html
• TechRadar Pro – US federal agency breached by hackers using GeoServer exploit, CISA says : https://www.techradar.com/pro/security/us-federal-agency-breached-by-hackers-using-geoserver-exploit-cisa-says

La entrada Una vulnerabilidad crítica en GeoServer se explota activamente y permite tomar el control del servidor se publicó primero en Una Al Día.

Administraciones y empresas que publican servicios cartográficos con OSGeo GeoServer afrontan un problema urgente: un fallo crítico permite a un atacante tomar el control del servidor sin credenciales si la instancia expone ciertos endpoints de OGC. La vulnerabilidad, registrada como CVE-2024-36401, ya aparece vinculada a intentos de explotación activa y a intrusiones confirmadas, un escenario especialmente delicado en entornos donde GeoServer sirve información geoespacial a través de Internet.

El defecto nace en el modo en que GeoServer y su biblioteca GeoTools interpretan determinados nombres de propiedades. En configuraciones por defecto, algunos parámetros pueden evaluarse como expresiones XPath, lo que abre la puerta a cadenas maliciosas capaces de desencadenar ejecución remota de código mediante commons jxpath. En la práctica, un atacante puede enviar peticiones construidas a propósito para forzar el comportamiento vulnerable y ejecutar instrucciones en el sistema.

La superficie de ataque no se limita a un único servicio. Entran en juego peticiones WFS como GetFeature y GetPropertyValue, funciones de WMS como GetMap, GetFeatureInfo y GetLegendGraphic, además de WPS Execute. Dicho de otro modo, basta con que el servidor publique estos endpoints y permanezca accesible desde Internet para que el riesgo se dispare.

Los incidentes documentados dibujan un patrón conocido: acceso inicial con CVE-2024-36401, reconocimiento dentro de la red, movimiento lateral y persistencia mediante web shells. Entre las herramientas observadas figura China Chopper, un clásico por su sencillez y por lo rápido que permite recuperar control remoto tras un reinicio o un cambio superficial en el servicio.

La corrección ya existe en varias ramas del proyecto. Las versiones que incluyen parche son GeoServer 2.22.6, 2.23.6, 2.24.4 y 2.25.2. La recomendación práctica es actualizar sin demora a una de esas versiones, o a una posterior, y tratar cualquier instancia expuesta como potencialmente comprometida si ha estado accesible sin parche.

Cuando el parche no llega a tiempo, se ha propuesto una mitigación operativa: retirar del despliegue el fichero gt-complex x.y.jar. Esa medida puede reducir el riesgo, pero también rompe funcionalidades y, en ciertos entornos, incluso puede impedir el arranque si el módulo resulta imprescindible. Conviene validarla antes en un entorno de pruebas y planificar un retorno rápido al estado anterior si el servicio queda inoperativo.

Más allá de parchear, la defensa pasa por recortar exposición. Limitar el acceso por IP, exigir VPN, colocar un proxy inverso con autenticación y reglas de filtrado mientras se completa la actualización reduce drásticamente la probabilidad de explotación. También toca revisar logs de GeoServer y del frontal web en busca de patrones anómalos en solicitudes WFS, WMS y WPS, especialmente filtros y parámetros inusuales.

Si el servidor ha estado expuesto, el trabajo no termina con el update. Hay que buscar indicios de compromiso en el host, como web shells, procesos inesperados o conexiones salientes extrañas, y rotar credenciales asociadas al sistema. Un plan de respuesta a incidentes probado y una monitorización continua ayudan a acortar el tiempo de detección, justo lo que marca la diferencia cuando hablamos de RCE sin autenticación.

Más información

• The Hacker News – Unpatched GeoServer Zero-Day Targeted in Active Exploitation Attempts, Can Lead to RCE : https://thehackernews.com/2026/08/unpatched-geoserver-zero-day.html
• NVD – CVE-2024-36401 : https://nvd.nist.gov/vuln/detail/CVE-2024-36401
• GeoServer Project – CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions : https://geoserver.org/vulnerability/2024/09/12/cve-2024-36401.html
• TechRadar Pro – US federal agency breached by hackers using GeoServer exploit, CISA says : https://www.techradar.com/pro/security/us-federal-agency-breached-by-hackers-using-geoserver-exploit-cisa-says

La entrada Una vulnerabilidad crítica en GeoServer se explota activamente y permite tomar el control del servidor se publicó primero en Una Al Día.

La explotación activa de CVE-2026-55040 ha colocado a Microsoft SharePoint Server on premise en el centro de las prioridades de seguridad de muchas organizaciones este agosto de 2026. El problema, catalogado como bypass de una función de seguridad y con una puntuación CVSS 9,1, permite que un atacante remoto actúe sin autenticación dentro de un sitio de SharePoint. El detalle que ha acelerado el riesgo es la aparición de un PoC público, un detonante habitual para que actores maliciosos conviertan una debilidad ‘teórica’ en una intrusión reproducible.

El fallo se relaciona con varios defectos en la canalización de validación de tokens JWT. Traducido a un escenario práctico, el atacante puede eludir el control de acceso y operar como la identidad que indique, incluso como un usuario con permisos de administrador. En entornos corporativos, ese salto resulta especialmente delicado porque abre la puerta a acciones que normalmente exigirían credenciales, desde cambios de configuración hasta operaciones sobre contenido y permisos.

La superficie afectada incluye versiones compatibles de SharePoint Server, como Subscription Edition, SharePoint Server 2019 y SharePoint Server 2016. El riesgo crece cuando la instancia está accesible desde Internet, porque el vector es remoto y no exige cuentas válidas. Además, este tipo de bypass suele encadenarse con otras vulnerabilidades o fallos de configuración en rutas que sí requieren autenticación, lo que amplía el impacto más allá del acceso inicial.

El contexto reciente alrededor de SharePoint refuerza la urgencia. En campañas vinculadas al ecosistema de vulnerabilidades del producto se han visto pasos posteriores al compromiso, como persistencia, robo de material sensible del servidor y búsqueda de secretos o artefactos criptográficos. En respuestas a incidentes reales, algunas organizaciones han optado por rotación de credenciales, contención de cuentas comprometidas y, en casos extremos, reinstalaciones preventivas de servidores para recuperar garantías.

La mitigación inmediata pasa por aplicar las actualizaciones de seguridad de Microsoft publicadas en julio de 2026 en todos los nodos de la granja y comprobar que la compilación queda realmente parcheada. Conviene priorizar los SharePoint expuestos a Internet y, mientras se completa la remediación, reducir la superficie de ataque restringiendo el acceso externo. A partir de ahí, toca mirar hacia dentro: revisar registros de IIS y telemetría de SharePoint en busca de suplantaciones, accesos anómalos y operaciones administrativas inesperadas, reforzar alertas sobre cuentas privilegiadas y preparar un plan de respuesta por si existiera un compromiso previo, con rotación de credenciales y verificación de persistencia.

Más información

• The Hacker News – Researcher Drops New Windows Zero-Day PoC Hours After Microsoft Patch Tuesday : https://thehackernews.com/2026/07/researcher-drops-new-windows-zero-day.html
• ITPro – Swiss authorities urge calm amid fears over SharePoint credential leak : https://www.itpro.com/security/data-breaches/swiss-authorities-urge-calm-amid-fears-over-sharepoint-credential-leak

La entrada Atacantes aprovechan un bypass crítico en SharePoint tras publicarse un PoC se publicó primero en Una Al Día.

La vulnerabilidad CVE-2026-59310 ha colocado a VMware vCenter Server en el centro de una campaña de intrusiones que busca controlar de forma persistente infraestructuras virtualizadas. El fallo afecta al componente Syslog server y permite ejecución remota de código con acceso de red. En la práctica, el riesgo se dispara cuando la consola queda accesible desde internet, un patrón que los atacantes han aprovechado con rapidez desde principios de agosto de 2026.

El defecto encaja en la categoría de salto de directorios. En términos sencillos, un atacante puede manipular rutas para acceder a ubicaciones que no debería tocar y, a partir de ahí, encadenar acciones que terminan en la ejecución de comandos en el appliance. La gravedad no es teórica: la vulnerabilidad tiene una puntuación CVSS 9,8, un nivel que suele reservarse para fallos que abren la puerta a compromisos completos sin apenas fricción.

Los compromisos observados apuntan a una ventana muy corta entre divulgación y explotación. La actividad se detectó a partir del 3 de agosto de 2026, con un foco claro en instancias de vCenter visibles en internet. En el recuento más reciente, se han identificado 361 direcciones IP de víctimas únicas repartidas por 47 países, con una concentración destacada en Alemania, Estados Unidos, Turquía, Irán y Francia.

Una vez dentro, el atacante no se limita a ejecutar un comando y marcharse. Implanta persistencia mediante una tarea cron maliciosa y despliega reverse_ssh, una pieza pensada para mantener un canal de control estable. La clave de este enfoque está en que reverse_ssh establece conexiones salientes hacia la infraestructura del atacante, algo que puede sortear defensas que se centran en bloquear accesos entrantes y dejan más margen al tráfico que sale hacia internet.

La respuesta recomendada no deja espacio para atajos. Broadcom ha publicado correcciones en el aviso VMSA-2026-0006.1 y no existe una solución alternativa para CVE-2026-59310, así que la prioridad pasa por actualizar vCenter sin demora. A partir de ahí, conviene confirmar que el servicio no se expone a internet, endurecer el acceso con segmentación de red y listas de control, y revisar el appliance en busca de crontabs no autorizados, binarios o ejecuciones de reverse_ssh, además de conexiones salientes anómalas hacia dominios o IP que no formen parte del tráfico habitual.

El mismo paquete de actualizaciones también incluye arreglos para CVE-2026-59309. En paralelo se ha observado un aumento de escaneo y huellas contra esa superficie, aunque por ahora no se ha confirmado la relación directa con la explotación de CVE-2026-59310. Aun así, el contexto es claro: cuando vCenter queda expuesto y sin parchear, el tiempo de reacción se mide en días, no en semanas.

Más información

• The Hacker News – Attackers Exploit VMware vCenter Vulnerability to Gain Persistent Remote Access : https://thehackernews.com/2026/08/attackers-exploit-vmware-vcenter.html
• QUIRSO GmbH (Medium) – Active exploitation of CVE-2026-59310: 361 victim IPs across 47 countries : https://medium.com/%40quirso_de/active-exploitation-of-cve-2026-59310-361-victim-ips-across-47-countries-9783187cc6ff
• Broadcom Support Portal – VMSA-2026-0006.1: VMware ESX, vCenter, Workstation, and Fusion updates address multiple vulnerabilities : https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• vmware/vcf-security-and-compliance-guidelines (GitHub) – VMSA-2026-0006: Questions & Answers (README.md) : https://github.com/vmware/vcf-security-and-compliance-guidelines/blob/main/security-advisories/vmsa-2026-0006/README.md

La entrada Atacantes explotan un fallo crítico en VMware vCenter para instalar acceso remoto persistente se publicó primero en Una Al Día.

La investigación sobre GhostSplice pone el foco en una pieza cada vez más habitual en los flujos de trabajo con asistentes de programación, los servidores de herramientas conectados mediante Model Context Protocol (MCP). El hallazgo muestra un escenario incómodo: basta con que un desarrollador conecte un servidor MCP no verificado para que ese servidor, si actúa con mala fe, empuje al agente a filtrar información sensible que ya está al alcance del propio entorno de desarrollo.

La idea central resulta tan simple como eficaz. En vez de insertar una orden directa del tipo ‘envía las claves’, el servidor reparte la instrucción en fragmentos. Una parte aparece camuflada en la descripción de una herramienta MCP, otra se cuela en el resultado de una interacción posterior. Cada pieza, aislada, parece un texto operativo o metadatos inofensivos. El problema llega cuando el agente, que suele tratar esas descripciones y respuestas como contexto fiable, las recombina dentro de la misma conversación y acaba ejecutando el plan completo.

En pruebas controladas, el método elevó de forma notable la tasa de ‘cumplimiento’ del modelo. Dividir la instrucción en dos partes llevó el promedio del 42% al 82% en once modelos evaluados. En algunos casos, sistemas que antes se negaban de forma consistente pasaron a comportarse al revés, de 0% a 100%. Este detalle subraya un matiz clave: el riesgo no depende solo del modelo. Depende del cliente, de cómo integra herramientas, de las barreras alrededor del agente y de si ese entorno permite que el texto devuelto por una herramienta se convierta, de facto, en guía de acción.

La demostración incluye filtraciones de claves SSH, ficheros .env, código propietario y documentos con datos sensibles. La técnica usa plantillas y campos aparentemente neutros que terminan resolviendo rutas concretas del sistema, lo bastante cerca de la operativa diaria como para que el agente no levante sospechas. Aun así, conviene acotar el alcance: GhostSplice no compromete agentes a distancia por sí solo. Necesita dos condiciones previas, que el desarrollador conecte el servidor MCP del atacante y que el agente ya tenga permisos para leer los ficheros que se pretende sustraer.

La ausencia de CVE en esta divulgación y el carácter defensivo del trabajo no rebajan la urgencia práctica, porque encaja con avisos recientes sobre envenenamiento de herramientas MCP y ataques de agentjacking. El patrón se repite: contenido que llega desde servicios externos, vía MCP, se interpreta como instrucciones de resolución y puede terminar en acciones no deseadas, desde filtraciones silenciosas en datos corporativos hasta ejecución de código si el flujo de herramientas lo permite.

Las mitigaciones pasan por decisiones de ingeniería, no por confiar en que el modelo ‘se portará bien’. Lo primero es inventariar y restringir los servidores MCP permitidos, desactivar integraciones de terceros por defecto y aplicar el principio de mínimo privilegio en el número de herramientas habilitadas. También conviene tratar las descripciones de herramientas y cualquier cambio como material de alto riesgo, con control de versiones, revisión y alertas ante modificaciones inesperadas.

A partir de ahí, la clave está en separar datos e instrucciones. Si la salida de una herramienta alimenta sin validación los argumentos de otra, el atacante gana un carril perfecto para recomponer órdenes en varias etapas. En operaciones con capacidad de exfiltración, como lecturas masivas, acceso a rutas sensibles, exportaciones o envíos a endpoints externos, la aprobación humana sigue siendo un freno eficaz.

El puesto de desarrollo necesita contención real. Limitar el acceso del agente a directorios como .ssh, credenciales y ficheros .env reduce el daño potencial. Y el control del tráfico saliente, con destinos permitidos y vigilancia de volúmenes anómalos, ayuda a detectar subidas de datos impropias. Para cerrar el círculo, el registro detallado de llamadas a herramientas, argumentos, recursos leídos y destinos de red permite correlacionar cadenas de acciones y cazar recombinaciones de instrucciones. Incluso se recomienda introducir canarios y señuelos para disparar alertas automáticas cuando esos valores aparezcan en solicitudes salientes.

En paralelo, la formación del equipo importa. Conectar un servidor MCP ‘porque funciona’ ya no es un gesto inocente. Los ejercicios controlados de inyección y las pruebas de resiliencia del cliente, con políticas que impidan lecturas de secretos y envíos no autorizados, marcan la diferencia entre un asistente útil y una vía de fuga con aspecto de herramienta.

Más información

• The Hacker News – Malicious MCP Servers Can Split Instructions to Make AI Coding Agents Exfiltrate Secrets : https://thehackernews.com/2026/08/malicious-mcp-servers-can-split.html
• The Hacker News – Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data : https://thehackernews.com/2026/06/microsoft-warns-poisoned-mcp-tool.html
• The Hacker News – Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code : https://thehackernews.com/2026/06/agentjacking-attack-tricks-ai-coding.html

La entrada GhostSplice muestra cómo un servidor MCP malicioso puede forzar a un agente de IA a filtrar secretos se publicó primero en Una Al Día.

La comunidad de seguridad ha identificado dos extensiones maliciosas para Visual Studio Code que se presentan como herramientas orientadas al desarrollo con Solidity y el ecosistema Web3, pero en realidad buscan robar información sensible del equipo. La operación se apoya en un señuelo claro, el reclamo ‘Solidity Pro’, y apunta a un perfil muy concreto: desarrolladores que trabajan con contratos inteligentes y que suelen convivir en el mismo entorno con credenciales, tokens y sesiones activas.

El objetivo va más allá del propio editor. La actividad detectada incluye la recopilación de datos asociados a carteras cripto en el navegador, credenciales guardadas y secretos habituales en un puesto de desarrollo, como claves de API y otros tokens. Este tipo de robo resulta especialmente peligroso porque un único equipo comprometido puede abrir la puerta a accesos laterales, desde repositorios hasta servicios cloud, y en el caso de wallets, a la pérdida directa de fondos.

Los indicadores que han trascendido señalan dos identificadores concretos en la tienda de extensiones: helper-beeps.solidity-pro y web3devtoolsx.solidity-pro. En un ataque de cadena de suministro como este, el vector no suele ser un exploit complejo, sino una instalación aparentemente legítima que aprovecha la confianza en el ecosistema de extensiones, donde abundan herramientas útiles y el control real recae en el usuario o en políticas internas que muchas organizaciones aún no han endurecido.

El riesgo operativo crece porque el editor convive con archivos .env, llaves SSH, gestores de credenciales del sistema y sesiones iniciadas en servicios críticos. Si una extensión logra leer o exfiltrar esos datos, la recuperación no se limita a desinstalarla: obliga a asumir que todo secreto accesible desde esa máquina pudo quedar expuesto.

La recomendación inmediata pasa por desinstalar helper-beeps.solidity-pro y web3devtoolsx.solidity-pro y evitar su reinstalación. A partir de ahí, conviene tratar como comprometidos los secretos del equipo afectado, rotar tokens, claves de API y contraseñas, y revisar el uso reciente de credenciales en servicios críticos para detectar actividad anómala compatible con reutilización.

Para reducir superficie de ataque, resulta clave auditar el inventario de extensiones de VS Code, eliminar las que no sean imprescindibles y aplicar una política de instalación más estricta, con lista permitida y registro centralizado. En entornos Web3, además, ayuda separar operaciones sensibles del puesto de desarrollo: perfiles de navegador dedicados, cuentas aisladas y, cuando sea posible, hardware wallets para firmar transacciones fuera del alcance del software del equipo.

Más información

• The Hacker News – Solidity Pro VS Code Extensions Steal Crypto Wallets, API Keys, and Credentials : https://thehackernews.com/2026/08/solidity-pro-vs-code-extensions.html
• Reddit – Solidity Pro VS Code Extensions Steal Crypto Wallets, API Keys, and Credentials : https://www.reddit.com/r/SecOpsDaily/comments/1vkfmt8/solidity_pro_vs_code_extensions_steal_crypto/

La entrada Dos extensiones maliciosas de VS Code se hacen pasar por herramientas de Solidity para robar criptomonedas y credenciales se publicó primero en Una Al Día.

Un fallo de seguridad en KVM/x86 dentro del kernel de Linux ha puesto el foco en un riesgo que muchas plataformas de infraestructura asumen casi sin querer: la virtualización anidada expuesta a cargas no confiables. La vulnerabilidad, bautizada como Zapscape y registrada como CVE-2026-64561, puede permitir que un atacante con privilegios de kernel en una máquina virtual L1 consiga ejecutar código en el host con permisos de root.

El problema se concentra en la shadow MMU y en cómo KVM gestiona las shadow page tables cuando el invitado L1 actúa a su vez como hipervisor para un invitado L2. En términos prácticos, el aislamiento que suele proteger al host frente a lo que ocurre dentro de una VM se debilita justo en el escenario en el que el proveedor da más poder al inquilino, al permitirle virtualizar dentro de su propia VM.

La raíz técnica está en un orden incorrecto al comprobar una condición de ‘stale root’ durante el manejo de fallos de página del invitado. Esa secuencia puede desembocar en un use after free y, a partir de ahí, en escrituras posteriores a liberación, un patrón clásico cuando se busca convertir un fallo de memoria en ejecución de código.

La divulgación pública menciona una prueba de concepto que encadena la explotación y termina creando un fichero en el host, /Zapscape, con propietario root, como demostración del salto. En Intel, el escenario requiere que el invitado L1 tenga expuestos EPT page walk length 4 y 5 para que se cumpla la condición descrita. En AMD no aparece una condición equivalente en la información publicada.

No consta, por ahora, explotación activa en ataques reales. Aun así, el alcance potencial justifica actuar con rapidez, sobre todo en entornos multi tenant. NVD sitúa el rango afectado a partir de Linux 5.9 y la corrección ya aparece integrada en el árbol principal y en ramas estables, con versiones corregidas que incluyen 6.6.148, 6.12.101, 6.18.42, 7.1.6 y 7.2 rc5. La mitigación más directa pasa por actualizar a un kernel estable corregido o instalar el paquete del fabricante con el parche retroportado.

En paralelo, conviene inventariar qué hosts ofrecen nested virtualization a cargas no confiables y tratarlos como prioridad de parcheo. Si un servidor no necesita virtualización anidada, deshabilitarla reduce superficie de ataque de forma inmediata. También ayuda comprobar la versión ‘efectiva’ con el seguimiento del proveedor de la distribución, porque algunas correcciones llegan como retroportaciones sin reflejarse de forma evidente en la cadena de versión upstream. Y si se decide validar el riesgo con pruebas internas, lo sensato es ejecutar la PoC solo en entornos controlados, nunca en producción.

Más información

• The Hacker News – New Zapscape KVM Flaw Could Let Privileged L1 Guest Code Escape to Linux Hosts : https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
• NIST National Vulnerability Database (NVD) – CVE-2026-64561 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-64561

La entrada Un fallo en KVM rompe el aislamiento en virtualización anidada y abre la puerta a ejecutar código como root en Linux se publicó primero en Una Al Día.

Una intrusión que empezó con una simple inyección SQL en una aplicación expuesta a Internet acabó escalando hasta la ejecución de comandos en un servidor Windows con privilegios de SYSTEM. El punto de giro no estuvo en una vulnerabilidad nueva del sistema operativo, sino en una capacidad legítima de Oracle Database: la posibilidad de cargar, compilar y ejecutar Java dentro de la base de datos como parte de su lógica interna.

Tras obtener acceso a la base de datos Oracle, los atacantes introdujeron código fuente Java y lo convirtieron en objetos del esquema, compilándolo en el propio servidor. Esta forma de post explotación resulta especialmente incómoda para la defensa porque reduce la dependencia de binarios clásicos en disco y desplaza parte del tooling al interior del motor de base de datos, que en muchos entornos se monitoriza menos que el sistema operativo o el servidor web.

La actividad se asoció a un artefacto denominado khunt, ligado a telemetría de Huntress. El objetivo final consiste en convertir una puerta de entrada a nivel de aplicación en una vía para ejecutar acciones en el host. Cuando el proceso de Oracle corre con permisos elevados en Windows, cualquier ejecución encadenada desde el contexto de la base de datos puede terminar heredando privilegios muy altos, hasta SYSTEM, con el consiguiente riesgo para el resto de la máquina y los datos que alberga.

La cadena refuerza una idea conocida, pero que se incumple con demasiada frecuencia: la defensa empieza en la aplicación. Corregir la inyección SQL exige abandonar concatenaciones de entradas y aplicar consultas parametrizadas y validación estricta. A partir de ahí, toca mirar a la base de datos: si Java en Oracle no resulta imprescindible, conviene deshabilitarlo o limitarlo al máximo, porque amplía el alcance de lo que un atacante puede hacer tras un primer acceso.

En paralelo, los equipos de seguridad pueden ganar visibilidad vigilando señales muy concretas dentro de Oracle. Sentencias y eventos como CREATE JAVA SOURCE, CREATE JAVA CLASS y operaciones de compilación deben encender alertas si aparecen en producción sin una razón clara. También ayuda restringir quién puede ejecutar DDL relacionado con Java, revisar el usuario de base de datos que usa la aplicación con enfoque de mínimo privilegio, y endurecer el propio host Windows, empezando por evitar que el servicio de Oracle funcione con privilegios innecesarios.

En la información disponible no aparecen CVE concretos para el acceso inicial ni se detallan versiones exactas de Oracle Database o configuraciones del entorno. Aun así, el patrón encaja con un riesgo recurrente: cuando una plataforma crítica, como la base de datos, mantiene habilitadas funciones potentes sin gobernanza ni auditoría, un fallo clásico como la inyección SQL deja de ser ‘solo’ un problema de datos y pasa a convertirse en un problema de control del sistema.

Más información

• The Hacker News – Attackers Compile khunt Inside Oracle to Turn SQL Injection Into Windows SYSTEM Access : https://thehackernews.com/2026/08/attackers-compile-khunt-inside-oracle-to-turn-sql-injection-into-windows-system-access.html
• Oracle Documentation – Loading Java Classes : https://docs.oracle.com/cd/A97630_01/java.920/a96659/02_load.htm
• Oracle Documentation – Server-Side Internal Driver : https://docs.oracle.com/en/database/oracle/oracle-database/26/jjdbc/server-side-internal-driver.html

La entrada Una inyección SQL en Oracle se convierte en ejecución como SYSTEM en Windows con Java dentro de la base de datos se publicó primero en Una Al Día.

Un episodio de robo coordinado vació 1.082,65 BTC de 1.196 direcciones en solo 41 minutos el 30 de julio de 2026, siguiendo un patrón de barrido automatizado que apunta a un problema de fondo mucho más delicado: la generación de frases semilla con entropía insuficiente en monederos físicos COLDCARD, de Coinkite. No se trata de una fuga puntual ni de un malware en el ordenador del usuario, sino de una debilidad que permitiría a un atacante enumerar y probar combinaciones de semillas fuera de línea, hasta dar con claves válidas y, después, firmar transacciones para mover los fondos.

La raíz del fallo se sitúa en un error de integración introducido en marzo de 2021. En lugar de apoyarse en el RNG hardware del microcontrolador STM32, algunas versiones redirigieron la creación de la semilla a un PRNG determinista por software. Ese generador se inicializó con el identificador único del chip y registros de temporización, pero no incorporó ‘entropía fresca’ después de arrancar. El resultado reduce drásticamente el espacio de búsqueda: se estimó una entropía efectiva de alrededor de 40 bits en Mk3 y de unos 72 bits en Mk4, Mk5 y Q, lejos de los 128 bits esperados en una semilla BIP39 de 12 palabras.

El alcance no depende del firmware que tenga hoy el dispositivo, sino del que se utilizó cuando se creó la semilla. Se consideran vulnerables, por modelo, semillas generadas en Mk2 y Mk3 con versiones 4.0.0 a 4.1.9, en Mk4 y Mk5 con versiones anteriores a 5.6.0, y en Q con versiones anteriores a 1.5.0Q. También se publicaron builds corregidas en ramas Edge, para Mk4/Mk5 anteriores a 6.6.0X y para Q anteriores a 6.6.0QX.

Tras el gran robo, se detectaron dos oleadas adicionales compatibles con el mismo mecanismo. La estimación observada sube a 1.367,05 BTC, cerca de 88,6 millones de dólares, repartidos en 4.585 direcciones. Se reportaron además cientos de direcciones presuntamente controladas por el atacante a investigadores y autoridades, con la sospecha de que la actividad continúa. Aun así, no se confirmó públicamente ni la reconstrucción de una semilla concreta de una víctima ni la atribución de la campaña.

Coinkite publicó un firmware de emergencia el 31 de julio, que reduce el riesgo al crear nuevas semillas. La clave es que actualizar no arregla una semilla ya generada con entropía débil. Restaurarla en el mismo monedero, o importarla en otro, conserva el problema. La recomendación práctica pasa por identificar la versión exacta con la que se creó la semilla, actualizar primero a firmware corregido, generar una semilla nueva y migrar de inmediato los fondos a direcciones derivadas de esa nueva semilla.

Hay matices. Si el usuario añadió entropía con dados, se considera no afectado por este fallo por sí solo si realizó al menos 50 tiradas justas, independientes y privadas. Si no puede asegurarlo, conviene migrar igualmente. Activar una passphrase BIP39 fuerte y única crea una cartera distinta y añade una capa defensiva, pero no sustituye la necesidad de reemplazar la semilla en los casos expuestos. Y el multisig solo aporta garantías si el quórum no depende exclusivamente de claves generadas en dispositivos o firmwares vulnerables.

En paralelo, los usuarios con fondos en direcciones potencialmente afectadas deberían vigilar la actividad on chain y priorizar el movimiento preventivo si detectan consolidaciones o barridos no autorizados. En incidentes de este tipo, la velocidad importa: una vez que el atacante automatiza la búsqueda y encuentra una semilla válida, el vaciado puede llegar en minutos.

Más información

• The Hacker News – Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes : https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
• National Vulnerability Database (NIST) – CVE-2026-65058 Detail : https://nvd.nist.gov/vuln/detail/CVE-2026-65058

La entrada Un fallo en las semillas de Coldcard se vincula a un robo de más de 1.000 bitcoin en 41 minutos se publicó primero en Una Al Día.

Un fallo de seguridad en Cisco Secure Firewall Management Center (FMC) se está usando en ataques reales y afecta a un componente crítico para muchas redes corporativas, el plano de gestión de sus firewalls. La vulnerabilidad, registrada como CVE-2026-20316, permite que un atacante remoto sin autenticación inicie sesión gracias a credenciales estáticas asociadas a una cuenta de bajo privilegio. No concede control total por sí sola, pero sí abre una vía de acceso a información sensible disponible para ese perfil.

El riesgo práctico no se mide solo por la puntuación técnica, que se sitúa en CVSS 5.3, sino por el contexto: la explotación activa ya ha llevado a su incorporación al catálogo Known Exploited Vulnerabilities. Además, Cisco elevó su valoración interna a High porque este acceso inicial puede encadenarse con otros fallos para subir el listón, desde ampliar permisos hasta llegar a escenarios de ejecución con privilegios elevados.

La compañía ha publicado hotfixes para varias ramas, incluidas 7.0, 7.2, 7.4, 7.6, 7.7 y 10.0, con paquetes específicos para cada versión. En paralelo, recomienda comprobar indicios de compromiso en el propio sistema. Uno de los más claros consiste en filtrar eventos de licencia en /var/log/messages y tratar como sospechosa cualquier aparición de la ruta /var/tmp/license.tmp.

Ese indicador también aparece vinculado a CVE-2026-20079, un bypass de autenticación catalogado como crítico en Cisco Secure FMC que puede permitir ejecutar scripts para obtener acceso root. En entornos donde conviven ambos riesgos, el parcheo debe plantearse como una remediación conjunta, no como incidentes aislados.

La medida más eficaz para reducir la superficie de ataque sigue siendo cortar la exposición del interfaz de gestión a Internet. Conviene limitar el acceso mediante ACL, VPN y redes de administración dedicadas, e identificar rápidamente todas las instancias de FMC y su nivel de parche. Si hay señales de explotación, toca ir más allá: rotar credenciales, claves y certificados, revisar accesos administrativos del periodo sospechoso y activar telemetría y alertas en el plano de gestión, con especial atención a ejecuciones inusuales vía sudo y a comandos relacionados con licencia y utilidades como paquete_info.pl. Para agencias federales civiles de Estados Unidos, el plazo de remediación asociado al catálogo KEV se fijó en el 1 de agosto de 2026, una referencia útil también para priorizar en empresas con exposición elevada.

Más información

• The Hacker News – Cisco FMC Zero-Day Actively Exploited, Static Credentials Could Expose Sensitive Data : https://thehackernews.com/2026/07/cisco-fmc-zero-day-actively-exploited.html
• Cisco – Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability (CVE-2026-20079) : https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-onprem-fmc-authbypass-5JPp45V2.html
• Center for Internet Security (CIS), MS-ISAC – Multiple Vulnerabilities in Cisco Products Could Allow for Remote Code Execution (Advisory 2026-018) : https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-cisco-products-could-allow-for-remote-code-execution_2026-018

La entrada Un zero-day en Cisco Secure FMC abre la puerta a accesos con credenciales estáticas se publicó primero en Una Al Día.