Una falla sin parche en el servidor de repositorio de Argo CD podría permitir a los atacantes apoderarse de los clústeres de Kubernetes

CD Argouna herramienta ampliamente utilizada para implementar software en Kubernetes, tiene una falla sin parchear en su componente de servidor de repositorio que permite que un atacante no autenticado ejecute código, siempre que pueda alcanzar el puerto de red interno del componente.

sinácticoque encontró el error, dice que puede conducir a una toma de control total del clúster. No hay solución ni CVE. La empresa dice que informó la falla a los encargados de mantenimiento de Argo CD en enero de 2025; Aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error se encuentra en el servidor de repositorio, el componente de CD de Argo que lee los repositorios de Git y crea manifiestos de Kubernetes, los archivos que definen lo que implementa el clúster.

Su servicio gRPC interno no tiene autenticación; cualquiera que pueda acceder a él puede enviar una solicitud diseñada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 y no informa ninguna versión parcheada; no publicó una lista completa de las versiones afectadas.

La técnica abusa personalizaruna herramienta estándar que ejecuta Argo CD para convertir archivos del repositorio en manifiestos. Kustomize tiene una opción –helm-command que apunta al binario de helm al que debe llamar.

Ciberseguridad

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del servidor de repositorio puede establecer esa opción en un script, extraído de un repositorio Git controlado por un atacante. Cuando se ejecuta kustomize, ejecuta el script en lugar de helm.

Pero «interno» no significa aislado por defecto. CD Argo envía políticas de red de Kubernetes que separan el servidor de repositorio de todo excepto de sus propios componentes.

Synacktiv encontró el gráfico Helm, una forma común de instalar Argo CD, deja esas políticas desactivadas de forma predeterminadacon networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al servidor de repositorio y desencadenar el error.

Ejecutar código en el servidor de repositorio no es el final. Synacktiv usó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse al caché de Redis de Argo CD y envenenar los datos de implementación almacenados. En la siguiente sincronización automática, Argo CD implementó una carga de trabajo proporcionada por el atacante.

Ese paso revive CVE-2024-31989Cycode encontró una falla en 2024 donde Redis de Argo CD no tenía contraseña, lo que permitió que cualquier pod en el clúster envenenara el caché de implementación. Argo CD solucionó el problema agregando una contraseña de Redis, pero el caché en sí aún no está firmado, por lo que robar la contraseña vuelve a abrir el mismo ataque.

que hacer

No existe una versión parcheada, por lo que la defensa es el aislamiento de la red. Active las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar al servidor de repositorio y a los puertos de Redis. Argo CD proporciona los archivos de políticas; Los usuarios de Helm tienen que habilitarlos porque el gráfico los deja fuera.

Comprueba qué está activo con: kubectl obtiene la política de red -A. Una instalación saludable muestra una política de red por componente, incluido el servidor de repositorio y Redis. Si faltan esas políticas, se puede acceder al servidor de repositorio y a los puertos de Redis desde el resto del clúster.

Ciberseguridad

Synacktiv creó una herramienta, argo-cdown, que automatiza el ataque completo. Está reteniendo la herramienta por ahora para darles tiempo a los defensores para bloquear sus políticas de red, y dice que la publicará en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.

Esta no es la primera vez que Argo CD expone sus propios componentes internos. En septiembre de 2025, parchó CVE-2025-55190donde un token API con solo acceso de lectura básico podría recuperar las credenciales del repositorio Git de un proyecto, una falla que The Hacker News señaló en ese momento.

En mayo de 2026, otro error, CVE-2026-42880permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto sin formato. Es difícil pasar por alto el patrón: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, a una solicitud no autenticada en un error y a un token de privilegios bajos en el siguiente.

Hasta que se envíe un parche, tratar la red del clúster como hostil es la única defensa real.

Los piratas informáticos aprovechan un defecto crítico del complemento de WordPress Everest Forms Pro para apoderarse de los sitios

Los actores de amenazas están explotando activamente una falla de seguridad crítica en Everest Forms Pro, un complemento de WordPress con alrededor de 4000 instalaciones activas, para ejecutar código arbitrario, lo que lleva a un compromiso completo del sitio.

La vulnerabilidad en cuestión es CVE-2026-3300 (puntuación CVSS: 9,8), un error de ejecución remota de código que afecta a todas las versiones del complemento hasta la 1.9.12 inclusive. Se lanzó un parche para la falla el 18 de marzo de 2026, con la versión 1.9.13.

«Esto se debe a que la función Process_filter() del complemento de cálculo concatena valores de campo de formulario enviados por el usuario en una cadena de código PHP sin el escape adecuado antes de pasarlo a eval()», Wordfence dicho.

«La función sanitize_text_field() aplicada a la entrada no escapa de las comillas simples u otros caracteres de contexto del código PHP. Esto hace posible que atacantes no autenticados inyecten y ejecuten código PHP arbitrario en el servidor enviando un valor manipulado en cualquier campo de formulario de tipo cadena (texto, correo electrónico, URL, selección, radio) cuando un formulario utiliza la función ‘Cálculo complejo’».

La explotación exitosa de la vulnerabilidad podría permitir a actores maliciosos no autenticados ejecutar código PHP arbitrario en el servidor, permitiéndoles crear cuentas de administrador fraudulentas, implementar shells web y abrir otras formas de profundizar en el servidor y establecer puntos de apoyo persistentes.

Ciberseguridad

Según la empresa de seguridad de WordPress, se ha observado que los atacantes explotan el defecto a partir del 13 de abril de 2026. Hasta la fecha se han bloqueado más de 29.300 intentos de explotación dirigidos al defecto. De estos, 16 intentos de ataque ocurrido en las últimas 24 horas. La carga útil más común implica intentos de crear una cuenta de administrador llamada «diksimarina» (dirección de correo electrónico: diksimarina@gmail.com) en el sitio comprometido.

Estos esfuerzos de ataque se originaron en las siguientes direcciones IP:

  • 202.56.2.126
  • 209.146.60.26
  • 15.235.166.18
  • 2402:1f00:8000:800::40dB
  • 185.78.165.153

Los ataques de Skimmer explotan Stripe para C2

La divulgación se produce cuando Sansec advirtió sobre múltiples campañas de skimmer, incluida una que utiliza Stripe como servidor de comando y control (C2) y un sumidero de exfiltración de datos en un intento por explotar la reputación de la marca y eludir las reglas de la Política de seguridad de contenido y los filtros de red.

«El atacante trata a Stripe como una infraestructura gratuita, no como una forma de blanquear cargos», Sansec anotado. «Stripe les proporciona una base de datos grabable para tarjetas robadas y un punto final de alojamiento de código para el skimmer, ambos detrás de un dominio en el que las reglas CSP y los filtros de red confían de forma predeterminada».

La campaña se basa en los dominios Google Tag Manager (GTM) y Stripe (googletagmanager.com y api.stripe.com), en los que las tiendas en línea confían implícitamente, con el código malicioso cargado desde un contenedor GTM y ejecutado en cada página que lo carga.

En las páginas de pago de Magento y Adobe Commerce, extrae un skimmer ofuscado de un Cuenta de cliente de Stripedel campo de metadatos («cus_TfFjAAZQNOYENR», en este caso) y guarda la información financiera, las direcciones de facturación y de correo electrónico y los números de teléfono ingresados ​​por usuarios desprevenidos para almacenamiento local. Los datos capturados luego se extraen de nuevo a la cuenta de Stripe del atacante.

Ciberseguridad

«Cada tarjeta robada se convierte en un ‘cliente’ en la cuenta del atacante», afirmó la empresa de seguridad del comercio electrónico. «Si tiene éxito, el cargador elimina la entrada localStorage, por lo que el mismo registro no se envía dos veces. El atacante lista sus tarjetas robadas más tarde llamando a la misma API con la misma clave. La base de datos de clientes de Stripe se convierte en un sumidero de exfiltración gratuito y duradero».

Se dice que el registro de cliente de Stripe que contiene el skimmer se creó el 24 de diciembre de 2025, lo que indica que la operación puede haber estado activa desde entonces. Sansec dijo que también identificó una segunda variante del cargador que usa Google Firestore en lugar de Stripe, aunque el objetivo final es el mismo: abusar de un servicio confiable como un canal encubierto que es poco probable que sea bloqueado por las tiendas de comercio electrónico.

Los hallazgos coinciden con una operación a gran escala denominada Gorgonágora que ha utilizado un grupo de 5.714 escaparates .shop falsos que se hacen pasar por marcas como Starbucks, Ford, Sony, Mattel, Hasbro, Lego, Disney y Toyota, cuyas páginas de pago canalizan datos de tarjetas robadas a un único servidor skimmer en Moldavia. La campaña ha estado en curso desde agosto de 2025.

«Cada tienda ejecuta la misma pila de comercio Medusa.js y carga el mismo SDK de pago personalizado, que genera un iframe Stripe falso y filtra los datos de la tarjeta a través de un WebSocket cifrado a un único servidor en Moldavia», dijo la compañía holandesa.

«La exfiltración se ejecuta a través de WebSocket con una carga útil AES-256-GCM, y el C2 mantiene una retransmisión 3D Secure en vivo: cuando el banco víctima devuelve un desafío 3DS, el operador se lo devuelve al comprador a través del iframe falso para que la transacción se complete y el robo permanezca invisible».

Anthropic acusa a los laboratorios chinos de intentar apoderarse ilícitamente de las capacidades de Claude

Anthropic acusó el lunes a tres laboratorios chinos de inteligencia artificial de intentar desviar sigilosamente las capacidades de Claude para sus propios modelos, potencialmente de una manera que podría impulsar operaciones cibernéticas ofensivas.

La startup estadounidense de inteligencia artificial dijo que los tres laboratorios, DeepSeek, Moonshot y MiniMax, realizaron “campañas a escala industrial” con una táctica conocida como “destilación”. Implica enviar solicitudes masivas a su modelo Claude en un intento por impulsar las suyas propias (en este caso, 16 millones en total). La destilación puede ser una práctica legítima como método de capacitación, dijo la compañía en una publicación de blogpero no cuando se utiliza como atajo para quitar capacidades a los competidores.

“Los modelos elaborados ilícitamente carecen de las salvaguardias necesarias, lo que crea importantes riesgos para la seguridad nacional”, argumentó Anthropic. “Los laboratorios extranjeros que destilan modelos estadounidenses pueden luego incorporar estas capacidades desprotegidas a sistemas militares, de inteligencia y de vigilancia, permitiendo a los gobiernos autoritarios desplegar IA de frontera para operaciones cibernéticas ofensivas, campañas de desinformación y vigilancia masiva”.

No es la primera vez que Anthropic advierte sobre las amenazas chinas derivadas del uso de Claude por parte de la nación. Y Anthropic combinó sus revelaciones sobre la campaña de destilación con repitiendo su llamada para controles más estrictos a las exportaciones.

OpenAI también tiene acusó a DeepSeek de utilizar técnicas de destilación. CyberScoop no pudo comunicarse de inmediato con los tres laboratorios chinos para comentar sobre las afirmaciones de Anthropic.

«Las tres campañas de destilación… siguieron un manual similar, utilizando cuentas fraudulentas y servicios de proxy para acceder a Claude a escala mientras evadían la detección», dijo Anthropic. «El volumen, la estructura y el enfoque de las indicaciones eran distintos de los patrones de uso normales, lo que reflejaba una extracción deliberada de capacidades en lugar de un uso legítimo».

En total, los laboratorios utilizaron 24.000 cuentas fraudulentas, dijo Anthropic. DeepSeek fue responsable de 150.000 de los intercambios, en comparación con 3,4 millones de Moonshot y 13 millones de MiniMax, según la startup. La actividad violó los términos de servicio y las restricciones de acceso regional, dijo.

Lo que hace que la táctica sea ilegítima es que esencialmente roba la propiedad intelectual, la potencia informática y el esfuerzo de Anthropic, dijo Gal Elbaz, cofundador y director de tecnología de Oligo Security, que se anuncia a sí misma como una empresa de seguridad de tiempo de ejecución de IA.

«Lo aterrador es que puedes tomar todo el poder y liberarlo, porque no tienes a nadie que realmente haga cumplir esas barreras en el otro lado», dijo Elbaz a CyberScoop sobre los temores que Anthropic generó sobre los laboratorios que alimentan los ciberataques.

Las propias empresas de IA se han enfrentado a acusaciones de que están robando datos e propiedad intelectual de otros para impulsar sus modelos.

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.