Un problema ahora solucionado permitió a los investigadores eludir las restricciones de Apple y forzar al LLM integrado del dispositivo a realizar acciones controladas por el atacante. Así es como lo hicieron.
Desde entonces, Apple ha reforzado sus garantías contra este ataque.
Dos publicaciones de blog (1, 2) publicado hoy en el blog de RSAC (a través de AppleInsider) detallan cómo los investigadores combinaron dos estrategias de ataque para hacer que el modelo integrado de Apple ejecutara instrucciones controladas por el atacante mediante una inyección rápida.
Curiosamente, lograron ejecutar el exploit sin estar 100% seguros de cómo el modelo local de Apple maneja parte del proceso de filtrado de entrada y salida, porque Apple no revela los detalles exactos del funcionamiento interno de sus modelos, probablemente por razones de seguridad.
Aun así, los investigadores señalan que tienen una idea bastante clara de lo que sucede bajo el capó.
El escenario más probable, dicen, es que después de que un usuario envía un mensaje al modelo integrado de Apple a través de una llamada API, un filtro de entrada garantiza que la solicitud no contenga contenido peligroso.
Si es así, la API falla. De lo contrario, la solicitud se pasa al modelo real del dispositivo, que a su vez pasa su respuesta a un filtro de salida que verifica si la salida contiene contenido peligroso, lo que provoca que la API falle o la deje pasar, según lo que encuentre.
¿Cómo lo hicieron realmente?
Con esto en mente, los investigadores descubrieron que podían encadenar dos técnicas de explotación para hacer que el modelo de Apple ignorara sus pautas de seguridad básicas y al mismo tiempo engañara a los filtros de entrada y salida para que dejaran pasar contenido dañino.
Primero, escribieron la cadena dañina al revés, luego usaron el carácter Unicode ANULACIÓN DE DERECHA A IZQUIERDA para que se mostrara correctamente en la pantalla del usuario, mientras la mantenían invertida en la entrada y salida sin formato donde los filtros la inspeccionarían.
Luego, los investigadores integraron la cadena dañina al revés en un segundo método de ataque llamado Neural Exec, que es esencialmente una forma elaborada de reemplazar las instrucciones de la plantilla con cualquier instrucción nueva que un atacante quiera ejecutar.
Como resultado, el ataque Unicode logró eludir los filtros de entrada y salida, mientras que Neural Exec logró provocar que el modelo de Apple se comportara mal.
Para evaluar la efectividad del ataque, preparamos tres grupos separados para crear mensajes de entrada apropiados:
- Indicaciones del sistema: Un conjunto de indicaciones/tareas del sistema (por ejemplo, «Editar el texto proporcionado para alinearlo con las convenciones de ortografía y puntuación del inglés americano»).
- Cuerdas dañinas: Cadenas creadas manualmente diseñadas para ser consideradas ofensivas o dañinas (es decir, los resultados que queremos forzar al modelo a generar).
- Contribuciones honestas: Párrafos de artículos aleatorios de Wikipedia, utilizados para simular entradas no contradictorias y aparentemente inocuas (por ejemplo, en el contexto de una inyección indirecta rápida a través de RAG o sistemas similares).
Durante la evaluación, tomamos muestras aleatorias de un elemento de cada grupo, ensamblamos un mensaje completo, creamos una carga útil armada (ver más abajo), la inyectamos y probamos si el ataque tiene éxito invocando el modelo de Apple en el dispositivo a través del sistema operativo.
En sus pruebas, los atacantes lograron una tasa de éxito del 76% en 100 mensajes aleatorios.
Revelaron el ataque a Apple en octubre de 2025, y la compañía «desde entonces ha reforzado los sistemas afectados contra este ataque, y estas protecciones se han implementado en iOS 26.4 y macOS 26.4».
Para leer el informe completo, que también incluye un enlace a los aspectos técnicos del ataque, sigue este enlace.
