MuleSoft's Support Treadmill: Mule 4.4 Has Been Fully Dead Since October — and 4.6 LTS Leaves Standard Support August 31

Published: August 11, 2026  ·  EOL Watch — deadline coverage  ·  Dates verified against MuleSoft's Edge/LTS release-cadence documentation and our tracked lifecycle data — methodology

Mule 4.4 has received zero updates — security fixes included — since October 8, 2025. That is the version most of the enterprise Mule estate was built on. Released September 7, 2021, it was the only current Mule runtime for twenty-six straight months: every integration flow, every API implementation, every system API an organization stood up between late 2021 and late 2023 defaulted to it, because there was nothing else to default to. Its Standard Support ended October 8, 2024; its Extended Support ended October 8, 2025. Ten months later, per our tracked demand data, Mule 4.4 remains consistently among the most-asked-about versions in our dataset — well ahead of the LTS releases that succeeded it. People are still planning around a runtime that can no longer be patched.

And while the 4.4 long tail plays out, the versions that replaced it run on a much faster clock. MuleSoft — now a Salesforce company — split the Mule runtime into two release channels starting with 4.5: Edge, where every release in our data has lived 8 to 12 months from release to End of Life, and LTS, which carries roughly three years. The nearest deadlines on that treadmill: 4.6 LTS leaves Standard Support on August 31, 2026 — 20 days from this article's publication — and 4.11 Edge reaches End of Life on October 31, 2026, 81 days out and already in its Extended window.

The 4.4 long tail: why the dead version is still the busy one

Mule 4.4's dominance is a structural artifact, not an accident. Between September 2021 and October 2023, MuleSoft shipped no new minor runtime at all — 4.4 simply was Mule 4. Those two years coincided with a heavy enterprise integration build-out, much of it delivered by systems integrators on fixed-scope engagements. The SI ships the flows, the contract ends, the team disbands — and the runtime version freezes where the project left it. Integration middleware is exactly the software category where "it works, don't touch it" wins budget arguments for years, because a Mule app that moves orders between an ERP and a warehouse doesn't accumulate feature requests. It accumulates age.

The support wall arrived in two stages. Standard Support ended October 8, 2024. Extended Support — the critical-fixes tier — ended October 8, 2025; our data records the final 4.4 patch line as the 4.4.0-20250919 build. MuleSoft's own Mule runtime release notes now list 4.4 flatly as having reached End of Life. There is no paid tier beyond Extended Support, no third-party rebuild community, no ESU program: a 4.4 runtime today is a fixed target that only gets softer.

On the exploitation question, precision matters more than drama. We checked the live CISA Known Exploited Vulnerabilities catalog (version 2026.08.10, checked August 11, 2026): it contains no MuleSoft or Mule runtime entries. That is a statement about confirmed in-the-wild exploitation, not about safety — the KEV catalog also contained no FortiOS 7.0 entry until ten months after that train's End of Life, and then it did. The structural risk of an unsupported runtime is forward-looking: every vulnerability disclosed from here on — in Mule itself, in its embedded HTTP stack, in the libraries it bundles, in the JVM configuration it certifies — will be fixed only in supported versions. For an integration runtime this cuts deeper than for most software, because Mule sits by design at the junction of everything: it holds credentials to the ERP, the CRM, the database, and the partner SFTP simultaneously. It is the box whose compromise is everyone else's incident.

One more tail behind the tail: Mule 3 is entirely gone. 3.9, the last Mule 3 line, reached End of Life on March 20, 2024 after a six-and-a-half-year run. Organizations still carrying Mule 3 apps face not just an unsupported runtime but a genuine rewrite — Mule 3 to Mule 4 was a breaking architectural change — which is precisely why some of them are still carrying it.

Edge vs LTS: the two-speed treadmill, in MuleSoft's own words

Starting with Mule 4.5 (October 2023), MuleSoft moved the runtime to two release channels, documented on its Edge and LTS release-cadence page. The policy terms, per that page:

• Edge releases ship "up to three times per year" and carry Standard Support "until one month after the next Edge version is released," followed by 3 months of Extended Support.
• LTS releases are periodic — "Scheduled for February" — and carry "a minimum of 18 months of Standard Support" plus "a minimum of 6 months of Extended Support."

Our tracked dates confirm the Edge arithmetic exactly, and it is brutal. Mule 4.10 released October 31, 2025; 4.11 followed on February 28, 2026; one month later — March 31, 2026 — 4.10's Standard Support ended, and three months after that, on June 30, 2026, 4.10 was End of Life. Eight months, release to grave. The same eight-month arc holds for 4.5, 4.6 Edge, 4.7, 4.8, and 4.12 (scheduled); 4.9 Edge got twelve months only because its successor took longer to arrive. Note also that an Edge release's Standard Support window is not even fixed at release time — it depends on when the next Edge ships. Choosing the Edge channel is not choosing a version; it is subscribing to a permanent upgrade cadence of two to three runtime moves per year.

The LTS channel delivers more than its floor promises: both LTS releases in our data — 4.6 LTS (February 29, 2024) and 4.9 LTS (February 28, 2025) — received 30 months of Standard Support plus 6 of Extended, for a three-year total. That is the channel actually shaped like an enterprise change-management calendar: one runtime migration roughly every two years, with a year of overlap between successive LTS lines to do it in.

A naming trap worth flagging: 4.6 and 4.9 each exist twice — once as an Edge release and once as an LTS release, with radically different dates. Mule 4.6 Edge died October 31, 2024; Mule 4.6 LTS is supported into 2027. An inventory that records "Mule 4.9" without the channel is ambiguous by fourteen months of support. Check the channel designation in the runtime version string before concluding anything about a deployment's status — or check the exact version here.

What the calendar looks like from August 2026

4.6 LTS is the deadline hiding in plain sight. Its Standard Support ends August 31, 2026 — twenty days out. Extended Support (critical fixes) runs to February 28, 2027, so this is a downgrade rather than a cliff, but the window to plan an orderly move is the Extended window, and it is six months wide. 4.11 Edge is further along the same path: Standard Support ended July 31, 2026, and End of Life lands October 31, 2026. 4.12 Edge reaches End of Life February 28, 2027 — the very same day as 4.6 LTS, a coincidence of the calendar that makes the channel choice vivid: the February 2027 wall claims both the newest Edge release and a three-year-old LTS at once. What survives past it: 4.9 LTS, with Standard Support to August 31, 2027 and End of Life February 29, 2028 — and, per the cadence page's February scheduling, whatever LTS ships next.

CloudHub: where the choice gets made for you

If your Mule apps run on CloudHub or CloudHub 2.0 — MuleSoft's managed runtime planes — the End of Life dates above are not advisory. The release-cadence documentation states that starting with Mule 4.7, CloudHub and CloudHub 2.0 applications on the Edge or LTS channels "that are still running End of Life versions will undergo a forced upgrade to the latest version during the monthly upgrade window." Edge channel apps move even sooner: all are auto-upgraded to the latest Edge minor during the monthly patching cycle of the month their version leaves Standard Support. In the managed cloud, in other words, the treadmill runs whether you walk or not — the only question is whether the runtime under your production flows changes on your test schedule or on Salesforce's.

Self-managed deployments — on-premises standalone runtimes and customer-hosted Runtime Fabric — get the opposite failure mode. Nothing forces an upgrade, nothing patches automatically, and a forgotten 4.4 keeps passing messages unpatched for years. That split explains the shape of the long tail: the dead versions live where no platform can reach them.

Every Mule runtime version: the full table

All dates from our tracked lifecycle data (verification pass 2026-08-11), cross-checked against MuleSoft's published release-cadence policy. "Standard Support ends" is the end of the full-support window; "End of Life" is the end of Extended Support — after it, no fixes of any kind. Each version links to its live lifecycle page with current status and risk score.

Pre-channel releases (4.4 and earlier) followed MuleSoft's older versioning policy of longer Standard windows plus multi-year Extended Support, which is why their spans differ from the Edge/LTS pattern. Note the duplicated version numbers: 4.6 and 4.9 each appear as both an Edge and an LTS release with different dates — the channel is part of the version's identity.

The decision framework: which version, honestly

Production belongs on LTS unless a specific Edge feature is worth two to three forced runtime moves per year. That is the whole framework, and MuleSoft's own channel design says as much: Edge exists to deliver features early to teams equipped to chase them; LTS exists for everyone whose integration flows outlive their project teams — which, per the 4.4 long tail above, is most of the enterprise Mule audience.

If you are on 4.4 (or anything older): the target is 4.9 LTS — the longest runway available, at eighteen more months of Standard Support (to August 31, 2027) and End of Life on February 29, 2028. Within Mule 4, the move is a minor-version upgrade rather than the Mule 3-style rewrite, but a 4.4-era estate typically carries pinned connector versions and an aging Java baseline, so treat it as a real regression-testing project per application, not a version-bump. Ten months past 4.4's last patch, the queue-jumping question is not whether to schedule it but which apps go first: start with the ones holding external-facing listeners and the broadest credentials.

If you are on 4.6 LTS: you have until February 28, 2027 at the outside, but only until August 31, 2026 on full support. The upgrade to 4.9 LTS buys exactly one year of additional End of Life runway — the LTS-to-LTS hop is the treadmill's steady state, and this is what it feels like: a migration roughly every two years, planned during the year the two lines overlap.

If you are on Edge: 4.11 dies October 31, 2026, and if those apps run on CloudHub the platform will move them for you when the time comes. Either commit to the cadence — upgrade to 4.12 now, and to its successor within months — or admit the apps are not actually being actively developed and step off onto 4.9 LTS.

We track MuleSoft Runtime and 480+ other products against vendor-verified dates — every Mule runtime version with live status, check any version in seconds, or see what else hits end of life this quarter.

Frequently Asked Questions

Related

• All MuleSoft Runtime versions with live status · Mule 4.4 — dates and risk score
• Java 17's September 30, 2026 Deadline Is Oracle's, Not Java's — the JVM under many Mule estates has its own clock
• EOL 2026, the Mid-Year Report — the year the dates got dangerous
• The 2026 EOL Calendar — everything else with an autumn date