Skip to main content

erlang-jose EUVDEUVD-2026-110303

| CVE-2026-65625 MEDIUM
Improper Validation of Integrity Check Value (CWE-354)
2026-10-26 EEF
5.9
CVSS 4.0 · Vendor: EEF
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Submit crafted JWE token to decrypt endpoint
  2. Delivery
    Service routes GCM through pure-Erlang fallback
  3. Exploit
    Truncate authentication tag to 8 bits
  4. Execution
    Brute-force 256 single-byte tag values
  5. Impact
    Forged ciphertext accepted, integrity bypassed

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Integrity verification
Exploitation Conditions

Requires a deployment where Erlang/OTP does not expose a native AES-GCM crypto NIF, so JOSE routes GCM through the jose_jwa_aes pure-Erlang fallback - explicitly FIPS builds, or stripped/older OTP builds; on standard OTP where :crypto provides AES-GCM the fallback is not reached and the flaw is not triggered. The victim service must decrypt attacker-influenced JWE tokens using AES-GCM content encryption (A128/192/256GCM) or AEAD key wrapping (A*GCMKW) via the public JOSE.JWE.block_decrypt / block_decrypt/4 path. No authentication is required (PR:N) and no user interaction. The principal limiting factor is the non-default fallback condition: the forgery (and the over-length-tag process crash) only occurs when native GCM is absent; affected versions are jose 1.2.0 up to but excluding 1.11.13.

Impact

Signals point to a genuine but conditional integrity flaw rather than a mass-exploitation emergency. The CVSS 4.0 base score is 5.9 (medium) with VI:H (authentication-tag forgery / integrity bypass) but VC:N and only VA:L, and critically AT:P - exploitation requires the pure-Erlang AES-GCM fallback to be active, which only happens when Erlang/OTP exposes no native AES-GCM NIF (FIPS, stripped, or older OTP builds). EPSS is very low at 0.11% (2nd percentile) and the CVE is NOT on CISA KEV, so there is no evidence of active or widespread exploitation; a low EPSS combined with a published, self-verifying PoC is consistent with a credible-but-not-yet-exploited library bug. The vuln.today decision label is 'this_month', i.e. a patch-promptly item, not act_now/emergency. Note a discrepancy in attack vector: the authoritative vector is AV:L, yet the advisory threat model is an unauthenticated outside attacker submitting JWE compact tokens to a decrypt endpoint, which reads as network-reachable (AV:N) in most real deployments - verify how tokens reach the service before downgrading reachability. Net: real priority only for Erlang/Elixir deployments that both decrypt attacker-influenced JWE and run without native AES-GCM; elsewhere the vulnerable fallback path is not reached and real risk is low.

Exploit ScenarioDerived

An unauthenticated attacker submits a crafted JWE compact token (dir/A256GCM) to a victim service that decrypts attacker-supplied tokens via the public JOSE.JWE.block_decrypt path, on a host where GCM falls back to jose_jwa_aes (no native crypto NIF). The attacker truncates the GCM authentication tag to a single byte and brute-forces the 256 possible values; because only 8 bits of the real 128-bit tag are ever compared, exactly one forged ciphertext is accepted as authentic within 256 attempts without knowledge of the key. A complete, self-verifying proof-of-concept exploit script is published in the vendor's GHSA advisory.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 28, 2026

Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attacker defeat AES-GCM integrity wherever decryption routes through the pure-Erlang jose_jwa_aes fallback - FIPS builds, or stripped or older OTP releases where :crypto does not expose a native AES-GCM NIF. Because verification compares only as many bits of the real 128-bit tag as the attacker-supplied tag contains, truncating the tag to a single byte drops forgery resistance to 2^-8, so a forged JWE with attacker-chosen ciphertext is accepted within 256 attempts without knowledge of the key; an over-length tag instead triggers a badmatch that crashes the decrypting process. A public PoC reference exists (advisory-attached Elixir script); it is not verified as working exploit code, there is no confirmed active exploitation (not in CISA KEV), and EPSS is 0.11% (2nd percentile), consistent with the conditional fallback prerequisite.

RemediationAI

Upgrade to jose 1.11.13, the version named in the vendor advisory and package metadata as the fix; the patch commit is https://github.com/potatosalad/erlang-jose/commit/3fa1f8e3efda0da5ce6f4c9984789f979dc02740 and the advisory is https://github.com/potatosalad/erlang-jose/security/advisories/GHSA-6gxw-6f7r-cjr6. The release rejects any AEAD authentication tag that is not exactly 128 bits before dispatching to a crypto provider, covering A128GCM/A192GCM/A256GCM, C20P/XC20P and the A128GCMKW/A192GCMKW/A256GCMKW, C20PKW/XC20PKW wrapping algorithms, and the same check closes the over-length-tag crash. If upgrading is not possible, the vendor's workaround is to validate tag length in the application before decrypting: base64url-decode the authentication tag - the fifth segment of a compact JWE, or the tag value from jose_jwe:expand/1 / JOSE.JWE.expand/1 - and reject any token whose tag is not exactly 16 bytes, applying the same check to the tag header parameter for the AEAD key-wrapping algorithms; this depends on every decrypt path in the service being wrapped, so a missed entry point leaves the forgery and the crash reachable. Moving the deployment onto an OTP/crypto build that provides native AES-GCM also avoids the fallback, but the vendor treats updating as the complete fix. Note the fix also affects ChaCha20-Poly1305 tag handling, so regression testing of C20P/XC20P tokens is advisable.

Affected VersionsENISA

jose 1.2.0 <1.11.13
jose 8848b172575fb7d7e1e2977e8ae0a21678d2157a <3fa1f8e3efda0da5ce6f4c9984789f979dc02740

Affected Packages

euvd jose fix: 1.11.13

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The flaw is CWE-354 (Improper Validation of Integrity Check Value) in the pure-Erlang AES-GCM implementation of jose_jwa_aes, the fallback provider selected when the Erlang/OTP crypto NIF does not offer native AES-GCM - cipher dispatch is table-driven via the jose_jwa ETS entry for {:cipher, {:aes_gcm, Bits}}, so on FIPS, stripped or older OTP builds verification silently runs in Erlang rather than in :crypto. In the {aes_gcm, Bits} clause of block_decrypt/4 the incoming CipherTag is guarded only by is_binary/1, with no length constraint; gcm_block_decrypt/6 then sets TBits = bit_size(T) and compares the computed tag <<TPrime:TBits/bitstring, _/bitstring>> only over those bits, so the number of authenticated bits is chosen by whoever supplies the token instead of being fixed at 128. constant_time_compare/2 is used correctly, so this is not a timing side channel - the sole defect is the absent lower bound on tag length, which falls below the minimum tag length NIST SP 800-38D permits. The same missing check produces a secondary badmatch crash when a tag longer than 128 bits is supplied, since the bitstring binding cannot match. The fix rejects any authentication tag that is not exactly 128 bits before dispatching to a crypto provider, covering content encryption A128GCM/A192GCM/A256GCM and the ChaCha20-Poly1305 variants C20P/XC20P as well as AEAD key wrapping A128GCMKW/A192GCMKW/A256GCMKW and C20PKW/XC20PKW. The vendor's CVSS 4.0 vector scores 5.9 (AV:L/AC:L/AT:P/PR:N/UI:N/VI:H/VA:L); our independent assessment rates it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L, treating network reachability of the decrypt path as realistic but the non-default fallback condition as the principal limiting factor.

Know when Erlang gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (EEF) PRIMARY 5.9 MEDIUM
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
vuln.today AI 6.5 MEDIUM

Unauthenticated remote JWE submission (AV:N/PR:N/UI:N); AC:H reflects the required non-default pure-Erlang fallback deployment; I:H forgery, A:L over-length-tag crash, C:N as no plaintext/key is disclosed.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector
Local
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

The pure-Erlang AES-GCM fallback in jose_jwa_aes derives the number of verified authentication tag bits from the attacker-supplied tag itself. In the {aes_gcm, Bits} clause of block_decrypt/4, the incoming tag is guarded only by is_binary/1, with no check on its length. Verification in gcm_block_decrypt/6 then computes TBits = bit_size(T) and compares only those bits of the real 128-bit tag. An attacker who controls a JWE token can truncate the authentication tag to as little as 8 bits, so only 8 bits are ever checked. This reduces forgery resistance from 2^-128 to 2^-8, and a forged ciphertext is reliably accepted as authentic within 256 attempts without knowledge of the key (an authentication tag forgery and integrity bypass). Supplying a tag longer than 128 bits instead causes a badmatch that crashes the decrypting process. The fallback is reached through the public JWE decryption path whenever AES-GCM is not provided by a native crypto NIF, for example on FIPS or stripped or older OTP builds.

This issue affects jose: from 1.2.0 before 1.11.13.

Threat Intelligence Overview

EPSS Score
0.1%
Top 98% exploitable
Prevalence
Medium
de facto JOSE/JWT library for Erlang/Elixir, a limited ecosystem
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

30
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +30
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

More in Erlang

View all
CVE-2025-32433 CRITICAL POC
10.0 Apr 16

Erlang/OTP SSH server allows unauthenticated remote code execution by exploiting a flaw in SSH protocol message handling

CVE-2017-1000385 MEDIUM POC
5.9 Dec 12

The Erlang otp TLS server answers with different TLS alerts to different error types in the RSA PKCS #1 1.5 padding. Rat

CVE-2023-48795 MEDIUM POC
5.9 Dec 18

The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remot

CVE-2020-13802 CRITICAL POC
9.8 Sep 02

Rebar3 versions 3.0.0-beta.3 to 3.13.2 are vulnerable to OS command injection via URL parameter of dependency specificat

CVE-2014-1693 HIGH POC
7.5 Dec 08

Multiple CRLF injection vulnerabilities in the FTP module in Erlang/OTP R15B03 allow context-dependent attackers to inje

CVE-2021-29221 HIGH POC
7.0 Apr 09

A local privilege escalation vulnerability was discovered in Erlang/OTP prior to version 23.2.3. Rated high severity (CV

CVE-2016-10253 CRITICAL
9.8 Mar 18

An issue was discovered in Erlang/OTP 18.x. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitab

CVE-2022-37026 CRITICAL
9.8 Sep 21

In Erlang/OTP before 23.3.4.15, 24.x before 24.3.4.2, and 25.x before 25.0.2, there is a Client Authentication Bypass in

CVE-2026-89422 CRITICAL
9.3 Sep 22

Erlang/OTP's ssl application in affected releases (OTP 22.2 through the fixed 27.3.4.18, 28.5.0.7 and 29.1.1) will compl

CVE-2026-67404 CRITICAL
9.2 Sep 23

RabbitMQ brokers that use the OAuth2 plugin can silently fall back to disabled TLS certificate verification when no CA b

CVE-2026-67231 CRITICAL
9.1 Sep 23

TLS client-authentication bypass in the RabbitMQ trust-store plugin lets a remote unauthenticated attacker whose forged

CVE-2026-55953 CRITICAL
9.1 Jul 27

An on-path attacker can force an Erlang/OTP TLS 1.2 or DTLS client to accept an anonymous cipher suite not offered by th

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy