v3.2.1

[cnkk]

Security related update

This patch release fixes a security vulnerability affecting the following versions of Plausible Community Edition (image: ghcr.io/plausible/community-edition):
Tags:

• v3.2
• v3.2.0
• v3
• v3.2.0-rc.0
• v3.1
• v3.1.0
• v3.1.0-rc.1
• v3.1.0-rc.0
• v3.0.1
• v3.0
• v3.0.0
• v3.0.0-rc.6
• v3.0.0-rc.5
• v3.0.0-rc.4
• v3.0.0-rc.3
• v3.0.0-rc.2
• v3.0.0-rc.1
• v3.0.0-rc.0

The affected versions expose a HTTP "/storybook" endpoint which, under certain conditions, allows remote code execution with privileges of system user running the application.

This release v3.2.1 of Plausible Community Edition completely removes that endpoint.

Who is affected?

All deployments of Plausible Community Edition running the following versions:

• v3.2
• v3.2.0
• v3
• v3.2.0-rc.0
• v3.1
• v3.1.0
• v3.1.0-rc.1
• v3.1.0-rc.0
• v3.0.1
• v3.0
• v3.0.0
• v3.0.0-rc.6
• v3.0.0-rc.5
• v3.0.0-rc.4
• v3.0.0-rc.3
• v3.0.0-rc.2
• v3.0.0-rc.1
• v3.0.0-rc.0

where HTTP "/storybook" endpoint is exposed to a public or other untrusted network.

Mitigation

All affected versions of Plausible Community Edition should be updated to v3.2.1 as soon as possible.

As an immediate mitigation, it is recommended to block access to HTTP "/storybook" endpoint in your reverse proxy configuration or via other applicable means.

Changes in this release

• Remove HTTP "/storybook" endpoint along with the associated logic

No other changes are included in this release.

---

This discussion was created from the release v3.2.1.

[Calyhre]

Thanks for the quick fix, but I feel that the framing here significantly undersells this.

I tested /storybook on a default instance and it's wide open, no auth. And it seems that it gives arbitrary code execution as the app's system user via the websocket. Is it related to CVE-2026-8467 / GHSA-55hg-8qxv-qj4p? If so, the affected dependency was shipped in the CE image since v3 (more than a year of releases).

Honestly, I feel lucky that I randomly came across this release and upgraded my instance quickly. Anyone who isn't watching this repo has almost no way to know they're running an unauthenticated RCE.

I have a few concerns about it:

1. No CVE / GitHub Security Advisory. Posted inside a release description, this won't surface in automated security scanners. Feels like an unauthenticated RCE warrants a bit more than a release note.

2. "under certain conditions" / "untrusted network". Self-hosted Plausible is public-facing by design, and /storybook was reachable unauthenticated. Saying this only applies under certains conditions really undersell the potency of this vulnerability.

3. No compromise guidance. This was exploitable for a bit more than a year. Anyone whose /storybook was reachable should assume possible breach: rotate secrets/DB creds and check logs for unexpected /storybook access. Some IOCs would help.

Removing the route was definitely the right call, but please publish a proper GHSA/CVE, link the upstream advisory (if it's the same one), and add compromise-assessment steps so self-hosters who don't watch this repo find out in time.

EDIT: This was published as GHSA-mhcv-h7gf-57cf. Thank you for this 👍

[Calyhre]

Quick follow up because I got curious where this could lead and dug a bit: It's pretty straight forward to get a complete system access with a default setup of community edition, completely unauthenticated.

There seems to be ~1758 instances publicly available (checked via Shodan and CE favicon hash).

[FabianRohr]

We were running CE v3.2.0 and noticed unexplained CPU load (~50% of all cores, throttled — so it never fully saturated the server). The culprit was a process named php-fpm: pool lite, which was suspicious because Plausible ships no PHP at
all. Tracing it via /proc/<pid>/cgroup led into our Plausible app container, and /proc/<pid>/exe pointed to /tmp/.OmN/cpanel-lite (deleted) — a cryptominer that had unlinked its own binary and was masquerading as php-fpm, running since
about nine days.

Indicators of compromise, if you want to check your own instance:

• docker exec <plausible-container> ps aux — look for anything besides beam.smp, epmd, erl_child_setup, inet_gethost (we had php-fpm: pool lite and a watchdog sh cpassists)
• docker diff <plausible-container> — we had an added /tmp/.OmN directory
• Sustained CPU load that doesn't match your traffic

The good news: it ran as the unprivileged plausible user and never left the container (verified: no host persistence, no lateral movement). Cleanup was: upgrade to ≥ v3.2.1, force-recreate the container from the fresh image (the miner lives
only in the container layer/memory), rotate everything in the container's environment (SECRET_KEY_BASE, other credentials, etc).

[Calyhre]

Sorry to hear that, quite a bad surprise I imagine. I also had to report some instances used by governments.

Seems like this is actively being exploited in the wild now

[RadekHavelka]

I had the same issue as Fabian, php-fpm, and [java] processes with cryptominer. I thought it was just some malformed url that made plausible stuck the first time, luckily i was on the server when the second miner poped up so i was able to kill it right away. Only after that I found this security notice :(

[jvtrigueros]

I just want to add that I got got by this CVE, please update!

[abhranil26]

Yes, i got hit by this too. Gotta update!!

[ngist]

I think me too this morning or maybe last week still trying to figure it out.

[bradley-varol]

Just got hit by this.

[Nithur-M]

Did you happen to know it by the email from your server vendor?

[bradley-varol]

@Nithur-M i found out because Beszel alerted me to high CPU usage

[destinyfkrr]

Just got hit by this. I saw the RAM usage and found a running cryptominer inside my LXC. make sure to block 103[.]189[.]234[.]47 IP from your firewalls as well.