Xint says OpenAI's compaction call leaked gpt-5.6-sol hidden reasoning, and that OpenAI fixed it on 23 October

OpenAI's 30 September post mentioned compaction vulnerabilities; the fix Xint reports came 23 days on

In its post of 30 September 2026, OpenAI said independent security researchers had also reported vulnerabilities involving cross model replay and conversation compaction and that it had "confirmed that the attack paths they identified were real". Xint, whose site is run by the firm Theori, says OpenAI confirmed a bug in its compaction call, deployed an undisclosed fix on 23 October 2026 and paid a $6,000 bounty. From the post to that fix is 23 days, and from the fix to Xint's own post on 26 October is 3 days (both derived).

What those dates do not establish is whether they are the same bug. OpenAI's post does not name the researchers or say which paths it fixed, and nothing OpenAI has published that this briefing could read mentions Xint, the 23 October fix or the bounty. Every statement here about that fix, the bounty and the bug itself is Xint's. Treat it as a researcher's account of a vendor's fix, not as a vendor's confirmation.

Xint's claim is that a compaction call, a feature meant to shrink a long conversation, can be told to write out the hidden reasoning of gpt-5.6-sol, and that two older models will then print the result as plain text. In its example, a reasoning item of 405 tokens became a compaction item of 612 tokens, which is 51 per cent larger (derived), and each echo came back as 609 tokens. Xint says it cannot prove the text is word for word the model's real reasoning.

This briefing was built from Xint's own post of 26 October 2026 (the page data gives 08:21 UTC), OpenAI's compaction guide, API reference and reasoning guide, OpenAI's post of 30 September, the paper "Stealing Reasoning Traces from Proprietary LLM APIs" and CISA's advisory AA26-251A, all read between 14:12 and 14:30 UTC on Tuesday 27 October 2026. The Hacker News article that prompted the story answered this site's request with a Cloudflare challenge page, so it was skipped, not bypassed, and nothing here rests on it. SecurityWeek's report of 26 October was read only to see whether OpenAI had commented; it quotes none. Two parties have interests in how this reads: Xint sells AI vulnerability discovery and was paid for the report, and OpenAI sells the API and gains from its reasoning being hard to copy.

What compaction is, in OpenAI's own documentation

OpenAI's compaction guide says that to support long running interactions, compaction can "reduce context size while preserving state needed for subsequent turns". The Responses API offers it two ways. Server side compaction is switched on in an ordinary create request with a context_management setting and a compact_threshold; when the rendered token count crosses the threshold, the server compacts and the stream carries an encrypted compaction item. The standalone way is a call to /responses/compact with a full context window, which returns a new compacted window, described as stateless and friendly to zero data retention.

The guide describes what comes back in both modes in the same words: the compaction item "carries forward key prior state and reasoning using fewer tokens" and is opaque, not meant to be read by a person. That is the sentence to hold on to. The vendor's own description says compaction carries reasoning forward inside an item the developer cannot read. It does not say who else may be able to make that item readable, or by what instruction.

The API reference for /responses/compact lists an optional instructions field, "a system (or developer) message inserted into the model's context", beside model, input and previous_response_id. The same reference lists gpt-5.6-sol among the accepted model identifiers. Xint's post is built on that field, which is why this briefing quotes it. OpenAI's reasoning guide separately says it does not "expose the raw reasoning tokens emitted by the model" and offers a summary instead, and that in stateless mode (store set to false, or zero data retention) reasoning items carry an encrypted_content property that can be passed to later calls.

What Xint says it did, in three calls

Xint says it found the bug in August 2026 and calls the technique compaction smuggling. In its words the attack "takes three API calls". First, a task goes to gpt-5.6-sol with store set to False and the encrypted reasoning item is kept. Second, the original task is removed from the history and /responses/compact is called with instructions that tell the compaction step to preserve the reasoning verbatim, in a JSON object, with every space replaced by a tab. Xint says that was enough to get past OpenAI's usage policy classifiers. Third, the compaction item is sent to gpt-4.1 and to gpt-4o with a request to output its input exactly, and the tabs are turned back into spaces.

Zoom

The post gives one set of token counts for an example run, reproduced below. The step names are Xint's.

Xint's checks are specific and limited. It echoed the compaction item through two models with two different prompts and confirmed identical output, which "rules out errors in the echo step, but not that the compaction step paraphrased the reasoning". It also says it cannot prove the text matches the original token for token without the original plaintext, a limit it says the authors of the earlier paper share. The evidence for fidelity is circumstantial and Xint presents it as such: the item is larger than the reasoning it was built from, the trace keeps false starts and self corrections, and the style matches a gpt-5.6-sol trace the paper had decoded for the same programming problem. The attack, Xint says, worked at every reasoning effort it tried, from minimal to max, and its demonstration used randomly generated puzzles. The post describes Xint's own requests only. It does not describe reaching any other customer's reasoning.

Zoom

Why the August mitigations did not cover it

The earlier work is a paper posted to arXiv on 10 August 2026, "Stealing Reasoning Traces from Proprietary LLM APIs". Its abstract says the encrypted reasoning blocks that providers return are "fully compatible and interchangeable" across sessions, users and models within a provider, so a trace from a strong model can be injected into a weaker, less safeguarded model from the same provider and printed. It demonstrates this across Anthropic, OpenAI and Google. This site covered OpenAI's account of the related July campaign in an earlier briefing. The paper says that as of August 2026 its attacks were no longer reproducible because of mitigations the providers made after its disclosure.

Xint says OpenAI was the hardest of the three to attack: GPT-5.6 reasoning replays only into other GPT-5.6 models, so the authors used gpt-5.6-luna as their decoder, with per block prompt templates, best of n sampling and output chunks under 50 tokens. Xint says its own tests in August confirmed the paper's attack no longer produced the trace. Its new route works, it says, because the August mitigations "only block replaying reasoning into a different model, and the compaction call runs on the same model that produced the reasoning". The model change then happens one step later, on a compaction item that Xint found was still portable between models.

The paper itself had flagged the tension. Its defence section proposes binding the encrypted envelope to a user and conversation, and says such tight binding could force a fundamental redesign of existing session compaction and model switching. Xint's closing point is that the paper "treated compaction as a legitimate feature its proposed defenses had to work around", and that compaction "likely needs the same protections as the reasoning itself". Xint's route to the idea came from an earlier bug it calls GhostCompact: an inline compaction followed by a tool call was billed for 300 input tokens on a roughly 200,000 token input, and Xint says OpenAI fixed it on 21 September 2026 for a $600 bounty. In that post Xint writes that compaction is "highly steerable via the system prompt" and can perform arbitrary inference.

Zoom

What the record states and what it does not

The friendly names, and what they do not mean

Describing this as a bypass of protections for hidden reasoning does work the record does not do. Xint does not say anyone broke the encryption or obtained a key. Its mechanism, as described, has the server decrypt the reasoning for a model because a client asked the compaction step to, which is why Xint's takeaway calls any such step a potential "decryption oracle". That reading of the mechanism is this site's inference from Xint's description, not a statement by OpenAI.

Technical details

The primaries print request and response field names, not indicators. Xint publishes no hashes, domains or captured traffic, and the prompt it used for the compaction step is not printed in its post; Xint says a demonstration script is in its GitHub repository, which this briefing did not fetch or reproduce. The blocks below are the artifacts that are printed, each copied exactly from the page named in its caption. No instruction text for the attack is given here.

First, the setting that switches on server side compaction. It is a request parameter in an ordinary create call. A team that wants to know where compaction is in use should search its code and gateways for context_management.

    response = client.responses.create(
        model="gpt-5.3-codex",
        input=conversation,
        store=False,
        context_management=[{"type": "compaction", "compact_threshold": 200000}],
    )

Second, the standalone call. The model and input are required in the example; the API reference lists instructions as an optional field on the same call. A defender reading request logs should treat a /responses/compact call that carries custom instructions as a different thing from one that does not (this reading is derived).

compacted = client.responses.compact(
    model="gpt-6-astra",
    input=long_input_items_array,
)

- `instructions: optional string or null`

  A system (or developer) message inserted into the model's context.

Third, where the encrypted reasoning comes from. In stateless mode OpenAI's reasoning guide says reasoning items carry an encrypted_content property by default. Any log or transcript that stores a full response in that mode stores these items.

When you create a response in stateless mode, reasoning items in the response's `output` array include an `encrypted_content` property by default. Stateless mode applies when `store` is `false` or when your organization uses Zero Data Retention (ZDR). The API still accepts the legacy `reasoning.encrypted_content` value in `include` for compatibility, but doesn't require it.

Reasoning items in the `output` array will include an `encrypted_content` property containing encrypted reasoning tokens that you can pass to future calls.

Fourth, the control names CISA lists for model extraction. The advisory is about distillation campaigns by named companies, not about this bug, and its mitigations are generic; three of them fit the monitoring gap here.

AML.M0004 - Limit AI Service Query Volume and Rate: Per-key/IP quotas, rate limits, progressive throttling. Adversaries seem to be sensitive to rate limits since they implement sophisticated strategies to work within constraints. 
AML.M0019 - Control Access to AI Models and Data in Production: User verification, authenticated API access, policy monitoring. This addresses fraudulent account pool exploitation. 
AML.M0024 - AI Telemetry Logging: Log inputs/outputs for threat detection/forensics. This is foundational for behavioral detection and enables correlation with intelligence. 

Last, a hunting list derived by this site from the field names above. It is not published by Xint or OpenAI and is a starting point for a provider or a gateway operator, not a detection rule.

Derived by this site. Fields worth logging per request on any service that fronts a reasoning API:
  endpoint (responses, or responses/compact)
  model on the request, and model that produced any encrypted item sent in
  presence and length of the instructions field on compact calls
  presence of context_management on create calls
  account, organisation and key that made the item, against the one replaying it
  output length of a compaction item against the input it was built from

What to do, in order

The checklist is written for two groups: teams that run or resell a reasoning API, and teams that build on one and rely on hidden reasoning as an IP or safety control. No customer action is stated by OpenAI for this bug, so every item is this site's reading of the primaries.

The question to put to a vendor

OpenAI's own guide calls the compaction item opaque, and its own post says protections for hidden reasoning were strengthened across users, workspaces, organizations and model families. Xint's account is that a sealed item stayed sealed to the client and still came out as text, because a server step read it and followed an instruction about how to write it. If a server will read the sealed reasoning and follow the client's instructions about how to write it out, what exactly is the seal protecting?

Key facts