GHSA-3v6c-9qpg-gf63: 
Python vulnerability analysis and mitigation

Summary

memtomem-stm's shared credential detector (proxy/privacy.py, CREDENTIAL_PATTERNS) contains a JWT rule whose cost is quadratic in the length of a run of base64url characters: \beyJ[A-Za-z0-9_-]{8,}.[A-Za-z0-9_-]{8,}.[A-Za-z0-9_-]{8,}\b A match can be attempted after every - inside such a run, and each attempt scans to the end of the run. The detector runs synchronously on the proxy's event loop for upstream tool responses: response cache set/get/sweep, the pending-store credential gate, tool eligibility, extraction, and the LLM-compression privacy scan. So while one crafted response is being scanned, every other call through the proxy waits. Severity: High (availability). No data is exposed. The stall ends when the scan finishes. No CVSS vector or CVE is asserted yet.

Measured (main 5897eb75, Python 3.13)

Related

LTM core (memtomem) carries the same rule byte-for-byte in its privacy.DEFAULT_PATTERNS. That is tracked separately, and publication of this advisory should be coordinated with its fix.

Fix

The rule is replaced with a form that gives the same yes/no answer, match count and match ends, in linear time and constant regex memory: \beyJ(?=[A-Za-z0-9_-]{8})[A-Za-z0-9_]+(?:-(?!eyJ[A-Za-z0-9_-]{8})[A-Za-z0-9_]+)*+.[A-Za-z0-9_-]{8,}.[A-Za-z0-9_-]{8,}\b The first segment does not cross another start that has eight characters after it, so the attempts scan disjoint regions. It is consumed possessively, so no backtracking state accumulates. A match can begin at a later eyJ in the same run, with the same end, but STM consumes only the yes/no answer. The fix is checked against the old rule as an oracle on 20,000 seeded random strings plus structured cases. Four mutations of the rewrite each fail the checks. On the stall inputs it finishes within 2 s with under 8 MiB of traced memory; the inputs include 256 KB of eyJ-, a 1 MB segment, and a 1 MB hyphen-dense segment.