CVE-2026-28498
Authlib ≤ 1.6.9
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-28498 is a high-severity Improper Validation of Integrity Check Value (CWE-354) vulnerability in Authlib Authlib. Its CVSS base score is 8.2 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Supply Chain Compromise (T1195); ranked at the 13th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SC-13 (Cryptographic Protection) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-28498 is a library-level vulnerability in Authlib, a Python library used for building OAuth and OpenID Connect servers. Affecting versions prior to 1.6.9, the issue resides in the internal _verify_hash function, which validates the at_hash (Access Token Hash) and c_hash (Authorization Code Hash) claims in OpenID Connect ID Tokens. When encountering an unsupported or unknown cryptographic algorithm specified in the alg header, the function exhibits fail-open behavior by silently returning True, allowing validation to pass despite the absence of proper integrity checks. This violates OIDC specifications and core cryptographic principles, as rated with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) and mapped to CWE-354 (Improper Validation of Integrity Check Value) and CWE-573 (Improper Following of Specification by Caller).
Remote attackers without privileges can exploit this vulnerability over the network with low complexity. By crafting a forged ID Token containing an unrecognized alg header parameter, an attacker bypasses the mandatory hash verification for access tokens or authorization codes. This enables the acceptance of tampered tokens, potentially leading to unauthorized access or further compromise within OAuth/OIDC flows dependent on Authlib's validation.
The vulnerability has been addressed in Authlib version 1.6.9, as detailed in the project's security advisory (GHSA-m344-f55w-2m6j), release notes, and the patching commit (b9bb2b25bf8b7e01512d847a95c1749646eaa72b). Security practitioners should upgrade to 1.6.9 or later and review deployments relying on Authlib for OIDC token handling.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-12482
Vulnerability Data
Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to version 1.6.9, a library-level vulnerability was identified in the Authlib Python library concerning the validation of OpenID Connect (OIDC) ID Tokens. Specifically, the internal hash verification…
more
logic (_verify_hash) responsible for validating the at_hash (Access Token Hash) and c_hash (Authorization Code Hash) claims exhibits a fail-open behavior when encountering an unsupported or unknown cryptographic algorithm. This flaw allows an attacker to bypass mandatory integrity protections by supplying a forged ID Token with a deliberately unrecognized alg header parameter. The library intercepts the unsupported state and silently returns True (validation passed), inherently violating fundamental cryptographic design principles and direct OIDC specifications. This issue has been patched in version 1.6.9.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 24 hardening rules · 6 OS baselines
V10.4.12
Mitigating Controls (NIST 800-53 r5) AI
Requires selection and implementation of specific approved cryptographic algorithms and methods, reducing the chance that an incomplete algorithm is used.
Requires integrity verification tools that detect unauthorized changes when checksum validation is missing or flawed.
Developer testing and evaluation can discover cases where callers fail to follow required specifications or APIs.
Requires protection of transmitted information integrity, directly mandating correct validation of integrity checks.
Requiring a documented development process and standards reduces the chance that callers will deviate from language, framework, or protocol specifications.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Requires cryptographic hashes and signatures that directly enforce integrity-check validation for data at rest.
Requires cryptographic hashes and signatures that directly enforce integrity-check validation for data in transit.
Secure SDLC practices directly enforce correct adherence to language, framework, protocol and platform specifications during implementation.
Mandates pre-acquisition integrity assessment, addressing only the initial portion of the weakness lifecycle.
Requires verification of backup integrity, covering validation only within recovery scenarios.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Cryptographic controls mandate integrity mechanisms whose correct validation directly prevents CWE-354.
Secure coding standards require proper implementation and validation of checksums or MACs.
Security testing can detect missing integrity validation but does not itself implement the control.
Secure development life cycle mandates adherence to language, framework and protocol specifications, directly reducing improper caller behavior.
Application security requirements include integrity checks on messages and data, mitigating improper validation.
Secure system architecture and engineering principles include specification adherence as a design constraint.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (4 rules)
- V-248574 YUM must be configured to prevent the installation of patches, service packs, device drivers, or OL 8 system components that have not been digitally signed using a certificate that is recognized and approved by the organization. prevents CWE-354
- V-248524 OL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-325
- V-248535 The OL 8 shadow password suite must be configured to use a sufficient number of hashing rounds. prevents CWE-325
Oracle Linux 9 (2 rules)
- V-271454 OL 9 must enable FIPS mode. prevents CWE-325
- V-271523 OL 9 must check the GPG signature of locally installed software packages before installation. prevents CWE-354
RHEL 7 (3 rules)
- V-204447 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-354
- V-204448 The Red Hat Enterprise Linux operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-354
- V-204497 The Red Hat Enterprise Linux operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-325
RHEL 8 (3 rules)
- V-230223 RHEL 8 must implement NIST FIPS-validated cryptography for the following: To provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-325
- V-230264 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-354
- V-230265 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-354
Ubuntu 22.04 (1 rule)
- V-260650 Ubuntu 22.04 LTS must implement NIST FIPS-validated cryptography to protect classified information and for the following: To provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-325
Ubuntu 24.04 (1 rule)
- V-270744 Ubuntu 24.04 LTS must implement NIST FIPS-validated cryptography to protect classified information and for the following: To provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. prevents CWE-325