activation cache uses pickle.load (unsafe deserialization) — correction: the zip-slip vector does NOT reproduce

[EvolveAegis]

Correction (2026-08-04)

I need to correct this report. My original write-up claimed a zip-slip → pickle RCE chain. I re-tested the zip-slip leg locally and it does not reproduce: on Python 3.13, zipfile.ZipFile.extractall sanitizes traversal — entries with .., absolute paths, or sub/../ all land inside the target directory and do not escape. So the zip-slip write primitive I described is not real, and the "RCE chain" framing is withdrawn.

What does hold:

What still holds: pickle.load on the activation cache (unsafe deserialization, CWE-502)

• src/memos/memories/activation/kv.py:158 and src/memos/memories/activation/vllmkv.py:164 both do data = pickle.load(f) over cache files.
• A crafted pickle runs arbitrary code on load (confirmed: pickle.load of a __reduce__-based payload executed the canary).

I have not demonstrated a working write primitive that lets an attacker plant a malicious cache file on disk, so I am not claiming this is a proven RCE — it is an unsafe-deserialization sink that should be hardened regardless (treat the cache as untrusted input: use a non-executable format like JSON/safetensors, or load only from a trusted, integrity-checked location).

Apologies for the over-stated original report; I've edited it down to the verified sink.

Suggested change

Replace pickle.load on the activation cache with a safe format (JSON/safetensors) or a safe-pickle variant, and/or load only from a trusted, non-writable location with an integrity check.

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 5845caaa9f3b7735
Working branch: bugfix/autodev-2203-20260804015142516
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[EvolveAegis]

Correction (2026-08-04)

I need to correct this report. My original write-up claimed a zip-slip → pickle RCE chain. I re-tested the zip-slip leg locally and it does not reproduce: on Python 3.13, zipfile.ZipFile.extractall sanitizes traversal — entries with .., absolute paths, or sub/../ all land inside the target directory and do not escape. So the zip-slip write primitive I described is not real, and the "RCE chain" framing is withdrawn.

What does hold:

What still holds: pickle.load on the activation cache (unsafe deserialization, CWE-502)

• src/memos/memories/activation/kv.py:158 and src/memos/memories/activation/vllmkv.py:164 both do data = pickle.load(f) over cache files.
• A crafted pickle runs arbitrary code on load (confirmed: pickle.load of a __reduce__-based payload executed the canary).

I have not demonstrated a working write primitive that lets an attacker plant a malicious cache file on disk, so I am not claiming this is a proven RCE — it is an unsafe-deserialization sink that should be hardened regardless (treat the cache as untrusted input: use a non-executable format like JSON/safetensors, or load only from a trusted, integrity-checked location).

Apologies for the over-stated original report; I've edited it down to the verified sink.

Suggested change

Replace pickle.load on the activation cache with a safe format (JSON/safetensors) or a safe-pickle variant, and/or load only from a trusted, non-writable location with an integrity check.

[EvolveAegis]

Closing: I re-ran the PoC and the zip-slip vector does not reproduce (Python 3.x extractall sanitizes ../ and absolute-path entries), so the RCE chain I described is withdrawn. The pickle.load on the activation cache is a real unsafe-deserialization sink, but without a demonstrated write primitive to plant a malicious cache file it's a latent hardening item rather than an exploitable bug — not worth an open issue. Apologies for the over-stated original report.