CVE-2026-125335: 
Wolfi vulnerability analysis and mitigation

CVE-2026-125335 is an Ed25519 signature verification flaw in Forge (node-forge), a native JavaScript implementation of Transport Layer Security. The vulnerability allows an attacker who can supply an arbitrary public key to forge valid Ed25519 signatures for many or all messages without possessing a private key. All versions of node-forge up to and including 1.4.2 are affected; the issue was fixed in version 1.4.3. It carries a CVSS v3.1 base score of 3.7 (Low) (Github Advisory).

The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature). The crypto_sign_open() function in lib/ed25519.js decodes the supplied public key using unpackneg(), which only verifies that the point lies on the curve but does not reject small-order points (the identity point and the 7 other points of order 2, 4, or 8) or their non-canonical encodings where y >= p. The verification equation checks R == [S]B - [k]A with k = SHA-512(R || A || M); when S = 0, this reduces to R == [k](-A). For a small-order public key A, [k](-A) cycles through at most 8 small-order points, so an attacker can enumerate valid R values and produce a forged signature without any private key. The identity key (01 00 … 00) is the worst case: R = identity, S = 0 verifies for every possible message. The fix, introduced in commit 1b77e6f, adds an _isSmallOrder() check that computes [8]P and rejects the key if the result is the identity point (Github Advisory, Patch Commit).

The primary impact is an integrity violation: an attacker who can control the public key presented to ed25519.verify() can produce signatures that pass verification for arbitrary messages without knowledge of the corresponding private key. This defeats proof-of-possession checks, attribution, non-repudiation, and deduplication mechanisms that depend on a signature being cryptographically bound to a specific message and key pair. There is no confidentiality or availability impact. Applications that only verify signatures against internally generated or otherwise trusted public keys are not affected; the risk is limited to systems that accept attacker-supplied public keys alongside signed data (Github Advisory).

No public proof-of-concept exploit has been released independently, though a PoC script (tests/pocs/GHSA-6889-vf6x-f3g5.js) was included in the node-forge repository as part of the fix and demonstrates the attack using the identity key. There is no evidence of in-the-wild exploitation. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to control the public key used during verification, which is a non-trivial precondition that limits the practical attack surface (Github Advisory, Feedly).

1. Identify a vulnerable target: Find an application using node-forge <= 1.4.2 that accepts an attacker-supplied Ed25519 public key alongside signed data (e.g., a self-registration endpoint, a document with an embedded key, or a JWT-like scheme where the key is included in the payload).
2. Craft a small-order public key: Use the identity point as the public key: a 32-byte value 01 00 00 … 00 (y = 1, sign bit = 0). This is the simplest case and causes verification to succeed for every message.
3. Construct a forged signature: Set R = 01 00 … 00 (identity point) and S = 00 … 00 (32 zero bytes), producing a 64-byte signature. No private key is required.
4. Submit the forged data: Send the target application the chosen message (e.g., admin=true), the identity public key, and the forged signature. On node-forge <= 1.4.2, ed25519.verify() returns true for any message under this key.
5. Achieve the objective: The application accepts the forged signature as valid, bypassing proof-of-possession, authentication, or non-repudiation checks and granting the attacker the privileges or access associated with the signed claim (Github Advisory, Patch Commit).

• Network: Requests to signature-verification endpoints carrying a 32-byte Ed25519 public key equal to 0100000000000000000000000000000000000000000000000000000000000000 (hex) or other known small-order encodings (e.g., ecffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f for order-2).
• Application Logs: Successful signature verification events where the supplied public key matches a known small-order point; unexpected authorization grants or privilege escalations immediately following Ed25519 verification calls.
• File System / Code: Presence of node-forge npm package at version <= 1.4.2 in node_modules/node-forge/package.json or package-lock.json; absence of the _isSmallOrder function in node_modules/node-forge/lib/ed25519.js confirms a vulnerable version is in use.
• Behavioral: Repeated signature verification attempts with varying messages but the same zero-scalar signature (S = 00…00) and a fixed small-order public key, suggesting automated forgery attempts (Github Advisory).

Upgrade node-forge to version 1.4.3 or later, which rejects small-order public keys in ed25519.verify() by checking whether [8]P equals the identity point (Forge Release). As a temporary workaround for applications that cannot upgrade immediately, validate the 32-byte public key encoding against the known list of small-order points before passing it to ed25519.verify() — specifically the encodings blocked by libsodium — or restrict signature verification to keys that were generated internally or obtained from a trusted source (Github Advisory).

The vulnerability was reported by GitHub user @analisaperlengkapan and published by maintainer davidlehn as part of the node-forge 1.4.3 security release, which also addressed four other advisories of higher severity. Red Hat tracked the issue via Bugzilla (bug 2570954) and published a CVE advisory, indicating downstream awareness in enterprise Linux distributions (Red Hat CVE). No significant independent researcher commentary or broad media coverage has been identified beyond standard advisory aggregation.