INVESTIGACIÓN
Agentes de IA ante tools envenenados y archivos engañosos, fallos contra el post-quantum
OT and industrial securitySupply chain
Esta semana tres estudios ponen a prueba a los agentes de IA: tools MCP envenenados que aciertan casi una vez de cada cuatro, tools firmados que filtran datos y archivos Office que el modelo lee distinto que nosotros. En hardware destacan un trojan en sensores y dos ataques a SLH-DSA y ML-KEM. Cierran bugs del compilador en zkVM y la NativeMessaging de los navegadores.
1. SenTrojan: Revealing Analog Hardware Trojan Attacks on Sensors
arXiv · Kun Wang, Ruochen Zhou, Wenjun Zhu, Shilin Xiao et al. · Sistemas ciberfísicos e IoT
En breve: SenTrojan muestra que un troyano analógico implantado en sensores antes de su despliegue puede activarse con señales físicas externas, hasta bloquear o falsear las lecturas.
Los autores diseñan troyanos hardware en la circuitería analógica común a muchos sensores, activados con señales físicas diseñadas a medida. Dos variantes cubren arquitecturas distintas. En 14 sensores de 6 principios de transducción indican una tasa media de activación superior al 95% y más del 97% de similitud con el comportamiento normal.
Por qué importa. El trabajo lleva la seguridad de los sensores de los fallos físicos involuntarios al compromiso deliberado de la cadena de suministro. Un troyano que se desvía menos de un 5% del comportamiento normal es difícil de detectar con pruebas habituales.
Para quien asegura. Para quien asegura plantas industriales, vehículos o dispositivos médicos, el origen de los componentes pasa a ser una pregunta de suscripción: un sensor comprometido en fábrica puede provocar fallos o lecturas falsas en muchos asegurados con el mismo modelo, con riesgo de acumulación.
2. Beyond Instruction Override: Benchmarking Indirect Prompt Injection with Task-Tampering Attacks
arXiv · Rongting Zhang, Martin Bertran, Sandeep Avula, Chia-Jung Lee et al. · Seguridad de IA y LLM
En breve: Un nuevo benchmark muestra que la prompt injection indirecta puede alterar el resultado de una tarea sin sustituirla, y que las defensas actuales solo cubren una parte.
Los autores definen el ataque por autoridad: hay injection cuando un contenido intenta influir en una decisión que su fuente no puede tomar. En 90 casos de tres entornos, los ataques a reglas, acciones y estado tienen más éxito que los dirigidos al objetivo. Una defensa por detección deja pasar el 12,1% de los ataques al estado y una basada en herramientas el 15,4%.
Por qué importa. Muchas pruebas de seguridad de agentes solo comprueban si la tarea se desvía, y así sobrestiman las defensas. Un ejemplo realista: una prueba de reclamación que cita una falsa política de reembolso para inflar el importe.
Para quien asegura. Para quien asegura empresas que usan agentes en reembolsos, pagos o expedientes, el escenario de pérdida no es solo el agente secuestrado, sino la decisión falseada dentro de una tarea legítima. Las promesas de los proveedores sobre defensas frente a la prompt injection deben leerse con esta brecha en mente.
Leer el artículo · PDF · Código
3. PIMROP: A Feasibility Study of Return-Oriented Programming on Commercial Processing-in-Memory Architectures
arXiv · William C. Tegge, Shouzhi Fang, Alex K. Jones · Hardware y canales laterales
En breve: PIMROP demuestra por primera vez ataques de return-oriented programming en un procesador comercial integrado en la memoria, fuera de las defensas que protegen los programas del host.
Los procesadores en memoria ejecutan código junto a los bancos DRAM. En el DPU de UPMEM los autores hallan 517 gadgets en la librería de ejecución que enlaza todo kernel y demuestran dos ataques que filtran un secreto, con éxito en 10 de 10 intentos. Los stack canaries y las comprobaciones tipo _FORTIFY_SOURCE fallan por razones propias de la plataforma; un DMA con límites lo frena.
Por qué importa. Las arquitecturas processing-in-memory sacan cálculo y datos del alcance de defensas como canaries y control de flujo. Quien las adopte debe comprobar que las protecciones estándar funcionan de verdad en el nuevo hardware.
Para quien asegura. El processing-in-memory aún está poco extendido, por lo que el impacto asegurador es limitado por ahora. El caso muestra, aun así, que un control declarado activo, como el stack canary, puede resultar ineficaz en plataformas nuevas.
Leer el artículo · PDF · Código
4. MCP Tool Poisoning in Agentic AI Frameworks: A Cross-Framework Measurement Study
arXiv · Farooq Shaikh, Biagio Montaruli · Seguridad de IA y LLM
En breve: Una medición en 12 frameworks agénticos y 18 modelos muestra que el tool poisoning vía MCP tiene éxito en el 22,9% de los casos y que ningún framework tiene defensas intencionadas.
Con la herramienta abierta mcpvenom, los autores ejecutan una matriz de 9.720 celdas: 12 frameworks, 18 modelos y 45 escenarios con ejecución real. El ataque funciona en el 22,9% de los casos y en el 12,1% de ellos exfiltra un secreto. La resistencia depende del modelo (0,4%-49,7%). Un escáner regex bloquea 20 de 45 escenarios; los cinco avisos a proveedores fueron rechazados.
Por qué importa. Quien conecta agentes de IA a servidores MCP de terceros no puede confiar en el framework: descripciones y respuestas de los tools llegan al contexto del modelo sin validar. Escanear metadatos es solo un control parcial.
Para quien asegura. En la suscripción conviene saber qué modelos y servidores MCP usa el asegurado, porque la resistencia varía dos órdenes de magnitud entre modelos. La falta de defensas en frameworks muy usados sugiere además un riesgo de acumulación entre usuarios de las mismas herramientas.
5. Proving the Wrong Program: Miscompilations as a Threat to zkVM Guarantees
arXiv · Hui Xuan Tan, Stefanos Chaliasos, Alastair F. Donaldson · Seguridad de sistemas y software
En breve: Un bug del compilador puede hacer que una zkVM correcta genere una prueba válida de un cálculo distinto del código fuente, y un atacante puede provocarlo a propósito.
En SP1 y Jolt los autores reproducen 88 miscompilaciones conocidas de rustc y LLVM: 48 producen una salida errónea en SP1 y 46 en Jolt. En proyectos reales los bugs rara vez saltan por accidente, pero por unos 40 dólares por proyecto un agente LLM halla parches inocuos que los exponen en 12 de 366 pares, en 11 de 20 proyectos, incluido un cliente Ethereum que rechaza un bloque válido.
Por qué importa. Ni la revisión ni la verificación formal de la zkVM o del código fuente detectan un parche así, porque ambos son correctos. Los autores recomiendan tratar el compilador como parte de la base de confianza y seguir sus bugs conocidos.
Para quien asegura. Para quien asegura proyectos blockchain o servicios con pruebas de conocimiento cero, una prueba válida no garantiza que se ejecutó el programa esperado. En la suscripción importa cómo gestiona el asegurado su toolchain y las contribuciones externas.
6. Signed, Sealed, Leaked: Trust Beyond Signature for MCP Toolchains
arXiv · Yichiet Aun, Mohammed A. Alhartomi, Jing Jie Tan, Waqas Nadeem et al. · Cadena de suministro de software
En breve: Un tool MCP firmado puede filtrar datos hacia un destino permitido; la germline execution limita lo que el código malicioso puede divulgar.
Un tool MCP firmado oculta datos sensibles en peticiones a un destino permitido: MCPGuard-Dynamic de Meta no lo detiene en ninguna prueba. Los autores proponen la germline execution: cada invocación corre en copias efímeras con solo los datos autorizados. En 153 ataques no hay divulgaciones no autorizadas, frente al 5,9-74,5% de las defensas de referencia, con 10-49 ms por invocación.
Por qué importa. La firma prueba quién publicó un tool, no qué hace. Aislar los datos por invocación limita el daño aunque el código malicioso se ejecute.
Para quien asegura. Al valorar controles, la firma de código y las políticas de runtime no excluyen fugas de datos por tools de IA de terceros. El escenario se parece a una cadena de suministro comprometida, con posible acumulación entre usuarios del mismo tool.
7. Correlation Power Analysis on SHA-2-Based SLH-DSA
IACR Cryptology ePrint Archive · Jinwook Chang, Minjeong Lee, JIN YONG MIN, Dong-Guk Han · Criptografía poscuántica
En breve: Un análisis de potencia por correlación recupera partes de la semilla secreta de SLH-DSA basado en SHA-2 en un microcontrolador Cortex-M4.
Los autores atacan la función pseudoaleatoria basada en direcciones en los seis conjuntos de parámetros SHA-2, por los rounds de compresión de SHA-256 y por la expansión del message schedule. En un STM32F303, con 5.000 trazas por semilla, las fases de compresión logran un 100% de éxito. Las tasas son por fase, con los valores previos dados, no de recuperación completa.
Por qué importa. SLH-DSA es un estándar de firma post-quantum. Las implementaciones embebidas deben proteger frente a canales laterales tanto los rounds de compresión como el message schedule.
Para quien asegura. La relevancia aseguradora directa es limitada y a largo plazo: afecta a fabricantes de dispositivos y chips que adoptan firmas post-quantum. Recuerda que adoptar un algoritmo estándar no elimina el riesgo de implementación.
8. Keyber: Recovering the Signal by Amplifying the Noise in ML-KEM
IACR Cryptology ePrint Archive · Vipin Kumar, Prathamesh Ram, Suparna Kundu, Dhiman Saha · Criptografía poscuántica
En breve: Keyber recupera la clave secreta de ML-KEM con un único fallo inducido durante la generación de claves, comprometiéndola durante toda su vida.
Es el primer ataque SIFA a la generación de claves de ML-KEM. El fallo suma un valor conocido al vector de error; el atacante encapsula en local, conserva solo los ciphertexts útiles (0,2-27%) y convierte cada fallo de decapsulación en una desigualdad sobre la clave. Bastan hasta 30.000. Los autores lo ejecutan de extremo a extremo en ML-KEM-512 sobre Cortex-M4 con un fallo por over-clock.
Por qué importa. Hasta ahora los ataques por fallos a ML-KEM apuntaban a la decapsulación. El trabajo muestra que la generación de claves, una operación única, también debe protegerse.
Para quien asegura. El impacto asegurador directo es limitado, porque requiere acceso físico al dispositivo. Interesa a quien asegura fabricantes de hardware seguro, tarjetas inteligentes o IoT que adoptan ML-KEM.
9. Breaking \mathsf{TraintoDefend} via Adaptive Neuron Clustering in Cryptanalytic Model Extraction
arXiv · Haojie Wu, Haolin Liu, Tianshuo Cong, Guoyan Zhang · Seguridad de IA y LLM
En breve: SimBreak supera TraintoDefend, la única defensa considerada eficaz contra la extracción criptoanalítica de modelos, y eleva la recuperación de firmas del 0% al 100%.
TraintoDefend empuja a las neuronas a tener pesos similares para que sus contribuciones no se distingan. Los autores observan que pesos similares no implican conmutar a la vez y proponen una regla de clustering adaptativa que estima una escala relativa común para dirección de pesos y bias. En seis redes protegidas entrenadas con MNIST, la recuperación pasa del 0% al 100%.
Por qué importa. La similitud de pesos no basta para proteger un modelo de la extracción de parámetros. Las defensas frente a la extracción criptoanalítica deben evaluarse con ataques adaptativos.
Para quien asegura. La relevancia aseguradora es limitada: los resultados son sobre redes pequeñas con MNIST. Para quien protege la propiedad intelectual de modelos de IA, muestra que una defensa publicada puede caer pronto.
10. The Native Menace: Host-to-Browser Cross-Boundary Attacks via Native Messaging
arXiv · Jyotirmay Chauhan, Rownak Islam, Jason Polakis · Web y móvil
En breve: Una app nativa sin privilegios puede abusar de la NativeMessaging API de los navegadores para interceptar datos sensibles o firmar documentos en nombre del usuario.
Primer análisis empírico de seguridad de la NativeMessaging API, el canal entre extensiones del navegador y apps nativas. Una app maliciosa sin privilegios puede interceptar el tráfico o usar otras apps como confused deputy. Los ataques afectan a 1Password, al eID de la UE y a Google Drive, con más de 532 millones de descargas, hasta filtrar el vault entero y firmar documentos arbitrarios.
Por qué importa. El canal carece de raíz de confianza y de atestación del cliente. Los autores proponen cifrar los mensajes con un secreto compartido fuera de banda; el trabajo aparecerá en IEEE S&P 2027.
Para quien asegura. Gestores de contraseñas y firmas digitales son controles clave en los cuestionarios de suscripción. Aquí un malware local los elude, y la difusión de las extensiones afectadas sugiere riesgo de acumulación, con fraude documental y robo de credenciales.
11. Shoot on (Core)Sight: Re-enabling Secure Debug on the RP2350 with Photon-Emission Microscopy and Laser Fault Injection
arXiv · Antoine Plin · Hardware y canales laterales
En breve: Con microscopía de emisión de fotones e inyección de fallos por láser, el autor reactiva el debug Secure del core 1 en el chip RP2350 y extrae un secreto de prueba de 128 bits.
El trabajo muestra que almacenar políticas de forma resistente a fallos no garantiza aplicarlas de forma resistente. La microscopía acota la zona de escaneo láser, que halla dos puntos donde un pulso activa los bits DEBUGEN. Una secuencia guiada solo por la respuesta SWD restablece un acceso estable y, tras el rescue reset, recupera un secreto de prueba de 128 bits.
Por qué importa. El RP2350 es un microcontrolador muy usado y vendido con funciones de seguridad. El ataque exige equipo de laboratorio y acceso físico, pero señala dónde pueden fallar los controles de protección del debug.
Para quien asegura. La relevancia aseguradora es baja: requiere poseer el chip y herramientas costosas. Interesa a quien asegura fabricantes que guardan secretos o firmware protegido en estos chips, por el riesgo de clonación o robo de propiedad intelectual.
12. When File Ingestion Misleads Language Models: Measuring and Mitigating Divergences in Office Documents
arXiv · Penghui Li · Seguridad de IA y LLM
En breve: Los extractores de texto de archivos Office muestran al modelo de lenguaje un contenido distinto del que ve una persona, y esa diferencia es explotable.
Analizando los extractores más usados, el autor identifica 19 canales OOXML donde leen contenido invisible para una persona y 12 donde descartan contenido visible. Con ello construye cinco ataques que, sin inyectar instrucciones, llevan al modelo a interpretar el documento de otro modo que un revisor humano. Cuatro chat assistants y cuatro coding agents populares caen en al menos uno.
Por qué importa. Quien sube contratos, ofertas o informes a modelos de lenguaje no puede suponer que el modelo lee lo que ve el usuario. La defensa propuesta, Prism, reconstruye la vista humana a partir de la especificación OOXML.
Para quien asegura. El riesgo afecta a procesos que usan modelos de lenguaje para revisar documentos, como siniestros, contratos o due diligence: un archivo manipulado puede inducir una valoración errónea sin señales visibles. Conviene incluirlo en los controles sobre el uso de IA del asegurado.
Cómo se elabora este digest
Los nuevos artículos se recopilan cada día y se seleccionan cada semana desde arXiv, el archivo IACR ePrint y las principales conferencias y revistas de seguridad (IEEE S&P, USENIX Security, ACM CCS, NDSS, CRYPTO, PoPETs, IEEE TIFS y otras). Una puntuación basada en fuente, tema y primeras señales identifica a los candidatos; un modelo de inteligencia artificial los evalúa y redacta los resúmenes. Los resúmenes se basan en los abstracts: para los detalles, prevalece el artículo original.
Artículos nuevos evaluados en esta edición: 262.