Postiz fixes three critical file-read and token-forgery flaws across two releases

What changed in two releases

Postiz has shipped two security releases in just over 16 hours. Version 2.25.2 addressed one route to reading server files and disrupting the backend. Version 2.25.3 then addressed a different file-read route and a signed-token flaw that, according to the vendor, could let a registered user take over another user or organisation. Operators should treat 2.25.3 as the minimum fixed release for all three advisories, rather than stopping at the first patch.

The distinction matters. The first file issue is an unintended provider-method call. The second is a media path that crosses out of the upload area. The token issue concerns the purpose of a valid signature. They are three weaknesses, not a demonstrated three-stage intrusion. The published records examined for this briefing do not give a victim count or establish exploitation in the wild.

Affected ranges and fixed releases, from the three vendor-assigned CVE records and Postiz release notes, checked 24 October 2026.

Issue	Affected range	Fixed release
CVE-2026-115931: provider method call, file read or backend exit	2.23.0 to before 2.25.2	2.25.2
CVE-2026-115932: post media path can read local files	2.23.0 to before 2.25.3	2.25.3
CVE-2026-115933: signed token can cross purposes	2.15.0 to before 2.25.3	2.25.3

The earlier provider-method boundary

In CVE-2026-115931, Postiz says a signed-in user could direct the backend to call provider helper methods it did not intend to expose through that path. One helper reads a local file; another can terminate the backend process. The reported outcomes are therefore different: exposure of server-side data in one case, availability loss in the other. The vendor scores the issue 9.9 on CVSS v3.1, but that score is a severity assessment, not a measured count of successful attacks.

The advisory gives a concrete route: a user connects a channel whose stored token is a file path, then asks the backend to run the file-reading helper. It says the environment can hold the session-signing secret, database address and connected-service credentials. This explains why a local-file read could lead to wider compromise, but it does not establish which files were actually read from a production deployment. Postiz lists versions 2.23.0 up to, but not including, 2.25.2 as affected.

How post media can escape the upload area

The later file route, CVE-2026-115932, sits in the post-publishing workflow. The vendor describes a media path that is not a web address being handled as a local path. The worker fails to constrain that read to the upload directory. A registered user can then cause the opened file to be delivered as a Discord attachment. The record also describes routes to test file existence and deliver a file; these are related capabilities, not proof that every possible file was accessible.

A media path crosses the file boundary

Expand Full View

This is a different trust mistake from the provider-method flaw. A publishing feature needs to read media, but the path supplied by a user should not become authority to read arbitrary server files. Postiz rates this issue 9.6 on CVSS v3.1 and lists versions 2.23.0 up to, but not including, 2.25.3. The main Discord delivery route requires the Discord provider to be configured; Postiz says the relevant credentials are empty in its shipped Docker Compose file. Disabling Discord removes that main route, not the other file routes. One can reveal whether a file exists and exhaust backend memory; another can deliver the file. The advisory says self-registration is open by default, so “registered user” does not mean administrator.

Why a genuine signature can grant the wrong authority

The third advisory, CVE-2026-115933, is about token purpose rather than a file path. Postiz says session, invitation and password-reset tokens were signed with the same secret without a marker that bound each token to its intended use. In a browser-extension channel-refresh route, claims supplied by a user could be signed and the resulting token stored where that user could read it back. Another, narrower team-invite route could sign extra fields. A valid signature then demonstrated that Postiz had signed the claims, but did not prove that those claims had been issued for the receiving workflow.

A genuine signature grants the wrong purpose

Expand Full View

According to the vendor, the forged tokens could be accepted in flows for sessions, organisation invitations, password resets and enterprise provisioning. That creates a route to taking over other users and organisations from a registered account. The affected range begins earlier than the file issues: 2.15.0 up to, but not including, 2.25.3. The vendor scores it 9.9 on CVSS v3.1. The advisory describes what the flaw permits; it does not name compromised organisations or show that all these routes were used in the same incident.

What the advisories establish, and what they do not

The vendor-assigned CVE records go beyond a theoretical description. They report end-to-end demonstrations against unmodified builds: a file and the backend signing secret returned through the provider-method route, a file outside uploads delivered byte for byte through the media route, and a second self-registered user becoming super administrator of another organisation through the token route and reading its API key. The records credit Anthropic as finder and say Postiz reproduced the reports before releasing fixes. These are reported validation tests, not evidence of an attack on an unrelated customer deployment.

Source boundary: Postiz release notes and vendor-assigned CVE records checked 24 October 2026.

Question	Stated in the records	Not established there
Patch sequence	2.25.2 fixes the provider-method issue; 2.25.3 fixes the media and token issues.	Whether every operator has deployed both releases.
Attacker access	Each described route begins with a signed-in or registered user; self-registration is open by default.	Whether any particular installation permits public sign-up.
Discord condition	The main media-to-Discord route requires the Discord provider to be configured.	That the two other media-file routes disappear when Discord is disabled.
Impact	The records report controlled end-to-end demonstrations of file reads, backend exit and forged-token effects.	A victim count, a named customer victim, or confirmed exploitation in the wild.
Credentials and data	Local files may include environment secrets; forged claims may be accepted across token purposes.	Which files or accounts, if any, were actually exposed.
Hosted service	The records specify affected Postiz software versions.	The patch state or exposure of any particular hosted tenant.

The release timestamps are also easy to misread. The GitHub release for 2.25.2 is timestamped 23 October 2026, 21:59 UTC; 2.25.3 is timestamped 24 October 2026, 14:16 UTC. The difference is about 16 hours and 17 minutes. Those are publication times for releases, not the beginning of an attack or the first time a vulnerable instance existed. The CVE records were published separately. None of these timestamps supplies a discovery date, compromise window or notification date for a victim.

What an operator should do now

The vendor's affected ranges give an upgrade threshold, not a test of whether a particular installation was exploited. For a UK organisation, the immediate decision is the same as elsewhere: establish the running version and examine the data available in its own logs. No UK-specific victim count is stated in the primary records reviewed here.

The unresolved question is operational, not rhetorical: which instances ran an affected version while public registration was possible, and what do their records show about file access and token use? The answer needs deployment evidence. A CVSS number and a release note cannot supply it.