CVE-2026-46625

What it actually does

The flaw is a prototype-hijacking issue in the js-cookie JavaScript library before version 3.0.7. Its internal object merge helper copies enumerable properties using for...in and plain assignment. If attacker-controlled JSON containing an own enumerable "__proto__" property is merged into cookie attributes, assignment to that key changes the prototype of the newly created attributes object. Object.prototype is not globally polluted, but the specific merged cookie-attribute object inherits attacker-controlled properties. When js-cookie later serializes that object into a Set-Cookie string using another for...in loop, inherited attacker-controlled keys are emitted as cookie attributes. This can allow an attacker to alter cookie security properties such as Domain, Path, Secure, SameSite, and Expires when an application passes untrusted or semi-trusted input into js-cookie cookie attribute handling.

Why it matters to the business

Applications using vulnerable js-cookie versions may allow attackers to weaken browser cookie protections that developers expected to enforce. Depending on how the application uses cookies, this can enable session fixation, broader cookie scope across subdomains, loss of SameSite protections, removal or alteration of Secure behavior, premature expiration, or persistence changes. The likely impact is integrity compromise of client-side cookie behavior rather than direct server compromise. The EPSS score is currently low and there is no known KEV listing or reported exploit maturity, but the library is common in web front ends and should be upgraded during normal dependency remediation because cookie misconfiguration can undermine authentication and cross-site request protections.

How an attack unfolds

An attacker needs a path for attacker-controlled data to be parsed with JSON.parse and then supplied, directly or indirectly, as cookie attributes to js-cookie's set() workflow. The attacker provides JSON containing a "__proto__" object with desired cookie attribute names and values, such as domain, path, sameSite, secure, or expires. In vulnerable versions, js-cookie's internal assign() helper creates a fresh target object and copies the parsed JSON properties into it. The "__proto__" assignment invokes the prototype setter on that fresh object, causing the merged attributes object to inherit attacker-controlled keys. js-cookie then serializes the attributes object with for...in, which includes inherited enumerable properties, and those inherited attacker-controlled keys are written into the resulting cookie string. The browser then applies the altered cookie attributes, potentially changing where the cookie is sent, how long it persists, or whether cross-site requests include it.

How to fix it

Upgrade js-cookie to version 3.0.7 or later. If using npm or yarn, update the direct dependency and regenerate the lockfile so transitive references resolve to a fixed version where applicable. If the library is bundled into static frontend assets, rebuild and redeploy those assets after upgrading; simply updating package metadata is not sufficient. As a defense-in-depth measure, do not pass untrusted JSON directly into cookie attribute objects, reject dangerous keys such as "__proto__", "prototype", and "constructor", and prefer allowlisted cookie attributes with explicit normalization. Security-sensitive cookies should have server-side enforcement where possible, including explicit Secure, HttpOnly, SameSite, Path, Domain, and expiration settings.

How to confirm the fix worked

Confirm that all deployed frontend bundles and dependency manifests use js-cookie version 3.0.7 or later. Check package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, software composition analysis output, and built JavaScript bundles for vulnerable js-cookie versions. In a test environment, attempt to pass an attributes object derived from JSON such as {"__proto__":{"domain":"example.com","path":"/","sameSite":"None"}} into js-cookie cookie-setting code and verify that inherited prototype keys are not serialized into the resulting cookie attributes. Also verify that production cookie behavior still matches the intended security policy, especially Secure, SameSite, Domain, Path, and expiration settings.

Typical attack path

1. Identify a web application using js-cookie before version 3.0.7.
2. Find a feature where user-controlled JSON or configuration data is parsed and used to build cookie attributes.
3. Submit JSON containing an enumerable "__proto__" object with attacker-selected cookie attributes such as domain, path, sameSite, secure, or expires.
4. Trigger application code that calls js-cookie's cookie-setting logic with the polluted attributes object.
5. Cause the browser to receive or create a cookie with attacker-influenced attributes.
6. Leverage the weakened or altered cookie scope and protections for session fixation, cross-subdomain cookie influence, or reduced cross-site request safeguards.

How to detect it

Because this is a client-side library flaw, exploitation evidence is usually found in web application logs, API gateway logs, WAF logs, browser telemetry, client error reporting, and any server logs that capture request bodies, query strings, postMessage relays, or JSON configuration submissions. Look for inbound JSON containing "__proto__" together with cookie-related attributes such as domain, path, secure, samesite, sameSite, expires, or max-age. Review affected application code paths where parsed JSON or user-controlled objects can influence js-cookie cookie attributes. In browser or RUM telemetry, look for unexpected cookie attribute changes, cookies scoped to broader domains than intended, altered SameSite values, unexpected long-lived or prematurely expired cookies, and session anomalies following suspicious requests. Since there are no public threat actors or KEV exploitation reports for this issue, detection should focus on prototype-pollution payload patterns and unexplained cookie scope or attribute changes rather than named-campaign indicators.

• "__proto__"
• '__proto__'
• %22__proto__%22
• \u005f\u005fproto\u005f\u005f
• "__proto__":{"domain"
• "__proto__":{"path"
• "__proto__":{"secure"
• "__proto__":{"samesite"
• "__proto__":{"sameSite"
• "__proto__":{"expires"
• "__proto__":{"max-age"
• "__proto__":{"maxAge"
• js-cookie@3.0.6
• node_modules/js-cookie/

What your security team should do

• Inventory applications and frontend bundles that include js-cookie and prioritize any version before 3.0.7 for upgrade.
• Upgrade js-cookie to 3.0.7 or later, rebuild frontend assets, redeploy, and purge CDN or browser-cacheable static assets where appropriate.
• Search source code for cases where JSON.parse output, URL parameters, postMessage data, localStorage data, or other user-controlled objects are passed into cookie attribute handling.
• Add input validation or allowlisting for cookie attribute objects and reject keys such as "__proto__", "prototype", and "constructor".
• Review security-sensitive cookie configuration to ensure important cookies are set server-side with appropriate Secure, HttpOnly, SameSite, Path, Domain, and expiration controls.
• Monitor web telemetry for attempts to submit JSON prototype-pollution payloads, especially payloads combining "__proto__" with cookie attribute names.
• Treat exploitation as more likely to affect application integrity and session behavior than infrastructure availability; prioritize internet-facing authentication, account, checkout, and admin workflows first.