CVE-2026-75847: ash-project/ash_paper_trail

CISO Take

AshPaperTrail, the audit-trail/versioning library for the Elixir Ash framework, fails to redact attributes marked sensitive?: true — it computes the version resource's sensitivity from an ignore_attributes list that defaults to empty, so tracked sensitive values are stored and served in plaintext by the default read action and also spill into application logs, inspect output, and error messages. There's no CVSS score, no KEV listing, no public exploit or scanner, and exploitation requires nothing more than read access to a resource most apps already expose to internal roles or admins — meaning the real risk is quiet, credential-adjacent data exposure (API keys, PII, tokens tracked in versioned records) rather than remote takeover. Any AI/ML platform using Ash + AshPaperTrail to version records containing model credentials, dataset access tokens, or user PII in its data layer inherits this exposure across every audit trail entry ever created. Upgrade to ash_paper_trail 0.7.0+ immediately, then audit historical version records and logs for previously-leaked sensitive values (rotate any credentials found), and in the interim restrict read access to version resources and scrub sensitive fields from log sinks.

Sources: NVD GitHub Advisory

What is the risk?

Medium severity per the advisory, but exploitability is trivial once an attacker or over-privileged internal user has read access to the generated version resource — no authentication bypass, injection, or special tooling is required, just the default read action. Impact is confidentiality-only (no integrity/availability effect) but can cascade if the leaked sensitive attributes are credentials, tokens, or PII, enabling secondary compromise. No CISA KEV listing, no EPSS data, and no public exploit/PoC exist, indicating this is not being actively targeted; risk is driven by exposure surface (how many systems store secrets in Ash resources with paper-trail versioning enabled) rather than by attacker sophistication.

How does the attack unfold?

Precondition

Attacker or over-privileged internal user obtains read access to the application's AshPaperTrail-generated version resource (e.g., via an admin panel, internal API, or compromised low-privilege account).

Exploitation

Because ignore_attributes defaults to empty, the changes map is incorrectly marked sensitive?: false, so the default read action returns tracked sensitive attribute values in plaintext.

Data exposure

The same unredacted values also appear in application logs, Elixir inspect/IEx output, and error messages, widening the exposure beyond the API response itself.

AML.T0055

Impact

Attacker recovers plaintext sensitive data (PII, tokens, credentials) from version history or logs, enabling account takeover, compliance violations, or further lateral movement.

Precondition

Attacker or over-privileged internal user obtains read access to the application's AshPaperTrail-generated version resource (e.g., via an admin panel, internal API, or compromised low-privilege account).

Exploitation

Because ignore_attributes defaults to empty, the changes map is incorrectly marked sensitive?: false, so the default read action returns tracked sensitive attribute values in plaintext.

Data exposure

The same unredacted values also appear in application logs, Elixir inspect/IEx output, and error messages, widening the exposure beyond the API response itself.

AML.T0055

Impact

Attacker recovers plaintext sensitive data (PII, tokens, credentials) from version history or logs, enabling account takeover, compliance violations, or further lateral movement.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
ash-project/ash_paper_trail	—	—	No patch
ash_paper_trail	—	—	No patch

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade ash_paper_trail to 0.7.0 or later, which fixes the sensitivity derivation to reflect actually-tracked attributes rather than the (typically empty) ignore_attributes list. 2) Audit existing version resource tables and application logs for previously-exposed sensitive values and rotate any credentials/tokens found. 3) Until patched, restrict read access to generated version resources to the minimum necessary roles, and review log redaction/scrubbing configuration to strip sensitive fields before they reach log sinks. 4) After upgrading, verify via the resource's introspection that changes maps for resources with sensitive?: true attributes are now correctly flagged sensitive?: true and redacted in default read output, logs, and error messages. Reference patch commit: github.com/ash-project/ash_paper_trail/commit/90efdb0769f83f7c5daba6a87758daebf4baf32c.

How is it classified?

Data Leakage Privacy Violation Framework AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 10 - Data and data governance

ISO 42001

A.7.4 - Data for AI systems

NIST AI RMF

MANAGE-4.1 - Risk monitoring and data protection

Frequently Asked Questions

What is CVE-2026-75847?

AshPaperTrail, the audit-trail/versioning library for the Elixir Ash framework, fails to redact attributes marked sensitive?: true — it computes the version resource's sensitivity from an ignore_attributes list that defaults to empty, so tracked sensitive values are stored and served in plaintext by the default read action and also spill into application logs, inspect output, and error messages. There's no CVSS score, no KEV listing, no public exploit or scanner, and exploitation requires nothing more than read access to a resource most apps already expose to internal roles or admins — meaning the real risk is quiet, credential-adjacent data exposure (API keys, PII, tokens tracked in versioned records) rather than remote takeover. Any AI/ML platform using Ash + AshPaperTrail to version records containing model credentials, dataset access tokens, or user PII in its data layer inherits this exposure across every audit trail entry ever created. Upgrade to ash_paper_trail 0.7.0+ immediately, then audit historical version records and logs for previously-leaked sensitive values (rotate any credentials found), and in the interim restrict read access to version resources and scrub sensitive fields from log sinks.

Is CVE-2026-75847 actively exploited?

No confirmed active exploitation of CVE-2026-75847 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-75847?

1) Upgrade ash_paper_trail to 0.7.0 or later, which fixes the sensitivity derivation to reflect actually-tracked attributes rather than the (typically empty) ignore_attributes list. 2) Audit existing version resource tables and application logs for previously-exposed sensitive values and rotate any credentials/tokens found. 3) Until patched, restrict read access to generated version resources to the minimum necessary roles, and review log redaction/scrubbing configuration to strip sensitive fields before they reach log sinks. 4) After upgrading, verify via the resource's introspection that changes maps for resources with sensitive?: true attributes are now correctly flagged sensitive?: true and redacted in default read output, logs, and error messages. Reference patch commit: github.com/ash-project/ash_paper_trail/commit/90efdb0769f83f7c5daba6a87758daebf4baf32c.

What systems are affected by CVE-2026-75847?

This vulnerability affects the following AI/ML architecture patterns: data governance / audit-trail layers, MLOps metadata tracking.

What is the CVSS score for CVE-2026-75847?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

data governance / audit-trail layersMLOps metadata tracking

MITRE ATLAS Techniques

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 10

ISO 42001: A.7.4

NIST AI RMF: MANAGE-4.1

What are the technical details?

Original Advisory

Cleartext Storage of Sensitive Information vulnerability in ash-project ash_paper_trail allows an attacker with read access to the generated version resource to recover the plaintext of sensitive? attributes. AshPaperTrail stores the values of tracked sensitive? attributes in the generated version resource's changes map, which is declared public? true and sensitive? false, so the values are returned by the version resource's default read action and printed in logs, inspect output, and error messages instead of being redacted. AshPaperTrail.Resource.Transformers.CreateVersionResource derives the changes map's sensitivity from the ignore_attributes list (the attributes excluded from changes) rather than from the tracked attributes actually stored in it, and ignore_attributes defaults to empty, so the flag is effectively always false. This issue affects ash_paper_trail: from 0.1.1 before 0.7.0.

Exploitation Scenario

An internal user, contractor, or attacker who has compromised a low-privilege account with read access to an Ash-backed application's admin panel or API queries the generated version resource for a tracked entity (e.g., a user profile or API-credential record). Because the changes map was never actually marked sensitive, the response returns the plaintext values of fields the developer explicitly flagged as sensitive?: true — such as API keys or PII — even though the live resource itself redacts them correctly. The attacker harvests these values directly from version history, or alternatively pulls them from centralized log aggregation where the same unredacted values were printed during normal application error handling, then uses the recovered credentials for account takeover or lateral movement.

Weaknesses (CWE)

CWE-312 Cleartext Storage of Sensitive Information

CWE-312 — Cleartext Storage of Sensitive Information: The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

[Implementation, System Configuration, Operation] When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
[Implementation, System Configuration, Operation] In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

Source: MITRE CWE corpus.