Compaction smuggling: raționamentele OpenAI extrase prin API
Xint a ocolit protecțiile OpenAI pentru raționamentele criptate prin compaction: risc de distilare. Detalii tehnice și ce să ceri furnizorilor de IA.

Firma de cercetare Xint a publicat pe 26 octombrie 2026 detaliile unei tehnici numite compaction smuggling, care permitea extragerea în clar a urmelor de raționament ale modelelor de frontieră OpenAI prin API-ul său. Tehnica ocolea măsurile introduse de OpenAI în august pentru o problemă similară. OpenAI a confirmat vulnerabilitatea, a corectat-o și i-a plătit lui Xint o recompensă de 6.000 de dolari pe 23 octombrie 2026. Știrea este relatată de SecurityWeek, CSO Online, The Hacker News și Infosecurity Magazine.
Contextul: raționament criptat și compaction
Modelele de raționament returnează, împreună cu răspunsul, pașii raționamentului în formă criptată: aplicația îi trimite înapoi modelului în cererile următoare, astfel încât modelul își păstrează continuitatea „gândirii” fără ca clientul să-i poată citi. Pentru a nu depăși fereastra de context, compaction comprimă istoricul conversației, apelurile către instrumente și starea lucrului într-un rezumat, returnat tot ca element criptat.
Potrivit unui analist citat de CSO Online, elementele de compaction sunt portabile între modele dintr-un motiv funcțional: permit instrumentelor agentice precum Codex să schimbe modelul în mijlocul sesiunii.
În august, studiul Stealing Reasoning Traces from Proprietary LLM APIs (publicat pe 10 august) a arătat că raționamentul criptat al unui model de frontieră putea fi retrimis unui model mai slab al aceluiași furnizor și determinat să-l transcrie. CSO Online menționează printre consecințele posibile extragerea de date la scară largă, injecții de prompt invizibile și inserarea de conținut malițios în rulări agentice publice; SecurityWeek vorbește și despre extragerea de date personale. OpenAI a reacționat blocând reutilizarea raționamentului într-un model diferit de cel care l-a generat.
Cum funcționează compaction smuggling
Potrivit articolului Xint, semnat de cercetătorul Tim Becker și citat de CSO Online, atacul are trei etape:
- Capturarea raționamentului: se trimite o sarcină unui model de raționament (Xint dă ca exemplu gpt-5.6-sol), se capturează raționamentul criptat, se elimină sarcina originală din istoric și se păstrează raționamentul exact așa cum este.
- Modelarea compaction: se cere ca raționamentul să fie inclus în compaction ca valoare a unei chei
solutionîntr-un obiect JSON, cu fiecare spațiu înlocuit cu un tab. Potrivit Xint, acest lucru era suficient pentru a trece de clasificatoarele OpenAI pentru politicile de utilizare. - Transcrierea de către alt model: elementul de compaction criptat, încă portabil, este trimis către gpt-4.1 și gpt-4o cu cererea de a returna intrarea exact așa cum este. Modelele se conformau; rămânea doar decodarea JSON-ului și refacerea spațiilor.
Punctul slab, explică Xint, este că măsura din august bloca doar trecerea raționamentului către un model diferit, în timp ce compaction rulează pe același model care a produs raționamentul. Atacul a funcționat la toate nivelurile de efort de raționament testate.
Becker a declarat pentru CSO Online că o parte din cronologie nu este cunoscută: OpenAI nu a publicat când a aplicat corecția și, spre deosebire de patch-urile tradiționale, un furnizor de modele poate face modificări fără niciun anunț. OpenAI nu a răspuns solicitării de comentariu a CSO Online.
De ce contează: distilarea
Riscul principal semnalat de SecurityWeek este distilarea: folosirea raționamentului unui model avansat pentru a antrena ieftin un model concurent. SecurityWeek amintește avertismentul de la începutul lui septembrie în care CISA (împreună cu NSA și FBI, potrivit unui analist citat de CSO Online) atribuia companiilor DeepSeek, Moonshot AI, Alibaba, MiniMax, StepFun și Z.AI extragerea a miliarde de tokeni, în milioane de cereri, din modele americane precum Claude, GPT, Gemini și Grok, cel puțin de la sfârșitul lui 2024.
Pentru companiile care folosesc API-ul, problema nu este un furt direct al datelor lor, ci un semnal despre modelul de securitate al platformelor de IA. CSO Online amintește și cazul AWS, care a trebuit să corecteze din nou în septembrie o problemă deja corectată în aprilie.
Impactul pentru companiile europene și italiene
Analiștii intervievați de CSO Online sunt de acord asupra câtorva puncte:
- funcții legitime ale platformei, combinate între ele, pot ocoli protecții gândite pentru o singură cale de atac;
- vulnerabilitățile platformelor de IA vin fără CVE, fără buletin și fără note de lansare: gestionarea vulnerabilităților bazată pe fluxurile CVE nu le vede;
- un „rezolvat” al furnizorului acoperă adesea cazul raportat, nu întreaga clasă de slăbiciuni; de aceea un analist sugerează să consideri lizibil orice conținut criptat returnat de aceste API-uri.
Pentru entitățile NIS2, furnizorii de servicii de IA intră în securitatea lanțului de aprovizionare (articolul 21): au nevoie de aceleași clauze și verificări ca orice alt furnizor critic.
Ce să faci acum
- Fă inventarul aplicațiilor care folosesc API-uri de modele de raționament, compaction sau starea conversației pe partea clientului și al locurilor unde sunt salvate aceste elemente (loguri, baze de date, cozi).
- Tratează raționamentul și compaction criptate ca date sensibile: aceleași controale de acces și aceleași perioade de păstrare ca pentru conținutul în clar.
- Întreabă-ți furnizorii de IA cum a fost verificată o corecție pe funcțiile conexe și dacă au făcut o analiză a variantelor: au corectat cazul raportat sau clasa de probleme?
- Include în contracte obligația de a notifica problemele de securitate și regresiile corecțiilor.
- Desemnează pe cineva să urmărească publicațiile cercetătorilor despre platformele de IA pe care le folosești, pentru că nu vin sub formă de CVE.
- Repetă-ți propriile teste după fiecare corecție anunțată de furnizor, în loc să te bazezi doar pe comunicarea lui.
- Dacă expui tu însuți modele prin API, urmărește tiparele de extragere (volume mari de cereri sistematice) și verifică faptul că obiectele de stare trimise înapoi de clienți nu pot fi reutilizate în afara contextului prevăzut.
Ultima actualizare:


