GHSA-rr87-p3f8-qhxj: 
Python vulnerability analysis and mitigation

Summary

memtomem's shared credential detector (privacy.py, DEFAULT_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. privacy.scan() scans the whole input with no length cap, and it runs on the write path (mem_add and indexing) and in session-tracing redaction, so a crafted text holds that path until the scan finishes. Severity: High (availability). No data is exposed. No CVSS vector or CVE is asserted yet.

Measured (main 2f9eae64, Python 3.13, privacy.scan)

Related

memtomem-stm carries the same rule byte-for-byte in its CREDENTIAL_PATTERNS (GHSA-3v6c-9qpg-gf63, draft). The two advisories are published together.

Fix

The rule is replaced with the linear-time form memtomem-stm adopted, which gives the same yes/no answer, match count and match ends: \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 memtomem also uses match starts (redaction in session tracing, the span_start reported by the privacy audit commands), so scan() restores each JWT match's start to where the old rule began it. The browser-side pattern list keeps the old rule, unchanged.