CVE-2024-42460

What it actually does

This vulnerability is an ECDSA signature malleability issue in Elliptic 6.5.6 as used by affected Envoy builds. Because signature parsing/validation does not enforce the required leading-bit canonical encoding checks for the ECDSA r and s values, an attacker can transform a valid signature into an alternate byte representation that still verifies as valid. The flaw does not directly expose private keys or allow arbitrary signature creation, but it can undermine systems that rely on the exact signature bytes as a unique identifier, cache key, replay-prevention token, audit artifact, or transaction hash. The CVSS profile indicates remote, unauthenticated, low-complexity exploitation with limited confidentiality impact and no direct integrity or availability impact.

Why it matters to the business

The primary business risk is trust and audit ambiguity in systems that depend on ECDSA signatures for identity, request authorization, signed tokens, message validation, or non-repudiation. Attackers may be able to bypass duplicate-detection, replay controls, signature-based allow/deny lists, or monitoring logic that assumes one valid message has only one valid signature representation. This is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS likelihood, and has no reported mature public exploit in the provided data, so remediation should be prioritized through normal patch management unless the affected component validates externally supplied ECDSA signatures in security-sensitive workflows.

How an attack unfolds

An attacker first needs access to a valid ECDSA-signed object that the affected software will verify, such as a signed token, signed request, certificate-related artifact, transaction, or protocol message. The attacker does not need the signing private key. They alter the serialized ECDSA signature by changing the encoding of the r and/or s integer values in a way that should be rejected by strict canonical validation but is accepted by the vulnerable implementation. The modified signature is then submitted to the affected verifier. If downstream application logic tracks, caches, logs, or de-duplicates the object by the raw signature bytes rather than by a canonical message identifier or verified claims, the altered signature may be treated as a distinct object even though it validates against the same signed content. Successful exploitation depends heavily on how the vulnerable library is used; the most relevant scenarios are systems where signature uniqueness has security or business meaning.

How to fix it

Upgrade affected Envoy source builds to a version containing commit 84d6d3ae2d687626e9fa0dd6560acc6107ac4c2c or a downstream release that includes that fix. Where Elliptic is used directly in Node.js applications, upgrade to a patched Elliptic release when available from the package maintainer and ensure dependency lockfiles are refreshed so vulnerable transitive copies are removed. Rebuild and redeploy services that statically bundle the vulnerable code. As defense in depth, require strict DER/canonical ECDSA signature validation, reject non-canonical r and s encodings, normalize signatures before comparison where appropriate, and avoid using raw signature bytes as the sole replay-prevention, uniqueness, authorization, or audit key. Use stable identifiers derived from the signed payload, verified claims, nonce values, timestamps, issuer/audience fields, or transaction IDs instead.

How to confirm the fix worked

Confirm that running builds include the fixed Envoy commit 84d6d3ae2d687626e9fa0dd6560acc6107ac4c2c or a vendor release that documents inclusion of the fix. For Node.js dependency trees, run dependency inventory commands such as npm ls elliptic, yarn why elliptic, or pnpm why elliptic and verify that no vulnerable Elliptic 6.5.6 instance remains in production artifacts. Review software composition analysis results, container image SBOMs, and build lockfiles for elliptic@6.5.6. Functional validation should include negative tests that submit ECDSA signatures with non-canonical r or s encodings and confirm they are rejected. Also test replay and duplicate-detection logic to verify it does not rely solely on raw signature byte equality.

Typical attack path

1. Identify an externally reachable workflow that accepts ECDSA-signed data and uses an affected Elliptic/Envoy code path for verification.
2. Obtain a legitimate ECDSA-signed message, token, request, or transaction that the target accepts.
3. Modify the DER/serialized ECDSA signature encoding for the r and/or s value to create a non-canonical but mathematically valid alternate signature representation.
4. Submit the altered signed object to the target service.
5. Rely on vulnerable verification accepting the malleated signature.
6. Abuse application logic that treats the altered signature as a new object, bypassing replay prevention, duplicate detection, audit correlation, or signature-byte-based policy decisions.

How to detect it

There is no universal network or host indicator for this issue because exploitation consists of submitting non-canonical but otherwise valid ECDSA signatures to an application-specific verification endpoint. To investigate possible prior exploitation, review application, API gateway, Envoy, authentication, token-verification, and transaction-processing logs for repeated signed payloads, token claims, request IDs, nonces, or transaction bodies that appear with different raw ECDSA signature values. Focus on workflows that log verification failures, replay rejections, duplicate submissions, JWT/JWS validation, signed webhook validation, blockchain-style transaction handling, or custom signed API requests. Look for bursts of near-identical requests where only the signature field changes, especially from the same source address, user agent, client certificate, account, or session. If raw signed objects are retained, perform offline parsing to identify signatures where r or s uses non-canonical integer encoding or where equivalent message content validates under multiple signature byte strings. On hosts, inspect dependency inventories and deployed artifacts for elliptic@6.5.6, but presence of the package is an exposure indicator rather than proof of compromise.

• elliptic@6.5.6
• node_modules/elliptic/package.json
• "elliptic": "6.5.6"
• "elliptic":"6.5.6"
• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• 84d6d3ae2d687626e9fa0dd6560acc6107ac4c2c
• ECDSA
• invalid signature
• signature verification failed
• replay detected
• duplicate signature
• duplicate transaction
• JWT signature verification failed
• JWS signature verification failed

What your security team should do

• Inventory all Envoy builds and Node.js applications that perform ECDSA signature verification or bundle the Elliptic package, including transitive dependencies.
• Prioritize patching systems that accept untrusted, externally supplied signed data or use ECDSA signatures in authentication, authorization, transaction processing, replay prevention, or audit workflows.
• Upgrade affected Envoy builds to include commit 84d6d3ae2d687626e9fa0dd6560acc6107ac4c2c or a vendor release containing that commit.
• Search dependency manifests, lockfiles, SBOMs, and container images for elliptic@6.5.6 and replace vulnerable bundled copies.
• Add regression tests using malformed or non-canonical ECDSA signatures to ensure future dependency updates do not reintroduce permissive verification behavior.
• Review application logic for use of raw signature bytes as identifiers, cache keys, deduplication keys, or policy inputs, and replace with canonical, payload-derived identifiers.
• Monitor authentication, token-verification, and signed-message workflows for repeated payloads or claims appearing with different signature byte strings.