CVE-2026-46625: js-cookie Prototype Pollution Allows Cookie Attribute Hijacking

Technical summary

The vulnerability stems from js-cookie's assign() helper function, which uses for…in loops combined with direct property assignment to merge objects. When processing a JSON.parse() output containing a __proto__ key as an own enumerable property, the assignment target[key] = source[key] triggers the Object.prototype.__proto__ setter. This pollutes the target object's prototype chain without modifying Object.prototype itself. The polluted prototype is then enumerated again during cookie serialization, injecting attacker-controlled attributes into the Set-Cookie header. The attack succeeds because modern JavaScript allows __proto__ as a regular property key in JSON, and the library does not defensively filter or use Object.create(null) to prevent prototype chain pollution.

Business impact

Applications relying on js-cookie to enforce strict cookie policies face degraded security posture. An attacker could bypass intended domain restrictions, remove the Secure flag to enable unencrypted transmission over HTTP, weaken SameSite protections against CSRF, or extend cookie lifetime. In authentication-heavy applications, this directly undermines session management and could facilitate account takeover or privilege escalation. Third-party integrations and single-page applications that delegate cookie handling to js-cookie are particularly at risk if the library version is not current.

Affected systems

Any application using js-cookie versions prior to 3.0.7 is potentially affected. This includes client-side JavaScript applications, browser extensions, Electron applications, and server-side Node.js applications that handle cookies via this library. The vulnerability is triggered only when the set() method receives a JSON-parsed object as input, making applications that directly parse untrusted JSON and pass it to js-cookie most vulnerable. Server-side usage is less common but possible in Node.js environments.

Exploitability

Exploitability is high. The attack requires only network access and the ability to influence input passed to js-cookie's set() method—no user interaction, authentication, or complex setup needed. If the application accepts JSON from an untrusted source (user input, third-party API, message queue) and forwards it to js-cookie, exploitation is straightforward. Proof-of-concept is trivial: JSON.parse('{"__proto__":{"domain":".attacker.com"}}') followed by a call to set(). This is not yet tracked in CISA's Known Exploited Vulnerabilities list, but the low barrier to exploitation makes defensive patching urgent.

Remediation

Upgrade js-cookie to version 3.0.7 or later immediately. Verify the update in package.json or lock file and test cookie behavior in staging before production rollout. For applications unable to upgrade immediately, implement input validation: sanitize or reject JSON objects containing __proto__ keys before passing to js-cookie, or use a library fork that defensively filters such keys. As a temporary mitigation, avoid calling js-cookie's set() with untrusted JSON; instead, construct cookie option objects explicitly in application code.

Patch guidance

Version 3.0.7 contains the fix and should be deployed as a priority patch. If using npm, run npm install js-cookie@latest or npm update js-cookie, then verify the installed version with npm list js-cookie. For yarn users, run yarn upgrade js-cookie. Regenerate package-lock.json or yarn.lock and commit to version control. In production, test cookie behavior (domain, secure flag, samesite) immediately after patching to ensure no application logic depends on the buggy behavior. If using a monorepo or private registry, coordinate updates across all dependent services.

Detection guidance

Monitor for unusual Set-Cookie headers that contain unexpected attribute values (domain, secure=false, samesite=none) injected after js-cookie calls. In browser DevTools or proxy logs, examine Set-Cookie responses for suspicious domain= values pointing to attacker-controlled domains. On the server side, log and alert on Set-Cookie headers where attributes deviate from configured defaults. Correlate timing: if Set-Cookie attributes change immediately after a POST/API request containing JSON payloads, investigate whether json-cookie's set() is being called unsafely. WAF rules can detect patterns like {"__proto__": in request bodies when followed by anomalous Set-Cookie responses.

Why prioritize this

This vulnerability merits immediate patching due to the combination of high CVSS score (7.5), direct impact on authentication and session security, trivial exploitability, and broad applicability to web and Node.js applications. Prototype pollution is a well-understood attack class with ample tooling and researcher familiarity. The fix is low-risk and backward-compatible. Organizations should treat this as a P1 security patch, especially for customer-facing authentication flows.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects network-accessible exploitation with no user interaction required and high integrity impact on cookie attributes. The score does not award severity for confidentiality or availability impact because the vulnerability is confined to cookie attribute injection, not data exfiltration or denial of service. However, in real-world deployments, the integrity impact (hijacking session scope, weakening protections) often cascades into authentication bypass and unauthorized access, warranting urgent remediation despite the base score not being Critical.

Frequently asked questions