Postiz 2.25.3: a 9.9 flaw lets any registered user seize your org

If you run Postiz on your own server to schedule social posts, Oct 24, 2026 brought an update you should not postpone. Version 2.25.3 closes two critical flaws. The worse one, scored 9.9 out of 10, lets an ordinary registered user become super administrator of someone else's organization and read its API key. Forged tokens also do not expire, so updating alone is not enough.

What happened on Oct 24?

Postiz released version 2.25.3 on Oct 24, 2026, with two security advisories for two critical flaws: one forges tokens, the other reads server files.

The first advisory, PSA-2026-YT2HMH, is CVE-2026-115933, scored 9.9, about token forgery. The second, PSA-2026-E9AHFV, is CVE-2026-115932, scored 9.6, about reading server files.

Both flaws were reported to Postiz on Oct 23. The team reproduced them the same day and pushed the fix on Oct 24. So it took less than a day from report to fix. That speed is good, but the advisories went public with the fix, so any old version is now an obvious target. The official release page recommends that all users upgrade immediately.

How does a forged token steal a whole organization?

Postiz signs login sessions, invitations and password resets with one shared secret, and nothing marks what a token is for. A route that refreshes a browser-extension channel's credentials signed data the user sent in the request itself, and left the result where that user could read it back.

So an ordinary user can ask for a correctly signed token holding any claims they want, and the app accepts it as a login session, as an invitation to an organization with a role they choose, as a password reset, or as an enterprise provisioning token. The advisory says researchers proved the attack end to end: a newly self-registered user became super administrator of another user's organization and read its API key.

Worse, self-registration is open by default in Postiz. The attacker needs no leaked account and no invitation from anyone: they register an ordinary account, then become admin of any organization whose id they know. That id shows up in any shared post preview link.

We saw one key opening everything before, when stolen UpdraftCentral keys opened backdoors on WordPress sites. In Postiz the attacker does not even need to steal the secret: the same secret signs every token type, so one route that signs user data was enough to make forgery possible.

What about the server file read?

The second flaw lets a registered user read files from the server's disk. When a post is published, Postiz treats a media path that is not a web address as a file on the disk, without checking that the file sits inside the upload directory.

The user stores a crafted file path with a post and gets it past the checks, and the publishing worker reads the file and sends it as an attachment to a Discord server the attacker controls.

The main route needs the Discord provider enabled in your Postiz. But there are two more routes: one reveals whether a path exists and can stop the server from answering with a single request aimed at a device file, and the other reaches the same file read if your Postiz stores media locally. The shipped Postiz container runs the publishing worker as root, so any file root can read is exposed, including the environment file holding the token-signing secret, the database address and provider secrets.

So the two flaws complete each other: one forges tokens, the other reads the secret those tokens are built on.

What should you do now?

Update first, then rotate the token secret. Use the two stopgaps only if you cannot update yet.

1. Update to Postiz 2.25.3 now. This is the full fix for both flaws, and the release page recommends it to all users.

2. Rotate the token secret after updating. Old forged tokens do not expire, so changing the secret is what kills them.

3. If you cannot update yet, close self-registration with DISABLE_REGISTRATION=true, and if you do not use channels that rely on the Postiz browser extension, block POST /integrations/extension-refresh at your reverse proxy. These steps lower the risk but do not close it: the second invitation route stays open, and any existing account can still attack.

4. Check your logs for odd activity: new admins added to organizations, API keys read from accounts you do not know, or posts carrying strange file paths.

Your other self-hosted tools on the same server may be in the same shape. The npm worm that steals AI tool keys showed that the supply chain and the small tools around your project are as easy a target as the main app.

When did you last review your self-hosted tools?

These two flaws need no long attack chain: an ordinary account, a shared secret and an unchecked file path are enough. If you run Postiz on your server, update today and rotate the secret, then ask yourself: which other tool of yours signs its tokens with one secret, or accepts file paths from users without checking them?

If you want someone to check those settings before anyone else finds them, Muhassan tests your platform and hands you a clear fix plan.