Browserify create-ecdh 4.0.5 Fixes Invalid Public-Key Validation
Tech GuruQuick Answer
Upgrade affected create-ecdh dependencies to 4.0.5 and rebuild deployed bundles. Confirm which implementation runs and whether untrusted peers can reach reused-key operations.
Confirm Scope And Apply The Supported Remediation
What to do now: Identify direct and transitive create-ecdh dependencies, browser bundles, runtime versions and application owners. Trace the deployed import and bundler resolution. Package presence alone does not establish use of the affected implementation. Use the project-fixed 4.0.5 package through the approved dependency process, rebuild consumers and deploy the resulting artifacts. Verify the deployed dependency and test valid key exchange and invalid-key rejection in a controlled test environment. Retain lockfiles, artifact hashes and test results.
Last verified: 2026-11-14 UTC. Recheck the authoritative advisory and supported distribution channel before changing production.
Scope And Authority
| Product scope | create-ecdh npm package, browser and fallback implementation |
|---|---|
| Advisory | GHSA-32q7-f779-hw5r |
| CVE | CVE-2026-129319 |
| Authoritative release date | 2026-11-14T06:48:29Z — project advisory publication timestamp. |
| Authority revision date | No separate revision is recorded; the project API publication and update timestamps are identical. |
| Affected versions | Versions 1.0.0 through 4.0.4 when browser.js is used by a browser bundle or the Node.js compatibility fallback. Modern Node.js native crypto.createECDH is not affected. |
| Fixed version | create-ecdh 4.0.5 |
| CVSS base score | 5.9 (CVSS v3.1) |
| CVSS severity | Medium |
| Exploitation status | The project advisory does not confirm exploitation in the wild.; no exploitation claim is inferred. |
What Changed
The project added public-key validation to computeSecret and setPublicKey. Invalid peer points could disclose information about a static or reused private key; some supported curve aliases also accepted unsafe subgroup inputs.
What To Validate Now
- Inventory. Identify direct and transitive create-ecdh dependencies, browser bundles, runtime versions and application owners.
- Establish applicability. Trace the deployed import and bundler resolution. Package presence alone does not establish use of the affected implementation.
- Remediate. Use the project-fixed 4.0.5 package through the approved dependency process, rebuild consumers and deploy the resulting artifacts.
- Validate. Verify the deployed dependency and test valid key exchange and invalid-key rejection in a controlled test environment. Retain lockfiles, artifact hashes and test results.
- Retain evidence. Preserve asset and owner identifiers, the applicability decision, before-and-after versions, change approval, installation output, validation results, and any exception or rollback record.
Operational Cautions
The update can reject inputs previously accepted, so test application error handling and interoperability. Review long-lived key exposure with the responsible cryptography owner; updating a dependency does not prove that an exposed key remained secret.
Evidence To Retain
- Exact product, release stream, package or application version, enabled feature, environment, and accountable owner.
- UTC timestamps, authority revision, approved change record, installer or package-manager output, and resulting version.
- Relevant logs and monitoring evidence, test results, exceptions, compensating controls, and rollback decisions.
Related TechGeeks Resources
Authoritative References
- Project security advisory GHSA-32q7-f779-hw5r
- Project advisory API: chronology, affected versions and CVSS
Correction policy: If the authority changes affected versions, fixed versions, severity, exploitation information, mitigations, or required action, TechGeeks will update this notice and its verification date.
