CVE-2026-33894
Digitalbazaar Forge ≤ 1.4.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NSummary
CVE-2026-33894 is a high-severity Improper Input Validation (CWE-20) vulnerability in Digitalbazaar Forge. Its CVSS base score is 7.5 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Supply Chain Compromise (T1195); ranked at the 39th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
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-33894 affects Forge, also known as node-forge, a JavaScript implementation of Transport Layer Security (TLS). Prior to version 1.4.0, the library's RSASSA PKCS#1 v1.5 signature verification is vulnerable to forgery for keys with low public exponents (e=3). Attackers can craft invalid signatures that pass verification by inserting "garbage" bytes within the ASN structure, enabling Bleichenbacher-style attacks. This flaw differs from the similar CVE-2022-24771 by placing bytes in an additional field inside the ASN structure rather than outside it. Additionally, Forge fails to enforce the specification's requirement for at least 8 bytes of padding in signatures, giving attackers more room to construct forgeries. The vulnerability is rated 7.5 on the CVSS 3.1 scale (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) and maps to CWE-20 (Improper Input Validation) and CWE-347 (Improper Verification of Cryptographic Signature).
Remote attackers require no privileges or user interaction to exploit this over the network with low complexity. Successful exploitation allows forging signatures that the library accepts as valid, potentially enabling attackers to impersonate legitimate signers, bypass authentication mechanisms, or tamper with signed data in applications relying on Forge for TLS or cryptographic operations.
The GitHub security advisory (GHSA-ppp5-5v6c-4jwp) confirms that version 1.4.0 fully patches the issue by addressing the ASN structure handling and padding validation deficiencies. Security practitioners should upgrade affected Forge installations to 1.4.0 or later and audit dependencies in JavaScript applications using this library for signature verification.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-16834
Vulnerability Data
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Prior to version 1.4.0, RSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes…
more
within the ASN structure in order to construct a signature that passes verification, enabling Bleichenbacher style forgery. This issue is similar to CVE-2022-24771, but adds bytes in an addition field within the ASN structure, rather than outside of it. Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as defined by the specification, providing attackers additional space to construct Bleichenbacher forgeries. Version 1.4.0 patches the issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 20 hardening rules · 5 OS baselines
—
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover missing input validation through analysis or test cases.
Requiring cryptographic protection mechanisms forces correct signature verification to be implemented for data protection.
SI-10 directly requires validity checks on information inputs, structurally preventing improper or missing validation.
Mandating integrity verification tools directly requires proper cryptographic signature checking to detect unauthorized changes.
Requiring documented development standards and tools can embed input-validation practices into the engineering process.
Protecting session authenticity requires correct verification of cryptographic signatures or equivalent mechanisms.
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.
Digital signatures are explicitly cited to protect integrity of data-at-rest, so proper verification directly mitigates the weakness.
Digital signatures are explicitly cited to protect integrity of data-in-transit, so proper verification directly mitigates the weakness.
Secure SDLC practices directly require and enforce input validation during development.
Requires assessing authenticity and integrity of acquired assets, which commonly relies on signature verification but is limited to pre-acquisition.
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.
Testing against a defined set of requirements and using code review plus vulnerability scanning forces validation of inputs and handling of unanticipated conditions, reducing the chance that malformed data will be accepted.
Establishing approved cryptographic solutions and usage practices lowers the probability that signature-verification steps will be omitted or incorrectly implemented.
Secure-coding guidelines and mandatory security testing (including code scans) compel developers to validate and sanitize inputs at design and implementation time, lowering the incidence of malformed or malicious data reaching downstream components.
Mandating input controls that include integrity checks and input validation ensures that untrusted data is examined before use, blocking the root cause of many injection and malformed-data weaknesses.
Security-by-design principles explicitly call for data validation and sanitization at every layer, reducing the chance that malformed or malicious input will be processed without scrutiny.
Requiring language-specific secure coding standards, peer review, SAST and documented mitigation of common programming errors forces validation of all inputs before they are trusted.
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 (2 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-347
- V-248575 OL 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-347
Oracle Linux 9 (2 rules)
- V-271525 OL 9 must have GPG signature verification enabled for all software repositories. prevents CWE-347
- V-271523 OL 9 must check the GPG signature of locally installed software packages before installation. prevents CWE-347
RHEL 7 (2 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-347
- 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-347
RHEL 8 (2 rules)
- 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-347
- 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-20
RHEL 9 (1 rule)
- V-257822 RHEL 9 must have GPG signature verification enabled for all software repositories. prevents CWE-347