CVE-2026-89317 in gose
Summary
by MITRE • 10/23/2026
gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it. RFC 7515 §4.1.11 requires a recipient to reject a JWS whose listed critical extension parameters it does not understand. gose implements no header extensions, so every token carrying a non-empty `crit` should have been rejected — and none were.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability in the gose library represents a significant deviation from the JSON Web Signature (JWS) specification defined in RFC 7515, specifically concerning the handling of critical header parameters. When parsing incoming JWS tokens, the library correctly extracts the crit header and stores it within the JwsHeader.Crit field. However, this data is subsequently ignored during the validation process. This oversight creates a scenario where the application fails to enforce mandatory security checks required by the standard for processing signed content with unknown extensions.
According to RFC 7515 section 4.1.11, any recipient that receives a JWS containing critical header parameters it does not understand must reject the token immediately. This requirement exists to prevent ambiguity and potential exploitation of undefined behaviors when new or custom headers are introduced into the protocol. By failing to inspect the crit list for unrecognized extensions, gose allows tokens with non-empty critical sections to pass validation as if they were standard JWS objects without any special processing requirements.
This flaw effectively nullifies the security guarantees provided by the critical header mechanism. An attacker can craft a malicious JWS that includes custom or experimental headers marked as critical in the crit list. Since gose does not validate these extensions, it will process and accept such tokens despite their non-compliance with strict interpretation rules. This behavior undermines trust in signed messages because applications relying on this library may execute logic based on data structures they do not fully understand or support, potentially leading to unexpected side effects or security bypasses depending on how the application interprets those unknown headers.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-756 Missing Explanation of Critical Functionality in Standards Compliance. The failure to reject non-compliant input constitutes an improper validation error that allows unauthorized or malformed data structures to proceed through the security pipeline. In terms of adversary tactics, this vulnerability could be leveraged within ATT&CK techniques related to Defense Evasion by exploiting protocol ambiguities to bypass expected processing logic or inject malicious payloads disguised as compliant signed content.
To mitigate this risk, developers using gose must ensure that any version containing this flaw is updated to a patched release where the crit header is properly validated against known extensions. If an immediate update is not feasible, applications should implement additional validation layers at the application level to manually check for non-empty critical headers and reject tokens accordingly until the library issue is resolved. This defensive coding practice ensures that even if underlying libraries fail to enforce standards compliance, the application itself maintains strict adherence to RFC 7515 requirements regarding unknown extensions.