CVE-2026-33895: 
JavaScript vulnerability analysis and mitigation

CVE-2026-33895 is a signature forgery vulnerability in the node-forge (digitalbazaar/forge) JavaScript cryptography library, caused by missing canonical scalar validation in Ed25519 signature verification. The flaw allows an unauthenticated remote attacker to forge non-canonical Ed25519 signatures that pass verification in forge but are correctly rejected by compliant implementations such as Node.js crypto.verify (OpenSSL-backed). All versions of node-forge up to and including 1.3.3 are affected; version 1.4.0 patches the issue. It was disclosed on March 24, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause (CWE-347: Improper Verification of Cryptographic Signature) lies in lib/ed25519.js within the crypto_sign_open() function, which passes the signature's last 32 bytes (scalar S) directly to scalar multiplication via scalarbase(q, sm.subarray(32)) without first checking that S < L (the Ed25519 group order). Because Ed25519 arithmetic is performed modulo L, a signature with S' = S + L is mathematically equivalent and will also pass verification, creating a class of non-canonical but accepted signatures. The fix adds a _isCanonicalSignatureScalar() function that performs a little-endian byte-by-byte comparison of S against L and rejects any signature where S >= L. A public proof-of-concept script (poc.js) was included in the advisory, demonstrating that forge accepts both the original and the S + L-mutated signature while Node.js/OpenSSL rejects the latter (GitHub Advisory, Forge Commit).

Successful exploitation allows an unauthenticated network attacker to forge valid-appearing Ed25519 signatures, directly undermining integrity guarantees. Applications that rely on signature uniqueness for replay protection, deduplication by signature bytes, or signed-object canonicalization checks can be bypassed, potentially enabling authentication and authorization bypass. This class of vulnerability has been exploited in practice in related CVEs (CVE-2022-35961, CVE-2026-25793), and affected IBM enterprise products include Maximo Application Suite, API Connect, App Connect Enterprise, watsonx BI Assistant, Data Product Hub, watsonx Code Assistant, and Sterling Connect:Direct Web Services (GitHub Advisory, IBM Maximo Advisory).

A public proof-of-concept script is included in the official security advisory and the patched commit, making exploitation straightforward for any attacker with knowledge of the target application's Ed25519 usage. No confirmed in-the-wild exploitation has been reported as of the time of this report, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.042% (13th percentile), indicating low near-term exploitation probability. No specific threat actor attribution has been made (GitHub Advisory, Red Hat Bugzilla).

1. Identify target: Locate an application using node-forge ≤ 1.3.3 that performs Ed25519 signature verification via ed25519.verify(...) for authentication, authorization, replay protection, or signed-object validation.
2. Obtain a valid signature: Acquire a legitimately signed message and its corresponding 64-byte Ed25519 signature (e.g., by authenticating normally or intercepting a signed token).
3. Mutate the scalar S: Extract bytes 32–63 of the 64-byte signature (the scalar S). Add the Ed25519 group order L (little-endian: 0xed, 0xd3, 0xf5, 0x5c, ...) to S using byte-by-byte addition with carry, producing S' = S + L (mod 2^256).
4. Construct forged signature: Replace bytes 32–63 of the original signature with the computed S', keeping the first 32 bytes (R) unchanged.
5. Submit forged signature: Present the forged 64-byte signature to the target application. Because forge does not check S < L, the forged signature passes ed25519.verify() and the application accepts it as valid.
6. Achieve objective: Depending on the application, this may result in authentication bypass, replay of a previously used signed token under a different byte representation, or circumvention of signature-based deduplication or canonicalization checks (GitHub Advisory, Forge Commit).

• Application Logs: Repeated or duplicate authentication/authorization events using signatures that differ only in the last 32 bytes (scalar S component); successful verifications that fail when cross-checked against an OpenSSL-backed verifier.
• Network: Submission of 64-byte Ed25519 signatures where bytes 32–63 are unusually large (high-order bytes near or exceeding the Ed25519 group order L = 0x1000...0014def9dea2f79cd65812631a5cf5d3ed in little-endian); duplicate signed requests with byte-differing but semantically equivalent signatures.
• File System / Code: Presence of the PoC script poc.js or ghsa-q67f-28xg-22rw.js on developer or CI systems; use of node-forge versions ≤ 1.3.3 in package.json or package-lock.json.
• Process Behavior: Node.js processes invoking ed25519.verify() from node-forge ≤ 1.3.3 in authentication-critical code paths (GitHub Advisory).

The primary remediation is to upgrade node-forge (npm package) to version 1.4.0 or later, which adds the _isCanonicalSignatureScalar() check enforcing S < L before scalar multiplication (Forge Commit, GitHub Advisory). As a workaround where immediate upgrade is not possible, applications should cross-validate Ed25519 signatures using Node.js's built-in crypto.verify() (OpenSSL-backed), which correctly rejects non-canonical signatures. IBM product users should apply patches per the relevant IBM security advisories for affected products (Maximo Application Suite, API Connect, App Connect Enterprise, watsonx BI Assistant, Data Product Hub, watsonx Code Assistant, Sterling Connect:Direct Web Services). Red Hat Ansible Automation Platform users should apply RHSA-2026:24761 (Red Hat Bugzilla, IBM Maximo Advisory).

The vulnerability was discovered and responsibly disclosed as part of a U.C. Berkeley security research project by Austin Chu, Sohee Kim, and Corban Villa, following a coordinated 90-day disclosure policy. IBM issued multiple security bulletins addressing the impact across its enterprise product portfolio. Red Hat addressed the issue in Ansible Automation Platform via RHSA-2026:24761. The vulnerability received coverage on security aggregation platforms including VulDB, cvefeed.io, and The Hacker Wire, as well as social media posts on Mastodon and Bluesky (GitHub Advisory, Red Hat Bugzilla).