Closed Bug 1782661 Opened 1 year ago Closed 1 year ago

Hang when a page has a localstorage entry with a hex value


(DevTools :: Storage Inspector, defect)

Firefox 103


(firefox-esr91 wontfix, firefox-esr102104+ wontfix, firefox103 wontfix, firefox104+ wontfix, firefox105+ verified, firefox106 verified)

105 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 104+ wontfix
firefox103 --- wontfix
firefox104 + wontfix
firefox105 + verified
firefox106 --- verified


(Reporter: xer0days, Assigned: jdescottes)


(Keywords: csectype-dos, hang, sec-low, Whiteboard: [adv-esr102.2-][adv-main105-])


(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

1- Browse any website you like
2- Open developer tools (F12) -> storage -> local storage
3- Change one of the entries to 0x41414141, otherwise add a new item and change its value to 0x414141

Actual results:

1- The Firefox browser will be dosed, increasing its memory and CPU usage
2- It tested on the latest version of the software, as well as on Windows 10,7, and MacOS Catalina 10.15.

Expected results:



Summary: Dos when a local storage entry with the value 0x41414141 → Dos when has a local storage entry with the value 0x41414141

The exact hex value doesn't seem to matter (adding a value of 0x1 also hangs) and the hang only happens when the devtools storage inspector is opened. So this seems like something to do with the devtools bits here. As an attacker cannot force a user to open the storage inspector, and because this is a hang rather than some kind of exploitable crash, this doesn't seem especially severe.

Component: Untriaged → Storage Inspector
Ever confirmed: true
Product: Firefox → DevTools
Summary: Dos when has a local storage entry with the value 0x41414141 → Hang when a page has a localstorage entry with a hex value
Whiteboard: [devtools-triage]

The issue occurs when you actually try to click on the item in the storage inspector. Merely opening the storage inspector will not trigger it.
It seems the problem is within the vendored JSON5 library used in parseItemValue.

This library is only used by the storage inspector so this should not impact any other DevTools panel. Will investigate to see if the issue was fixed upstream.

As far as security goes, this could be used to as an anti-debugging measure by a website (see But it requires clicking on the item so it's unlikely to be very efficient.

I confirm that updating to json5 2.2.1 fixes the issue

Related issue on the repository:
The fix was included in v2.1.3 while we are still on v.2.1.0. Compare view between v2.1.0 and v2.2.1 at

The list of changes seems relatively small, should be straightforward to update.

Assignee: nobody → jdescottes
Group: firefox-core-security → core-security-release
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch
Whiteboard: [devtools-triage]

The patch landed in nightly and beta is affected.
:jdescottes, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox104 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jdescottes)

Forgot to set this, but I don't think it's worth uplifting. This is not a recent regression, and I don't really think it qualifies as a security issue here.

Flags: needinfo?(jdescottes)
Whiteboard: [adv-esr102.2-]
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+

I've reproduced the issue in Release v104.0.1 and verified the fix in Beta v105.0b7 and Nightly v106.0a1 on Windows 10, Mac OS 11 and Ubuntu 22.

QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+
OS: Unspecified → All
Hardware: Unspecified → Desktop
Whiteboard: [adv-esr102.2-] → [adv-esr102.2-][adv-main105-]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.