Flarum 1.8.19 - Security Release, upgrade immediately

IanM · 2026-08-13T18:47:50+00:00

Flarum 1.8.19 — Security Release We strongly recommend all forums running Flarum 1.x upgrade to 1.8.19 immediately. This is a security release that fixes a critical vulnerability allowing account takeover via the password-reset flow. If you run a public Flarum forum, please treat this as urgent. Who is affected Flarum 1.x: all versions up to and including 1.8.18 are affected. Flarum 2.x: the 2.0.0-beta.1 through 2.0.0-beta.6 pre-releases were affected. This was resolved in 2.0.0-rc.1, so current 2.x is not affected. If you are on 1.x, you are affected and should upgrade. Impact An unauthenticated attacker could take over any account on an affected forum — including administrator accounts — without needing the victim's password-reset token or any prior access. The only prerequisite is knowing (or guessing) a registered email address. Because administrator accounts can be targeted, we consider this critical severity (CVSS 9.8). Tracked as GHSA-55f2-h36g-96c3. How to upgrade composer update flarum/core --with-all-dependencies php flarum migrate php flarum cache:clear if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } Then confirm your version: php flarum info if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } You should see Flarum core 1.8.19. If you cannot upgrade right now Upgrading is the only real fix, but if you genuinely cannot patch immediately, you can mitigate at your web server, reverse proxy, or WAF by rejecting password-reset requests whose token field is not a normal string value. Legitimate clients always send the reset token as a quoted string; the attack relies on sending a non-string value instead. Block POST /reset requests whose JSON body matches: "passwordToken"\s*:\s*(?!") if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } This blocks the malicious shape (a bare number, null, or boolean) while leaving genuine password resets untouched. Remove the rule and upgrade as soon as you are able — this is a stopgap, not a fix. Details Out of consideration for forums that have not yet upgraded, we are keeping the full technical write-up and proof-of-concept embargoed for now. Complete details will be published in the security advisory once forums have had a reasonable window to update. Thanks Thanks to the reporter for the responsible disclosure that led to this fix. Questions about upgrading? Ask in theSupport tag. Please do not post exploit details publicly.

dutchbavarian

If this is urgent, please activate the update trigger in Extension Manager. Right now it shows 1.8.18 as current.

IanM

dutchbavarian this is not how Extension Manager works, we cannot do this unfortunately.

dutchbavarian

Okay, it upgraded just now though ;-)

Karl

dutchbavarian for future reference, your updates are checked by running “check for updates.”

ClaudiusH

Karl That is why @dutchbavarian came here: He did use "Check for updates" an hour after the release went live and EM showed "Everything is up to date". Wondering if such a delay is expected after a platform release.

IanM

ClaudiusH could be one of two things, either a local cache on the results (a cache clear would resolve it), or packagist.org API cache (out of our control)

ClaudiusH

IanM I would expect an actively user initiated "Check for update" on the extension manager to always bypass a local cache. Is it worth me filing an improvement request for that or is it not feasible?

IanM

ClaudiusH A cache bust locally would certainly resolve that side of it (if that was the issue in this case). The question however is would this fit into the Critical bugfix category that is now required for changes on the 1.x line?

Karl

IanM being that the security issue is resolved in this current release, I think the go ahead for 2.x having cache buster makes more sense. I say this because the critical fix still requires a manual intervention at the current state anyways.
On the other hand, we get Flarum announcements directly in the Flarum admin dashboard. At that piint too, there shouldn’t be a reason to miss critical updates IMHO.

IanM

Karl 2.x does not suffer from the cache on the Flarum side. Is only subjected to the packagist API potentially lagging behind, so nothing to to here

Karl

IanM problem solved then 🙂

grit

спасибо вам за быстрое реагирование ❤

jslirola

IanM Block POST /reset requests whose JSON body matches:

It would be helpful to include some basic instructions for performing this temporary patch. In my case, I want to update the Flarum version, but the server hosting my forum has removed the Composer binary for some reason, and while they investigate the issue, I need to find alternatives to prevent them from taking control of my users' accounts.

GreXXL

jslirola highly depended on your hosting setup. This is a firewall configuration such as CF could be used to block it.

jslirola

GreXXL I'm using Cloudflare, and it handles the initial requests, although they're later redirected to the server where my forum is hosted. Is it easy to add blocking from Cloudflare if I don't have a paid plan? I'm using the free plan.

Karl

jslirola I have no issues using Cloudflare on the free tier.
Can you share your developer tools output?

jslirola

Karl No further investigation is necessary; I was just suggesting it for someone who doesn't have easy access to Composer. My problem has been resolved, and I quickly updated it using the commands mentioned in the first message. Now I feel much more safe using Flarum. Thanks!

Karl

jslirola ah I forgot there was a mention in the original post about blocking the vulnerability without update.
Glad you’re all good!

1337

upgraded. Thanks for the info.