🚨 SECRET LEAKAGE — TWO NEW ASHPAPERTRAIL FLAWS CAN TURN AUDIT HISTORY INTO A PLAINTEXT SECRET STORE Fields explicitly marked as sensitive can still end up exposed through version history, logs and nested data. CyberSignal Priority: 🟠 HIGH 📅 August 30, 2026 🆔 CVE-2026-75847 · CVE-2026-77970 📊 CVSS 5.9 / 5.9 📦 AshPaperTrail 🏷️ Sensitive Data · Audit Logs · Elixir · Application Security ### 🔎 What happened Two vulnerabilities disclosed today affect AshPaperTrail, a version-history/audit-trail system for applications built around the Ash Framework. The core problem is dangerous because it violates a developer expectation: Marking data as: `sensitive? true` does NOT necessarily mean that value stays redacted from historical versions. --- CVE-2026-75847 AshPaperTrail can place tracked sensitive attributes inside its generated: `changes` map. But that map is configured as: `public? true` and `sensitive? false` Result: a value that the application considers sensitive may still become readable through the version resource. It can also appear in: • normal reads • logs • `inspect` output • error messages --- CVE-2026-77970 The second vulnerability goes deeper. AshPaperTrail's redaction logic can fail to descend into: • embedded resources • unions • lists Meaning a top-level field may look harmless while containing a nested sensitive value such as: credentials API token secret private identifier That nested secret can then be written into the version table in cleartext. ### ⚔️ Exposure chain Application marks value as sensitive ↓ Application action executes ↓ AshPaperTrail records historical change ↓ Redaction logic handles field incorrectly ↓ Sensitive value enters version resource ↓ Audit/version data persists ↓ Reader with access to history recovers plaintext secret For nested values: non-sensitive parent ↓ embedded object / list / union ↓ `sensitive?` child field ↓ redaction does not recurse ↓ secret stored in cleartext ### 🎯 What is affected CVE-2026-75847: AshPaperTrail ≥ 0.1.1 and < 0.7.0 CVE-2026-77970: AshPaperTrail ≥ 0.3.0 and < 0.7.0 Version 0.7.0 is outside the affected ranges documented by the CNA. ### 🧠 Why this matters Security teams usually protect: production database fields ↓ API responses ↓ application UI But historical data often survives elsewhere: audit tables ↓ version records ↓ debug logs ↓ exceptions ↓ observability pipelines ↓ backups That creates a dangerous pattern: The live secret is protected. The historical copy is not. And historical systems often retain data much longer than the original application field. ### ⚠️ Important caveat These CVEs do NOT describe unauthenticated remote extraction of every AshPaperTrail deployment. The attacker needs access to the generated version resource. They are rated Medium, not Critical. There is also no evidence in the CNA disclosures of active exploitation in the wild. But confidentiality impact can still be serious if tokens, credentials or other secrets were historically recorded. ### 🛡️ Defender action Applications using AshPaperTrail should: • upgrade out of affected versions • inspect generated version resources • audit the `changes` field • search historical records for credentials/tokens • inspect embedded resources and nested fields • review logs and exception-management systems • rotate any credential discovered in historical versions And most importantly: Do not stop at patching. If sensitive values were stored historically, upgrading the code does NOT erase the old copies. CyberSignal Insight: **A secret deleted from production may still be alive in its history. Audit trails deserve the same data-classification controls as the database they monitor.** Sources: Erlang Ecosystem Foundation CNA · Ash Project · GitHub Security Advisories · OSV
Post summary
The post discloses two medium‑severity CVEs in AshPaperTrail, detailing how redaction failures expose sensitive data and provides clear remediation steps, including upgrading and auditing historical records.