Description
Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource.

AshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) > 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way.

This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Published: 2026-09-17
Score: 6.9 Medium
EPSS: n/a
KEV: No
Impact: Data tampering via forged JWT revocation records
Action: Patch promptly
AI Analysis

Impact

An attacker can supply a forged JSON Web Token to the token revocation endpoint of AshAuthentication. Because the implementation uses a peek function that extracts claims without verifying the signature, the attacker‐controlled jti, exp, and sub values are deserialized and stored as a revocation record. The revocation record can be crafted so that it already expires or contains arbitrary identifiers, allowing the attacker to either prevent a legitimate revocation from being stored or to insert unauthorized rows into the token database. This weakness is identified as improper verification of the cryptographic signature (CWE‑347) and enables data‑tampering rather than code execution.

Affected Systems

Versioned AshAuthentication packages from team‑alembic are affected. The vulnerability exists in all releases starting with version 0.2.0 through just before 4.15.0, and also in the release candidates 5.0.0‑rc.0 through 5.0.0‑rc.13. Upgrading to any stable release 4.15.0 or later, or to any 5.0.0‑rc.14 or newer, removes the flaw. The product is exposed via the revocation API exposed by AshAuthentication.Services.TokenResource.

Risk and Exploitability

Based on the CVSS base score of 6.9, this issue is classified as medium severity. EPSS is not available, and the vulnerability is not listed in the CISA KEV catalog, suggesting that widespread exploitation may not yet be documented. The vulnerability is exploitable by anyone who can invoke the revocation action; no network elevation or additional privileges are mentioned. A likely attack vector is a compromised user session or a malicious client that can send crafted revocation requests to the server.

Generated by OpenCVE AI on September 17, 2026 at 22:16 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade AshAuthentication to a supported version that includes the signature‑verification fix (≥4.15.0 or ≥5.0.0‑rc.14).
  • Disable or restrict external access to the revocation endpoint until the update is applied, confining it to trusted internal calls only.
  • Validate that revocation requests now require a signed JWT by inspecting the server logs or using a penetration‑testing tool to confirm that signature verification is enforced before the revocation record is written.

Generated by OpenCVE AI on September 17, 2026 at 22:16 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 17 Sep 2026 19:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Thu, 17 Sep 2026 13:30:00 +0000

Type Values Removed Values Added
Description Improper Verification of Cryptographic Signature vulnerability in team-alembic AshAuthentication allows a caller of the token revocation action to neutralise a revocation or write arbitrary rows into the token resource. AshAuthentication.TokenResource.RevokeTokenChange.change/3 reads the :token argument and decodes it with AshAuthentication.Jwt.peek/1, which delegates to Joken.peek_claims/1 and performs no signature check, unlike Jwt.verify/4. The jti, exp and sub claims it returns are written straight onto the revocation record, guarded only by byte_size(token) > 0. Because expires_at derives from the attacker-chosen exp, a forged copy of a genuine token that keeps the real jti but backdates exp yields a revocation row that is already expired: expunge_expired removes it and the genuine token passes revoked? again. Arbitrary jti and sub values can be inserted the same way. This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Title Token revocation record built from unverified JWT claims in AshAuthentication
First Time appeared Team-alembic
Team-alembic ash Authentication
Weaknesses CWE-347
CPEs cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*
Vendors & Products Team-alembic
Team-alembic ash Authentication
References
Metrics cvssV4_0

{'score': 6.9, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N'}

Subscriptions

Team-alembic Ash Authentication
cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-09-17T18:28:20.821Z

Reserved: 2026-09-11T18:30:01.328Z

Link: CVE-2026-78223

cve-icon Vulnrichment

Updated: 2026-09-17T18:28:17.876Z

cve-icon NVD

Status : Received

Published: 2026-09-17T14:17:29.987

Modified: 2026-09-17T19:16:59.760

Link: CVE-2026-78223

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T00:30:16Z

Weaknesses
  • CWE-347

    Improper Verification of Cryptographic Signature