Firefox and Firefox ESR Release History: Cadence, ESR and Security

Firefox grew out of Phoenix, a community browser first released in 2002, and shipped as Firefox 1.0 in 2004. Mozilla moved it to a rapid release train with Firefox 5 in June 2011, to roughly four week releases in 2020, and its own release calendar shows two week releases from Firefox 155 (1 September 2026). Firefox ESR (Extended Support Release) branches off a regular release about once a year, receives security fixes on the same days as Release, and overlaps the next ESR line by several releases so organisations can test and move. As of 25 October 2026 the current release is Firefox 158, the current ESR is 153.5.1, and ESR 115 still receives fixes only on Windows 7 to 8.1 and macOS 10.12 to 10.14 until March 2027.

It is a companion to our Chrome and Chromium release history. This post covers every era, the security features Mozilla's release notes credit to each, the ESR cycle, how fixes ship, and how to manage a fleet without pinning it into an unsupported state.

Key takeaways

• Mozilla's history page says the first version of Phoenix (later renamed Firefox) was released in 2002 and Firefox 1.0 followed in 2004. Firefox 4.0 shipped on 22 March 2011 and Firefox 5.0, the first release on the rapid release train, on 21 June 2011.
• The release calendar at whattrainisitnow.com shows roughly six to eight week gaps from 2011, four week gaps from early 2020, and two week gaps from Firefox 155 (1 September 2026) onward.
• The original ESR proposal maintained each ESR for nine release cycles (54 weeks) with a two cycle (12 week) overlap. Recent lines have run longer: ESR 128 from 9 July 2024 to 19 August 2025, ESR 140 from 24 June 2025 to 29 September 2026. ESR 153 started on 21 July 2026; ESR 175 is planned for 29 June 2027 and ESR 153 ends with the 21 September 2027 train.
• Security milestones from Mozilla's release notes: mandatory add-on signing and the first e10s rollout in 48, Enhanced Tracking Protection on by default in 69, HTTPS-Only Mode in 83, Total Cookie Protection by default in 103, Site Isolation (Fission) for everyone plus RLBox in 95, and Manifest V3 by default in 109 with Manifest V2 still supported.
• Security fixes ship in every scheduled release and ESR point release, with dot releases when needed, each with its own Mozilla Foundation Security Advisory (MFSA).
• Fleets manage Firefox with enterprise policies. The biggest operational risk is a policy that disables updates and is then forgotten.

How did Firefox begin?

Firefox started as a slimmed down browser carved out of the Mozilla Application Suite. Mozilla's own history page puts it this way: Mozilla 1.0, the suite, shipped in 2002, and in the same year community members released the first version of Phoenix, "later renamed to Firefox," with the goal of giving the widest possible set of people the best possible browsing experience. The Mozilla Foundation was created in 2003 as an independent non-profit. Firefox 1.0 was released in 2004 and, according to the same page, was downloaded more than 100 million times in less than a year.

Why the early cadence mattered for security

From 1.0 to 4.0, Firefox shipped big numbered releases with security fixes delivered as dot releases in between. The weakness is familiar: many users sit on old major versions, each needs its own maintenance branch, and hardening that needs architecture changes waits a long time to reach anyone.

Firefox 4.0 (released 22 March 2011, per the archived release notes) is the last release of that era. Among its changes, the notes list support for HSTS, the header that lets a site insist it is only loaded over a secure connection, and changes to how XPCOM components are registered to help startup time and process separation, an early hint of the multi process work that would take another five years to ship.

How did the release cadence change?

The short version: yearly, then six weeks, then four weeks, then two weeks. The dates below come from Mozilla's release calendar (whattrainisitnow.com, run by Mozilla's release management team) and from Mozilla's release notes.

Rapid release from Firefox 5

Firefox 5.0 was "offered to release channel users on June 21st, 2011," three months after 4.0. From then on, a feature moved through four channels: Nightly (built from mozilla-central), Aurora (later replaced by Developer Edition, which follows the Beta schedule), Beta and Release. Each train lasted a fixed period, and when it left the station the next version number started. Mozilla's own ESR proposal from that time describes a release cycle as six weeks.

Fixes reached users far faster, but organisations that certified a browser once a year now faced a new major version every six weeks. That pressure produced ESR.

Four week releases from 2020

In September 2019 Mozilla's Future Releases blog announced the change. It said Firefox had typically shipped a major release every six to eight weeks, that the move to four weeks would be deployed gradually starting with Firefox 71, and that Mozilla aimed to reach a four week cadence by the first quarter of 2020.

The calendar's past releases table shows the gaps shrinking at the start of 2020: Firefox 72 on 7 January 2020, 73 on 11 February, 74 on 10 March, 75 on 7 April, 76 on 5 May and 77 on 2 June 2020. From then until mid 2026 almost every train was four weeks, with a few five or six week trains around year end. Four week trains meant roughly 13 scheduled releases per year, each with a security advisory.

Two week releases from Firefox 155

The current calendar shows Firefox 154 on 18 August 2026 and Firefox 155 on 1 September 2026, followed by 156 on 15 September, 157 on 29 September and 158 on 13 October 2026, a release every two weeks. The upcoming table continues it: Firefox 159 on 27 October, 160 on 10 November and so on into 2027. For Firefox 159, Nightly started on 27 September and Beta on 8 October.

The ESR point releases follow the same days, so ESR 153.6 ships with Firefox 159 on 27 October 2026, ESR 153.7 with Firefox 160 on 10 November, and so on.

What is Firefox ESR?

Firefox ESR is the Extended Support Release: a Firefox version that stays on one major version for about a year, gets security fixes and selected stability fixes, and does not take new web platform features in the middle of its life. It is aimed at organisations, schools, libraries, kiosks and anyone who needs a stable, certifiable browser rather than the latest features.

The original ESR rules

Mozilla's ESR proposal on its wiki set the original rules:

• An ESR is based on an official desktop Firefox release.
• Each ESR is maintained for nine release cycles, which at the time was 54 weeks, close to the one year target.
• Point releases coincide with regular Firefox releases, and an urgent security fix (Mozilla calls these chemspills) ships to ESR at the same time it ships to Release.
• A new ESR overlaps the old one by two cycles (12 weeks), so organisations get up to 12 weeks to test against Beta before the new ESR ships, and another 12 weeks to certify and move.

Mozilla's September 2019 post on the four week cycle restated the target in simpler terms: a major ESR release every 12 months, with three months of support overlap between the new ESR and the end of life of the previous one.

The proposal also notes that from ESR 24, the version number's second digit tracks the matching mainline version. So ESR 115.13 shipped alongside Firefox 128, and ESR 153.5 shipped alongside Firefox 158.

Every ESR line and its dates

The table below is built from the whattrainisitnow ESR releases data (first and last release dates per major line) and the ESR schedule page. ESR 10 predates that dataset's first entries, so its start date comes from the Firefox 10 release notes.

How the overlap works

An ESR overlap is the period when two ESR lines both receive security fixes. During that window, Mozilla ships a point release for each line on every release day, and the matching ESR column in the calendar shows both: for example "140.13 + 153.0" for Firefox 153 on 21 July 2026, up to "140.17 + 153.4" for Firefox 157 on 29 September 2026. After that, Firefox 158 shipped only 153.5.

The current ESR schedule page lays out the next transition. ESR 175.0 is planned for 29 June 2027 alongside 153.22. Both lines then get point releases until 7 September 2027 (175.5 and 153.27), and on 21 September 2027 the page says "ESR 153 is EOL" and ESR 153 users update to ESR 175. That is about eleven weeks of overlap at a two week cadence.

The overlap is your migration window: if the next ESR has not passed testing when it closes, you are unsupported. Firefox's updater moves ESR users on when the old line ends (the schedule says "Updates to ESR 175"), unless updates are disabled by policy, in which case nothing moves and nothing warns you.

Why ESR 115 lasted so long

Firefox 115.0 (4 July 2023) was the last major Firefox version for Windows 7 and Windows 8 and for macOS 10.12, 10.13 and 10.14. The release notes say users on those systems would be migrated to ESR 115 so they kept receiving important updates. The ESR schedule page now says Mozilla has extended support for ESR 115 only on Windows 7 to 8.1 and macOS 10.12 to 10.14 until March 2027. The calendar shows 115.53 on 23 March 2027 as the last planned build and marks the ESR 115 branch as end of life with the 6 April 2027 train.

Firefox security features by era: the timeline

Every row below comes from the Firefox release notes for that version on mozilla.org, with the date shown on the notes page.

Architectural changes (multi process, site isolation, library sandboxing) took staged rollouts over several releases. Policy and protocol changes (TLS versions, SHA-1, cookie partitioning) arrive as single release note lines that can break internal sites overnight, and ESR fleets meet them all at once at the next ESR jump.

The multi process era: e10s, Quantum and Fission

e10s: content in its own process

Before Firefox 48, desktop Firefox ran the browser interface and all web content in one process. A crash or a memory corruption bug in content code ran with the same privileges as the browser itself. The Electrolysis project (e10s) split web content into separate content processes. Firefox 48's release notes describe the start of the rollout plainly: "Process separation (e10s) is enabled for some of you."

Process separation is what made a content sandbox possible. Once web content lived in its own process, that process could be locked down with operating system sandboxing so that a bug in page handling no longer meant direct access to files, devices or the network.

Quantum: a new engine

Firefox 57 (14 November 2017) was branded Firefox Quantum. The release notes describe "a completely new browsing engine, designed to take full advantage of the processing power in modern devices." Quantum was a performance and architecture project rather than a security feature, and the same release let users keep Tracking Protection on at all times.

How does Fission site isolation work?

Fission is Mozilla's project name for site isolation. Firefox's own source documentation for the process model explains how it works:

• Parent process. The parent process runs the browser UI and privileged internal pages such as about:preferences and about:config. It has extra protections and is treated, for process selection purposes, like a content process with no remote type.
• Content processes. Content processes are the only processes other than the parent that load and run JavaScript. They are divided into "remote types" that decide what each process may load and how it is sandboxed.
• Isolated web content. With Fission, web content that can be attributed to a specific site loads in a process with the remote type webIsolated=$SITE. That process will only load content from the named site. A separate pool is used per site, with additional separation for container tabs and private browsing.
• Shared web content. Content that cannot be attributed to a specific origin (for example some user initiated data: URIs) goes to a shared web process.
• Cross-origin isolated content. Pages that send COOP and COEP headers get webCOOP+COEP=$SITE processes, also keyed by site.
• Special content types. file:// URIs load in a separate File content process that is less sandboxed than web processes. High value Mozilla pages load in a privilegedmozilla process even when Fission is off, and privileged about: pages can load in privilegedabout. Extensions run in their own extension process.
• Utility processes. The GPU process does compositing and talks to graphics hardware, the network (socket) process handles networking, and the data decoder (RDD) and newer utility processes run untrusted decoding code in tight sandboxes.

The point of site isolation is that a page from one site can no longer share an address space with a page from another site. Firefox 94's release notes give the motivation directly: protecting users against side channel attacks such as Spectre. If a bug or a speculative execution side channel lets an attacker read memory in the content process, the memory in that process belongs to the attacker's own site, not to your bank or your mail provider in another tab.

Site isolation is a defence in depth layer. It does not fix bugs; it limits what a bug in one site's content process can reach. That is why it pairs with the content sandbox and with the RLBox work below. For how attackers have historically tried to break out of browser sandboxes, and what each fix taught, see our browser sandbox escape history.

RLBox: sandboxing libraries inside a process

Firefox 95's notes describe RLBox as "a new technology that hardens Firefox against potential security vulnerabilities in third-party libraries," now enabled on all platforms. RLBox compiles selected third party libraries (for example font and media parsing code) so they run in an isolated memory region inside the content process, with checked interfaces in and out. For a supply chain reader this is the most interesting line in Firefox's history: the browser treats some of its own third party dependencies as untrusted and sandboxes them, rather than assuming the code it ships is safe because it ships it.

Later releases kept pushing in the same direction. Firefox 102 moved audio decoding into a separate process with stricter sandboxing, and Firefox 109 enabled Arbitrary Code Guard, a Windows exploit mitigation, in the media playback utility processes.

Privacy and transport security eras

Tracking protection to Total Cookie Protection

Firefox's tracking protection work runs in a straight line through the release notes:

1. Firefox 43 (December 2015): Private Browsing with Tracking Protection offers a choice of block lists.
2. Firefox 57 (November 2017): Tracking Protection can be on at all times, not just in private windows.
3. Firefox 63 (October 2018): Content blocking settings let users block third party tracking cookies or all trackers.
4. Firefox 69 (September 2019): Enhanced Tracking Protection is on by default, blocking third party tracking cookies and cryptominers; the Strict setting also blocks fingerprinters.
5. Firefox 86 (February 2021): Total Cookie Protection arrives in Strict mode, giving every website its own cookie jar.
6. Firefox 103 (July 2022): Total Cookie Protection is on by default, so all third party cookies are isolated into partitioned storage.
7. Firefox 153 (July 2026): outdated cookie settings are removed from the settings UI, and users still on them are pointed to the default "Isolate cross-site cookies" behaviour.

Steps 6 and 7 are the ones that break enterprise web apps: single sign on flows and embedded widgets that relied on unpartitioned cookies can behave differently, and ESR users met this when moving from ESR 102 to ESR 115.

TLS, certificates and HTTPS-Only

• Firefox 4 added HSTS support.
• Firefox 74 (March 2020) disabled TLS 1.0 and 1.1; sites that do not support TLS 1.2 show an error page.
• Firefox 83 (November 2020) introduced HTTPS-Only Mode, which upgrades every connection to HTTPS and warns when a secure connection is not available.
• Firefox 91 (August 2021) added an HTTPS-First policy in Private Browsing windows, which tries HTTPS and falls back only when the site does not support it.
• Firefox 103 (July 2022) removed the option to allow SHA-1 signatures in certificates.
• Firefox 153 (July 2026) verifies and displays Qualified Website Authentication Certificates under the EU eIDAS rules.

DNS over HTTPS

DNS over HTTPS (DoH) sends DNS lookups over an encrypted HTTPS connection to a chosen resolver instead of in plain text to whatever resolver the network hands out. Firefox calls its implementation TRR (Trusted Recursive Resolver). Firefox's networking source documentation describes a separate "DoH Rollout" component: front end code that decides whether TRR is enabled automatically for users in the rollout, controlled by the network.trr.mode and doh-rollout.mode preferences, and that does not overwrite a user's own settings. Which users are in the rollout has changed over time and depends on region, so check Mozilla's current documentation rather than assuming a default.

For a fleet the important control is the DNSOverHTTPS enterprise policy. According to the policy templates, it sets whether DoH is enabled, which provider URL to use, and whether users can change it (Locked). Organisations with split horizon DNS, where internal names only resolve on the corporate resolver, should set this policy explicitly rather than leave the decision to the rollout logic.

Extension signing and Manifest V3

Firefox 48's release notes say add-ons that have not been verified and signed by Mozilla will not load. Signing means an extension has to be verified and signed by Mozilla before release builds will load it, which makes it much harder for other software to slip an unsigned extension into a profile.

Firefox 109 (January 2023) enabled Manifest V3 extensions by default while keeping Manifest V2 enabled and supported. Mozilla's add-ons blog set out the approach in May 2022: "Mozilla will maintain support for blocking WebRequest in MV3," and Firefox would also ship declarativeNetRequest for compatibility with other browsers. The MDN reference for the webRequest API explains the mechanics: an extension needs the webRequest permission, host permissions, and the webRequestBlocking permission to register a blocking listener that can cancel or modify a request. That matters for content blocking and enterprise security extensions that need to inspect and block requests synchronously.

Mozilla also sets rules for what data an extension may send, covered in our post on Mozilla add-on data consent rules.

Add-on signing has one more operational edge: Firefox 128's notes record that the root certificate used to verify add-ons and signed content was renewed ahead of its expiry. Old builds that never receive that update eventually lose the ability to verify signed add-ons, which is one more reason not to run a long dead version.

How do Firefox security fixes ship?

Advisories per release

Mozilla publishes a Mozilla Foundation Security Advisory (MFSA) for each release that fixes security bugs. Advisories are numbered by year and sequence (MFSA 2026-NN) and list each fixed issue with a CVE identifier, an impact rating (critical, high, moderate or low) and the products fixed. Firefox and Firefox ESR get separate advisories for the same release day, and Thunderbird gets its own advisories on its own schedule. The advisories index page groups them by product version, so you can find the advisory for exactly the version you run.

Impact ratings follow Mozilla's client security severity ratings, published on its wiki:

• Critical issues are urgent and present an ongoing or immediate danger to users; actively exploited vulnerabilities are the example given. The page says there is no technical difference between critical and high, only a difference in risk to users.
• High issues are exploitable and can lead to widespread compromise of many users with nothing more than normal browsing. Most memory corruption, universal cross site scripting and cross origin data leaks fall here.
• Moderate issues would be high but need unusual user actions, or are limited in scope.
• Low issues have clear security implications but are typically unexploitable, very limited, or need excessive time to exploit.

A "memory safety bugs" entry that rolls up several crash fixes is common in each advisory. The October 2026 cycle shows the pattern: MFSA 2026-106 covers Firefox 158, MFSA 2026-107 covers ESR 115.43 and MFSA 2026-108 covers ESR 153.5, followed a week later by a dot release round with MFSA 2026-111 (Firefox 158.0.1), 2026-112 (ESR 153.5.1) and 2026-113 (ESR 115.43.1).

Scheduled releases, dot releases and ESR backports

There are three paths for a fix:

1. Scheduled release. Most security fixes land in the next scheduled release, which now arrives every two weeks. The fix lands in Nightly, is uplifted to Beta and Release where needed, and ships with the advisory.
2. Dot release. When a fix cannot wait (for example an issue reported as exploited), Mozilla ships an unscheduled dot release such as 158.0.1 or an ESR point release such as 153.5.1. The ESR proposal calls these chemspills and ships them to ESR at the same time as Release.
3. ESR backport. Security fixes are backported to every supported ESR line. A fix that depends on a feature ESR does not have may need a different patch, and in rare cases a fix lands later on ESR or does not apply. The ESR advisory lists what was fixed on that line.

Tracking a fleet against releases

A workable tracking routine:

• Subscribe to the advisories and the release calendar's ICS feed.
• On each release day, note the Release and ESR versions from the calendar's "Matching ESR" column and compare your inventory. With two week trains, two releases behind is a month out of date.
• Read the ESR advisory for ESR machines, and track Thunderbird and any embedded Gecko build separately.
• If you also run Chromium based browsers, see how to follow Chrome security fixes.

How do enterprises manage Firefox?

Enterprise policies

Firefox 60's release notes (9 May 2018) announced "a policy engine that allows customized Firefox deployments in enterprise environments, using Windows Group Policy or a cross-platform JSON file," and ESR 60 was the first ESR to carry it. Mozilla's policy templates page lists the ways to deliver policies today:

• A policies.json file in a directory called distribution next to the Firefox executable. The file must be UTF-8.
• Windows Group Policy, using the ADMX templates Mozilla publishes, or Intune on Windows.
• macOS configuration profiles, which also need the EnterprisePoliciesEnabled key to turn policy support on.

Mozilla's Firefox administrator reference adds that Firefox and Firefox ESR can be deployed with common enterprise configuration systems, and it now keeps a changelog of policy changes, which the Firefox 158 release notes point to.

Mozilla's policy templates site lists every supported policy, the version it arrived in and whether it is ESR only. Policies that matter most for security include:

Firefox shows the policies it has loaded at about:policies, including errors for policies it could not parse. That page is the first thing to check when a policy seems not to work.

Update controls and the risk of pinning

Pinning a browser version is tempting: test once, then hold still. With Firefox the cost is clear from the calendar. A pinned Release build misses a security release every two weeks. A pinned ESR build is supported only until its line ends, and after the overlap it gets nothing.

The risks of pinning or disabling updates:

• Silent end of life. If DisableAppUpdate is set and your software distribution system misses a cycle, nothing alerts users; the browser keeps working.
• Add-on and certificate expiry. Old builds can lose the ability to verify signed add-ons after root certificate renewals, as the Firefox 128 notes illustrate.

If you must control versions, control them actively: deploy ESR, let the updater run inside the ESR line, and plan each ESR jump inside the overlap window.

Release versus ESR versus Beta and Nightly

A common structure is: a small ring on Beta for web app owners, the main fleet on ESR, and a Release ring for teams that need new web platform features sooner. Whatever you choose, each ring needs an owner and an update path.

Step by step: check, compare, read and verify

1. Check the running version and channel

On the desktop, open the menu, then Help, then About Firefox. The dialog shows the version and, for ESR, an "esr" label in the version string. You can also type about:support in the address bar and read the "Version" and "Update Channel" rows.

From a shell:

# Linux
firefox --version
# Example output: Mozilla Firefox 153.5.1esr

# macOS
/Applications/Firefox.app/Contents/MacOS/firefox --version

# Channel is recorded in the install's defaults/pref/channel-prefs.js
grep app.update.channel /usr/lib/firefox*/defaults/pref/channel-prefs.js 2>/dev/null
grep app.update.channel /Applications/Firefox.app/Contents/Resources/defaults/pref/channel-prefs.js 2>/dev/null

On Windows, read the file version of firefox.exe:

(Get-Item "C:\Program Files\Mozilla Firefox\firefox.exe").VersionInfo.ProductVersion
Get-Content "C:\Program Files\Mozilla Firefox\defaults\pref\channel-prefs.js"

2. Compare with the current Release and ESR

Mozilla's product details service publishes the current versions as JSON:

curl -s https://product-details.mozilla.org/1.0/firefox_versions.json

On 25 October 2026 it returned LATEST_FIREFOX_VERSION as 158.0.1, FIREFOX_ESR as 153.5.1esr and FIREFOX_ESR115 as 115.43.1esr, with FIREFOX_ESR_NEXT empty because no ESR overlap is running. During an overlap, FIREFOX_ESR_NEXT names the incoming line. Compare the major and minor parts with what you found in step 1. If your ESR's major version matches none of the ESR keys, that line is out of support. Use the release calendar, not this file's date fields, for planning: on the day we checked, its NEXT_RELEASE_DATE field did not match the calendar's next release day.

3. Read the advisory for your version

Open the security advisories index and find the newest advisory that names your product and version. If your running version is lower than the "Fixed in" version of any advisory, you are missing those fixes. For ESR, read the ESR advisory specifically.

4. Verify the update policy

Open about:policies on a sample machine. Check for DisableAppUpdate, AppAutoUpdate, ManualAppUpdateOnly and AppUpdateURL. Then check where the policies come from:

# Linux and macOS installs: look for a distribution policies file
cat /usr/lib/firefox*/distribution/policies.json 2>/dev/null
cat /Applications/Firefox.app/Contents/Resources/distribution/policies.json 2>/dev/null

# macOS configuration profile keys
defaults read /Library/Preferences/org.mozilla.firefox 2>/dev/null

# Windows Group Policy registry keys
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Mozilla\Firefox" -ErrorAction SilentlyContinue

A minimal policies.json that keeps updates on and blocks unapproved add-ons looks like this:

{
  "policies": {
    "AppAutoUpdate": true,
    "DisableAppUpdate": false,
    "ExtensionSettings": {
      "*": { "installation_mode": "blocked" },
      "approved-addon@example.com": { "installation_mode": "allowed" }
    },
    "HttpsOnlyMode": "enabled"
  }
}

Replace the example add-on ID with the add-ons you have actually approved. Test it on one machine, confirm it shows at about:policies without errors, then roll it out.

Common mistakes

• Staying on an ESR after its end date. The overlap window closes on a published date. After that, the old line gets no fixes at all.
• Disabling updates by policy and forgetting it. DisableAppUpdate is a valid choice only if your own deployment tool reliably installs every Release or ESR point release. Audit it every quarter.
• Assuming Thunderbird and Firefox ESR share dates. Thunderbird is built on Gecko and its version numbers now mirror Firefox (the October 2026 advisories cover Thunderbird 158 and 153.5.1), but it ships its own builds with its own advisories and timing. Track it as a separate product.
• Missing bundled Gecko in other apps. Derivative browsers, kiosk shells and embedded apps may ship their own Gecko build, often based on an ESR line, updated on the vendor's schedule. List each as its own component with its own version and end date; if its ESR base has ended, the vendor must backport fixes or you are exposed.
• Treating ESR 115's extension as general. It applies only to Windows 7 to 8.1 and macOS 10.12 to 10.14, and only until March 2027.
• Reading only the Release advisory. ESR fixes are listed in their own advisory, and the version numbers differ.
• Skipping web app testing before an ESR jump. Moving from one ESR to the next brings a year of platform changes at once, such as the default cookie partitioning that arrived between ESR 102 and ESR 115.
• Trusting every enterprise root. The Certificates policy with ImportEnterpriseRoots makes Firefox trust whatever is in the OS store, including inspection proxies. Know what is there.

FAQ

When was Firefox first released?

Phoenix, later renamed Firefox, was first released in 2002; Firefox 1.0 followed in 2004, per Mozilla's history page.

What is the current Firefox ESR version?

As of 25 October 2026, the current ESR is 153 (latest build 153.5.1, released 20 October 2026), and the current Release is 158.0.1. ESR 115 is still updated only for Windows 7 to 8.1 and macOS 10.12 to 10.14.

How long is a Firefox ESR supported?

About a year plus an overlap. The original proposal set nine release cycles (54 weeks). Recent lines ran from about 13 to 16 months: ESR 128 from July 2024 to August 2025, ESR 140 from June 2025 to September 2026.

When does Firefox ESR 153 end?

The ESR schedule page lists 153.27 on 7 September 2027 as the last ESR 153 build alongside 175.5, and says ESR 153 is end of life with the 21 September 2027 train, when users update to ESR 175.

How often does Firefox release a new version?

Every two weeks since Firefox 155 on 1 September 2026, according to the release calendar. Before that it was about every four weeks from 2020, and about every six weeks from 2011.

Does Firefox ESR get the same security fixes as Release?

It gets security fixes backported on the same release days, with its own advisory. Features do not change mid line. In rare cases a fix depends on code ESR does not have and needs a different patch.

What is Fission in Firefox?

Fission is Mozilla's site isolation project. Web content from each site loads in its own content process (remote type webIsolated=$SITE). It began rolling out in Firefox 94 and was enabled for all users in Firefox 95.

Does Firefox support Manifest V3 extensions?

Yes. Firefox 109 enabled Manifest V3 by default and kept Manifest V2 supported. Mozilla's documentation says Firefox keeps the blocking webRequest API available in MV3.

Is Firefox ESR the same as Firefox Enterprise?

No. ESR is a release channel. Mozilla's administrator reference describes Firefox Enterprise as a separate version managed from an admin console on the customer's own infrastructure; Firefox and ESR keep using the same policies.

Why supply chain hygiene still matters here

Safeguard does not update browsers, manage endpoints or scan desktop installs, so its role for a Firefox fleet is indirect. Where it does apply is in the builds your own teams ship: Safeguard policy gates can Block, Warn or Notify when a build carries a vulnerable component version, with approval handled through exceptions. The same discipline this post recommends for Firefox, knowing which version of each component you ship, which line it belongs to and when that line ends, applies to the open source dependencies and container images your own teams build, and Firefox itself shows why: Mozilla sandboxes some of its own third party libraries with RLBox rather than trusting them because they ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You ask it to fix a vulnerable dependency, it reads the finding and the advisory, asks before any command that changes something, edits package.json to the fixed lodash version, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same pattern fits the web apps your Firefox users reach: a front end dependency moves to its fixed version through a reviewed change, not a ticket.

Click through it at your own pace, or open it full screen.

The second demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. Teams that build kiosk images, VDI images or containers with a bundled browser can scan those images the same way to see which open source packages and versions they carry.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects contain a given component and version, and get answers from your own scan data.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Mozilla: History of the Mozilla Project
• Firefox Release Calendar (whattrainisitnow)
• Firefox ESR schedule (whattrainisitnow)
• whattrainisitnow ESR releases data
• Mozilla wiki: Firefox Extended Support Release proposal
• Mozilla wiki: Release Management, Rapid Release
• Firefox release notes index
• Firefox 4.0 release notes
• Firefox 5.0 release notes
• Firefox 10.0 release notes
• Firefox 43.0 release notes
• Firefox 48.0 release notes
• Firefox 57.0 release notes
• Firefox 63.0 release notes
• Firefox 69.0 release notes
• Firefox 74.0 release notes
• Firefox 83.0 release notes
• Firefox 86.0 release notes
• Firefox 91.0 release notes
• Firefox 94.0 release notes
• Firefox 95.0 release notes
• Firefox 102.0 release notes
• Firefox 103.0 release notes
• Firefox 109.0 release notes
• Firefox 115.0 release notes
• Firefox 128.0 release notes
• Firefox 140.0 release notes
• Firefox 153.0 release notes
• Firefox 155.0 release notes
• Firefox 158.0 release notes
• Firefox source docs: Process Model
• Mozilla Foundation Security Advisories
• Firefox enterprise policy templates
• Firefox Enterprise
• Firefox administrator reference
• Firefox 52.0 release notes
• Firefox 60.0 release notes
• Mozilla Future Releases: Moving Firefox to a faster 4-week release cycle
• Mozilla wiki: Security Severity Ratings (Client)
• Mozilla product details: firefox_versions.json
• Firefox source docs: DNS over HTTPS (TRR) and DoH Rollout
• Mozilla Add-ons Blog: Manifest V3 in Firefox, recap and next steps
• MDN: webRequest API

Last reviewed: 25 October 2026.