PSA-2026-E9AHFVCVE-2026-115932GCVE-125-2026-E9AHFVOctober 24, 2026Path traversal in post media lets any registered user read server files
A registered Postiz user can make the publishing worker open files outside the upload directory and deliver their contents to a Discord server the user controls. Any file the worker can read can be taken, including files that hold the secret that signs login sessions.
Affected (1)
- GitroomHQpostiz-app
- ≥ 2.23.0Fixed in 2.25.3
Mitigations
Workarounds
- Set DISABLE_REGISTRATION=true. The attacker needs an ordinary account, so closing self-registration limits exposure to people who already hold one. This reduces reach, it does not close the issue.
- If you do not need the Discord provider, leave its client id, client secret and bot token unset. This removes the main route only; the other routes remain.
Exploits
- Exploitation was demonstrated end to end against unmodified builds of the backend and the orchestrator at commit 3a7d28b7ad96, using only a self-registered account: a file outside the upload directory arrived byte for byte as an attachment in the attacker's Discord channel. The validation-time route and the stored media route were also exercised separately against the same builds.
Configurations
- The main route requires the Discord provider to be enabled, that is DISCORD_CLIENT_ID, DISCORD_CLIENT_SECRET and DISCORD_BOT_TOKEN_ID set. These are empty in the shipped docker-compose.yaml. The storage provider does not matter.
- The validation-time route requires a Dribbble, TikTok or Pinterest provider to be configured.
- The shipped container runs the worker as root, so every file root can read is exposed. Self-registration is open unless DISABLE_REGISTRATION is set to true.
Overview
When a post is published, Postiz treats a media path that is not a web address as a file on the server's disk, but it does not check that the file lies inside the upload directory. A registered user can store a crafted media path with a post, get it past the checks that normally restrict it, and have the publishing worker read an arbitrary file and send it as an attachment to a Discord server the user controls.
The same unconfined reads can be reached through two further routes. One tells the caller whether a file exists and can exhaust the backend's memory, the other delivers the file the same way as the main route. Self-registration is open by default, so the attacker needs no existing account.
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weaknesses (2)
References (3)
Credits (3)
- Anthropic, PBCFinder
- Enno GelhausCoordinator · @egelhaus
- Nevo DavidRemediation developer · @nevo-david
Context
Impacts
Where the Discord provider is configured, any registered user can read any regular file the publishing worker can read and have it delivered byte for byte to a Discord server they control.
Files within reach include those that hold the JWT signing secret, the database address and provider client secrets, such as the instance's environment file, mounted secret files and application logs, and the worker's process environment.
A second route lets a user with a connected Dribbble, TikTok or Pinterest channel learn whether a path exists and whether it is a file or a directory, and exhaust the backend's memory with one request by pointing at a device file, which stops the backend from answering any organization until it is killed.
A third route, on instances using local storage with an empty cloud bucket URL, reaches the same file read without needing a WordPress site.
Timeline
- 10/23/2026 17:45
Anthropic has disclosed a thorough report of this vulnerability including a working PoC to Postiz
- 10/23/2026 18:00
Postiz has reproduced the vulnerability and is working on a fix
- 10/24/2026 12:26
Postiz has pushed a fix for this vulnerability and verified it