CVE-2026-115933: CWE-290 in GitroomHQ postiz-app
Affects GitroomHQ postiz-appSource CVE Database V5
Not known to be exploited · CVSS 9.9 Critical : patch GitroomHQ postiz-app as a priority.
Data as of 10/24/2026, 16:08:18 UTC
- Exploitation
Not in CISA KEV, no exploitation reported
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HWhat to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| GitroomHQpostiz-app | Affected
| Fixed in
|
GitHub Actionspostiz-apppkg:github/postiz-appOther threats | Affected
| Fixed in– |
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Until an official fix is available, restrict access to affected routes and monitor for suspicious token usage. Avoid using tokens signed with a shared secret across multiple token types without proper token-type markers. Implement strict validation and separation of token signing keys per token purpose.
Description
Postiz-app versions from 2.15.0 up to but not including 2.25.3 have a critical vulnerability (CVE-2026-115933) where session, invitation, and password reset tokens are signed with a single shared secret without distinguishing token types. This flaw allows an attacker with limited privileges to craft tokens with arbitrary claims that the application accepts as valid sessions, invitations with chosen roles, password resets, or provisioning tokens. The vulnerability stems from improper authentication design (CWE-290) and insecure token handling.
Impact
An attacker with limited privileges can forge tokens that the application accepts as valid sessions, organization invitations with chosen roles, password reset tokens, or enterprise provisioning tokens. This can lead to full compromise of user accounts, unauthorized access to organizational resources, and potential takeover of enterprise provisioning processes. The CVSS score of 9.9 reflects the critical impact on confidentiality, integrity, and availability.
Summary
CVE-2026-115933 in GitroomHQ's postiz-app involves the use of a single shared secret to sign multiple types of tokens (session, invitation, password reset) without any token-type markers. A route that refreshes browser-extension channel credentials signs data taken from the request itself and stores it where the user can read it, enabling an attacker to obtain validly signed tokens with arbitrary claims. Another route creating team invitations similarly signs extra fields from the request body without proper validation. This design flaw allows privilege escalation and unauthorized actions by forging tokens accepted by the application as legitimate.