VYPR
Unrated severityNVD Advisory· Published Jun 2, 2023· Updated Jan 10, 2025

CVE-2023-29547

CVE-2023-29547

Description

When a secure cookie existed in the Firefox cookie jar an insecure cookie for the same domain could have been created, when it should have silently failed. This could have led to a desynchronization in expected results when reading from the secure cookie. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

In Firefox, setting an insecure cookie with the same name as an existing secure cookie succeeds in document.cookie but not the cookie jar, causing desynchronization.

Vulnerability

In Firefox, when a secure cookie exists in the cookie jar for a given domain, the document.cookie setter incorrectly allows an insecure cookie with the same name to be created from an insecure origin. This violates the expected behavior where the setter should silently fail to prevent overriding a secure cookie with an insecure one. The bug affects Firefox versions prior to 112, Firefox for Android prior to 112, and Focus for Android prior to 112 [1][2].

Exploitation

An attacker who can execute JavaScript on an insecure origin (e.g., an HTTP page) can exploit this by first ensuring a secure cookie exists for the target domain (e.g., by having the user visit an HTTPS page that sets it), then setting an insecure cookie with the same name via document.cookie. The insecure cookie appears in document.cookie but is not actually stored in the browser's cookie jar. No additional user interaction beyond normal browsing is required [1].

Impact

This desynchronization between document.cookie and the actual cookie jar can mislead applications that rely on document.cookie to read cookie values. An attacker can spoof the value of a secure cookie, potentially leading to session hijacking or other attacks that depend on cookie integrity. The impact is limited to same-site and network attackers who can serve content over HTTP [1].

Mitigation

The vulnerability is fixed in Firefox 112, Firefox for Android 112, and Focus for Android 112, released on April 11, 2023 [2]. Users should update to these versions or later. No workarounds are available for unpatched versions.

AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

8

Patches

0

No patches discovered yet.

Vulnerability mechanics

Root cause

"Missing validation in the document.cookie setter allows an insecure cookie to be written to the JavaScript cookie property when a Secure cookie with the same name already exists."

Attack vector

An attacker who can cause the victim to visit an insecure (HTTP) page for a domain that already has a Secure cookie set can exploit this desynchronization [ref_id=1]. The attacker sets a cookie with the same name as the existing Secure cookie via `document.cookie` on the insecure origin. Although the insecure cookie is not stored in the browser's cookie jar, it appears in `document.cookie` on subsequent loads of the insecure page, creating a mismatch between what JavaScript reads and what is actually sent in requests [ref_id=1]. This allows a same-site or network attacker to spoof the value of a Secure cookie when the application reads from `document.cookie` [ref_id=1].

Affected code

The bug resides in Firefox's cookie handling logic, specifically in the `document.cookie` setter within the networking/cookies component [ref_id=1]. When an insecure origin attempts to set a cookie via `document.cookie`, the code fails to check whether a Secure cookie with the same name already exists in the cookie jar, allowing the insecure cookie to be written into the `document.cookie` property even though it is not persisted to the actual cookie jar [ref_id=1].

What the fix does

The advisory does not include a patch diff, but the expected fix is to make the `document.cookie` setter on insecure origins silently fail when a Secure cookie with the same name already exists, matching Chromium's behavior [ref_id=1]. Mozilla's bug tracker confirms the issue was resolved, and the fix was included in Firefox 112, Firefox for Android 112, and Focus for Android 112 [ref_id=1]. The remediation ensures that `document.cookie` on an insecure origin cannot be populated with a cookie name that conflicts with an existing Secure cookie, eliminating the desynchronization.

Preconditions

  • inputThe target domain must have a Secure cookie already set in the browser's cookie jar.
  • networkThe attacker must be able to execute JavaScript on an insecure (HTTP) page for the same domain, or be a network attacker able to inject such content.

Reproduction

Visit `https://example.com` and set a Secure cookie via the console: `document.cookie = "test=secure; Secure"`. In the same tab, navigate to `http://example.com` and set an insecure cookie with the same name: `document.cookie = "test=insecure"`. Refresh the insecure page and observe that `document.cookie` shows `test=insecure` even though the cookie jar does not contain it and the cookie is not sent in requests [ref_id=1].

Generated on May 26, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

2

News mentions

0

No linked articles in our index yet.