loggingredactor CVE-2026-63417

Exposure occurs only when an application running loggingredactor prior to 0.0.7 logs a non-primitive/custom object whose __str__ or __repr__ method returns PII (e.g. a class whose __str__ yields an email address); primitive values and the explicitly-handled types were already redacted, and numeric conversions (%d/%f) were unaffected. Limiting factors: the vulnerable versions must be in use (<0.0.7), the application must actually log such custom objects rather than pre-formatted strings, and a party must be able to read the resulting logs to obtain the PII - there is no active, attacker-triggered exploitation path. The only complete fix per the vendor is upgrading to 0.0.7; the advisory states there is no workaround without patching.

The input CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) yields 8.2 and drives the 'VC:H' confidentiality impact, but this is a redaction-library failure (CWE-532), not a classic remote-code or injection flaw: there is no attacker who 'sends' anything to the library. The real signal is AT:P - successful exposure depends on a condition outside any attacker's control, namely that the host application actually logs a non-primitive/custom object whose __str__ or __repr__ returns PII. No EPSS score is provided, so widespread-exploitation probability cannot be quantified. KEV status is NO (not listed by CISA), and no working exploit code is referenced - only the GHSA advisory, the issue report (#12), the fix PR (#15), the patch commit, and the 0.0.7 release. The vuln.today Decision label is 'this_week', consistent with a real but non-emergency fix priority rather than act_now/emergency. Net: this is a genuine privacy-exposure bug that matters wherever the library is relied on to mask PII, but the headline 8.2 overstates urgency - there is no automatable remote exploit, exposure is contingent on specific logging patterns, and realizing harm additionally requires an adversary (or unauthorized party) to be able to read the resulting logs. Note the AV:N rating is debatable: the flaw's impact is realized at the log sink, so whether network reach truly applies depends on where logs are shipped - verify against your deployment.

An application using loggingredactor <0.0.7 logs a custom object (e.g. a User or Account instance) whose __str__/__repr__ embeds an email, SSN, or token; the redactor only handled primitive and explicitly-supported types, so the object's string output passes through unredacted and the PII is written verbatim to the log stream. Anyone who can read those logs - operators, downstream log aggregators, or an unauthorized party with log access - then obtains the sensitive values the filter was trusted to mask. No working public exploit code is identified; only the advisory, issue, and patch references exist.