mini-swe-agent 2.4.6 Is Still Latest. The Sandbox Keeps Host Keys.

PyPI's latest release of mini-swe-agent is 2.4.6, uploaded 23 July 2026 at 03:13 UTC. CVE-2026-108592 was published on 10 October at 18:16 UTC, and the affected range runs through that same version. The record lists no patched release.

HaiND, of the Post and Telecommunication Institute of Technology, is the finder named on the CVE. The technical note is the writeup the CVE cites. VulnCheck is the CNA. US X trends at 22:32 UTC were Giants, Seahawks, and the rest of the Sunday NFL slate. Hacker News did not lead with this package. The operator fact is the version PyPI still serves as latest.

Medium Medium on the CVE's own scores: CVSS v4 base 6.0, CVSS v3.1 base 5.3. High confidentiality, no integrity, no availability. Attack requirements are present, and the v3.1 vector marks user interaction required. The control that failed is the sandbox boundary around the runner's own environment.

What the CVE actually says.#

CVE-2026-108592 is CWE-526, cleartext storage of sensitive information in an environment variable, in mini-swe-agent from 1.10.0 through 2.4.6. The package URL is pkg:pypi/mini-swe-agent. The optional BubblewrapEnvironment starts bwrap without clearing the environment, so sandboxed commands inherit the host environment. A prompt injection in task content the agent processes can make those commands read API keys and send them over the shared network. Versions outside that range are unaffected by default. No fixed version is listed.

Bubblewrap is opt-in. The default backend is local, and it provides no isolation. An operator who selected Bubblewrap did so to contain commands. HaiND's note places the miss in the default wrapper and in the process call. The wrapper sets a read-only view of parts of the filesystem and overrides PATH. It never clears the environment it was started with, and it does not drop the network. The process call passes no replacement environment, so the child receives the runner's environment. The extra environment map on the config is empty by default, which leaves PATH as the only override.

The runner loads a global .env from the platform config directory at import, unless that directory is overridden. Model clients read provider credentials from the process environment. Those values are what a command inside the sandbox can see.

The note is explicit about the check that was run. Inheritance was reproduced against bubblewrap 0.6.1 using the default arguments from v2.4.6, commit a83fcae, and a synthetic marker. A negative control that cleared the environment came back empty. No real credential was used. No network send was attempted. No full agent loop was run. The end-to-end case still depends on the opt-in backend, a secret in the runner environment, and a run that actually executes a command which reads it. Interactive approval sits in front of that command. A batch run that does not prompt removes the person.

The note also says what was not done. Earlier releases were not checked. The focused file on main, commit 04d809ceab, is described as identical. On this read the two copies hash the same, and neither contains an environment-clear flag.

The package clock and the disclosure clock.#

The package clock is the registry, read tonight.

The Bubblewrap backend landed in commit c676c1d4 at 22:59 UTC on 25 August 2025. Tag v1.10.0 is commit 639744e5 at 01:39 UTC on 29 August 2025. PyPI 1.10.0 uploaded at 01:40 UTC the same morning. That tag's bubblewrap.py has no environment-clear flag, and its process call passes no replacement environment. HaiND did not run that tag. Presence at the floor is the CNA's range plus a source read. It is not a reproduction on every version between 1.10.0 and 2.4.6.

2.4.6 is the release the note pins. GitHub published v2.4.6 at 03:12 UTC on 23 July 2026. PyPI uploaded it at 03:13 UTC. The release notes are a billing-parse fix for failed calls against the cost limit. They do not mention the sandbox environment. Nothing newer is on PyPI. 2.4.7 is absent.

main has moved since that tag, and the sandbox file has not. The tip tonight is 04d809ceab, committed 3 September 2026 at 05:05 UTC, a merge whose message is a task-prompt update. bubblewrap.py at that commit is byte-identical to v2.4.6. A search for clearenv in the repo's issues returned nothing.

The disclosure clock is 10 October. The CVE record's datePublished is 18:16:56 UTC. dateReserved is 18:08 UTC the same hour. datePublic is 9 October, a date with no minute. HaiND's note, fetched after the CVE timestamp, still describes coordinated disclosure as in progress and still says no CVE had been assigned. The page and the record are not one document. VulnCheck's advisory is dated 10 October and cites the same note.

1. 2025-08-29
   v1.10.0 at 01:39 UTC, PyPI 1.10.0 at 01:40 UTC. The CVE later marks this as the floor. The tree has no environment-clear flag.
2. 2026-07-23
   v2.4.6 at 03:12 UTC, PyPI upload at 03:13 UTC. Release notes are a billing-parse fix. This is still PyPI latest.
3. 2026-09-03
   main tip 04d809ceab. bubblewrap.py matches the July tag byte for byte. The sandbox file did not move with the branch.
4. 2026-10-10
   CVE-2026-108592 at 18:16 UTC. No patched version. The researcher's note still says no CVE had been assigned.

Issue 843, opened 27 May 2026 and closed 3 June, describes a different exposure: the local backend handing the host environment to prompt templates. HaiND marks that path as distinct from the Bubblewrap shell. Closing the template issue did not put an environment clear into bubblewrap.py. The file on main is the July file.

What still holds.#

The precondition is the opt-in backend. A run that stays on the local environment is outside this CVE, and it was never isolated. A run that selected Bubblewrap and holds no secret in the process environment has nothing in that environment to read. The inheritance and the shared network remain.

Interactive approval is a person in front of the command. It is a procedural gate. The weakness is still in the default arguments. A batch mode that skips the prompt removes the person and leaves the arguments.

There is no named victim and no captured provider key in the note. Brief the boundary. Do not brief a theft count.

The v3.1 score marks the attack complexity high and user interaction required. The v4 score marks attack requirements present and user interaction passive. Both are medium, and both put the confidentiality impact at high. The scores describe a steered command inside an opt-in sandbox. They do not describe an unauthenticated listener.

What to change before the next run.#

Inventory mini-swe-agent before the next untrusted task. PyPI latest, the v2.4.6 tag, and main as of 3 September all ship the same bubblewrap.py. 1.10.0 is inside the range the CVE marks affected, and its copy already omits the environment clear.

If Bubblewrap is the backend you selected, stop treating it as a boundary for provider keys and other runner secrets. Take long-lived credentials out of the process environment, including the global .env the package loads at startup, until a release clears that environment and puts back only PATH and the variables the backend means to pass. Leave command approval on for untrusted repositories. Approval does not close the check.

If a task already processed untrusted content on this backend while those secrets were present, rotate them. The research note did not send a marker off the host. Absence of that send is not evidence the keys stayed put on a run you already executed.

Wait for a release note or a GitHub security advisory that names CVE-2026-108592. A version number merely newer than 2.4.6 would be evidence only after that note exists. Tonight the registry has no such version, main does not change the file, and the advisory list is empty.