CVE-2026-115933: Postiz Token Forgery Flaw
TL;DR - CVE-2026-115933 is a critical Postiz token-forging vulnerability rated CVSS 9.9. - Registered users may obtain signed tokens usable for sessions, password resets, invitations, and provisioning. - No public PoC or confirmed exploitation was identified; upgrade to Postiz v2.25.3 or later immediately.
Summary
CVE-2026-115933 is a critical Postiz vulnerability affecting the open-source social-media scheduling platform maintained in the gitroomhq/postiz-app repository. The flaw allows a registered Postiz user to cause the application to sign attacker-controlled claims with a secret also used for other security-sensitive token types.
The resulting tokens may be accepted as legitimate browser sessions, organization invitations, password-reset tokens, or enterprise-provisioning tokens. This creates a credible path to account takeover, unauthorized organization access, privilege escalation, and compromise of other users.
For background on related security concepts, see our guide to threat intelligence and our explanation of hashing in cybersecurity.
| Field | Detail |
|---|---|
| CVE | CVE-2026-115933 |
| Product | Postiz |
| CVSS | 9.9 Critical |
| CVSS vector | Not included in the retrieved NVD record |
| Attack vector | Not formally specified in the retrieved CVSS vector; exploitation requires interaction with an exposed Postiz application |
| Authentication | A registered Postiz user is required |
| Privileges required | Low, based on the requirement for a registered account; the canonical vector should be verified when published |
| Patch available | Yes |
| Fixed version | Postiz v2.25.3 |
| CISA KEV | No |
The vulnerability was published on October 24, 2026. Exploit reporting and vendor guidance may change quickly because the CVE is newly published. The absence of a CISA Known Exploited Vulnerabilities listing does not show that exploitation is impossible or exposure is low.
Root Cause
Postiz uses one shared signing secret for multiple classes of security-sensitive tokens. Those token classes include sessions, invitations, password resets, and enterprise-provisioning workflows. The tokens also lack a sufficiently enforced purpose marker that would prevent a token generated for one workflow from being interpreted in another.
A browser-extension credential-refresh route signs data taken from the request and stores the resulting token where the requesting user can retrieve it. The attacker can therefore supply claims, obtain a validly signed token, and present it to workflows that trust the same signing secret. A separate team-invitation route reportedly signs additional request-body fields in a similar manner.
The underlying problem is not merely weak input validation. The application treats attacker-influenced data as material for a trusted security token and then reuses the resulting signature across unrelated security contexts. A cryptographic signature confirms that the server signed the data; it does not make attacker-selected claims safe.
Technical Notes
The described attack chain has five important stages:
- An attacker registers or uses an existing Postiz account.
- The attacker submits controlled claims to a credential-refresh or invitation workflow.
- Postiz signs those claims with its shared application secret.
- The attacker retrieves the signed token.
- The token is replayed against a higher-impact workflow, such as session authentication, password reset, organization invitation, or enterprise provisioning.
A secure design should use separate keys or signing domains for materially different token types, enforce an explicit purpose or audience claim, constrain claims server-side, and avoid returning sensitive tokens to an untrusted workflow unless that behavior is strictly required.
Analyst’s Take: The shared signing secret turns a low-privilege registered account into a potential bridge to higher-impact workflows. The absence of a public PoC or CISA KEV listing should not change the first response: upgrade exposed deployments, rotate relevant secrets, and review tokens and account changes that may already have been issued.
Who’s Exposed
The affected product is Postiz, the open-source social-media scheduling platform in the gitroomhq/postiz-app project. The retrieved NVD material does not provide a precise vulnerable version interval. The available remediation evidence identifies Postiz v2.25.3 as the fixed release.
Until the project advisory or package metadata establishes exact lower and upper bounds, administrators should treat all Postiz versions earlier than v2.25.3 as potentially affected. This is a conservative operational assumption rather than a claim that every historical release has been independently confirmed vulnerable.
| Deployment | Assessment |
|---|---|
Postiz < 2.25.3 |
Potentially affected; upgrade required |
Postiz 2.25.3 |
Fixed release identified by the project |
Postiz > 2.25.3 |
Expected to contain the fix, but verify release notes and local deployment state |
| Customized forks | Exposure depends on whether the vulnerable routes and token implementation remain present |
| Internet-facing instances | Highest priority because registered attackers can reach exposed workflows |
| Internal-only instances | Still exposed to any user who can register or obtain a Postiz account |
Organizations should inventory container images, package manifests, Helm values, deployment repositories, and running application versions rather than relying solely on a web interface version string. Forks and vendor-modified builds require source-level comparison with fix commit a5affe62c74e39c1e7ac960d50d8418b807d532c.
Severity Breakdown
The reported base score is CVSS 9.9 Critical. The retrieved NVD record did not include the complete CVSS vector string, so individual metric values such as exact attack complexity, user interaction, scope, and confidentiality, integrity, and availability impacts cannot be stated definitively without risking an inaccurate reconstruction.
Operationally, the score is consistent with a vulnerability that can cross trust boundaries and affect authentication and authorization decisions. A low-privilege registered user may be able to obtain tokens that the application accepts for more privileged actions, including organization access or account recovery. That makes the impact substantially greater than a defect limited to the attacker’s own account.
The practical impact includes:
- Confidentiality: Access to other users’ or organizations’ data may follow account or membership compromise.
- Integrity: Attackers may alter account state, organization membership, roles, or connected workflows.
- Availability: Account takeover and administrative changes may disrupt access, although availability impact is not the primary consequence.
- Privilege escalation: Invitation or provisioning tokens may permit attacker-selected roles, including highly privileged organization access.
- Authentication compromise: Forged session or password-reset tokens may enable impersonation.
Administrators should obtain the canonical CVSS vector from the NVD record or project advisory once available. Until then, the 9.9 score and the described impact justify critical-priority remediation for exposed deployments.
Exploitation Status
No dedicated public exploit repository or verified proof of concept for CVE-2026-115933 was identified in the available research. There is also no confirmed in-the-wild exploitation in the retrieved sources.
CISA KEV status is currently negative:
on_kev: false
cve_id: CVE-2026-115933
There is no CISA date-added value, federal remediation deadline, required-action entry, or CISA ransomware-campaign flag associated with this CVE at the time of assessment. KEV absence is not proof that exploitation has never occurred. It means only that CISA has not cataloged this CVE as a known exploited vulnerability.
The technical exploitability remains serious. A registered user can potentially obtain server-signed tokens with attacker-selected claims, and those tokens may be accepted in workflows with substantially greater authority. Treat internet-exposed instances as high priority even without a public PoC or confirmed exploitation.
Sources
The primary technical references for this issue are the NVD record and the project’s security materials. The NVD publication date and last-modified date are both reported as October 24, 2026 at 15:17:33 UTC.
- GAdvisory, “Forged signed tokens allow a registered user to take over other users and organizations”:
https://gadvisory.org/advisories/PSA-2026-YT2HMH - Postiz source repository:
https://github.com/gitroomhq/postiz-app - Postiz security fix commit:
https://github.com/gitroomhq/postiz-app/commit/a5affe62c74e39c1e7ac960d50d8418b807d532c - Postiz v2.25.3 release:
https://github.com/gitroomhq/postiz-app/releases/tag/v2.25.3 - Postiz GitHub security advisories:
https://github.com/gitroomhq/postiz-app/security/advisories
The retrieved data does not provide the canonical CVSS vector or a precise vulnerable version interval. Defenders should validate both against the authoritative NVD and project records as they are updated. Until that information is available, treat Postiz versions earlier than v2.25.3 as potentially affected and prioritize exposed, multi-tenant deployments.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should focus on unusual token-issuing workflows, abnormal account recovery, unexpected organization membership changes, and administrative actions that follow browser-extension credential-refresh activity. Because the vulnerability concerns validly signed tokens, signature validation failures alone may not identify exploitation. An attacker may use correctly signed tokens that appear cryptographically legitimate.
Review application, reverse-proxy, identity, and database audit logs for:
- Repeated or unusual requests to browser-extension credential-refresh endpoints.
- Credential-refresh requests containing unexpected claims or fields.
- Password-reset issuance followed by a reset for a different user.
- Organization invitations with unusually privileged roles.
- Enterprise-provisioning activity not associated with an approved administrator.
- New sessions, memberships, or role changes shortly after token issuance.
- Multiple accounts or organizations affected by actions from one source IP or user.
The exact route names and structured event fields were not provided in the available advisory material. Do not deploy a guessed endpoint signature as a definitive detector. First identify the application’s route and event names in the version running at your site, then build detections around those confirmed fields.
Technical Notes
A generic reverse-proxy query can identify requests to likely sensitive workflows for manual correlation. Replace the placeholder paths with the actual routes confirmed from your deployment:
index=postiz
(uri_path="*credential*" OR uri_path="*refresh*" OR uri_path="*invite*" OR uri_path="*password*")
| stats count values(uri_path) values(http_status) values(user) values(src_ip)
by bin(_time, 15m), user
| where count >= 5
For an application that emits structured audit events, a useful starting query is:
SELECT event_time, actor_id, target_user_id, organization_id,
event_type, role, source_ip
FROM security_audit_events
WHERE event_type IN (
'token_issued',
'password_reset_requested',
'password_reset_completed',
'organization_invitation_created',
'organization_membership_created',
'enterprise_provisioning'
)
AND event_time >= CURRENT_TIMESTAMP - INTERVAL '7 days'
ORDER BY event_time DESC;
Investigators should correlate token issuance and use by timestamp, actor, source address, user agent, organization, and target identity. Preserve relevant logs before rotating secrets if possible, while ensuring that sensitive token values are not copied into tickets or long-term telemetry.
Remediation Steps
Upgrade every affected Postiz deployment to v2.25.3 or later. The project identifies commit a5affe62c74e39c1e7ac960d50d8418b807d532c as the security fix. Because the exact vulnerable range is not included in the retrieved NVD record, do not assume a version earlier than 2.25.3 is safe.
For a source checkout, a controlled update can begin with:
git fetch --tags origin
git checkout v2.25.3
# Follow the repository's documented dependency-install and build steps.
For a containerized deployment, update the image reference to a release containing v2.25.3 or later, then redeploy:
docker compose pull postiz
docker compose up -d postiz
The service name and image name may differ in your environment. Verify the running image digest and application version after deployment rather than assuming that a successful container restart applied the intended release.
Patching alone is insufficient if attackers may already have obtained valid tokens. Rotate the application secrets used for sessions, invitations, password resets, and provisioning. If the application supports separate secrets, use independent values for each token purpose. Invalidate existing sessions and security-sensitive tokens, and require users to authenticate again.
Technical Notes
A practical remediation sequence is:
1. Record the currently deployed Postiz version and image digest.
2. Upgrade to v2.25.3 or later.
3. Restart all application instances and background workers.
4. Rotate token-signing and application secrets using the deployment secret manager.
5. Revoke sessions and outstanding password-reset, invitation, and provisioning tokens.
6. Review account, organization, and recovery activity.
7. Confirm the vulnerable routes no longer sign unrestricted request data.
If immediate upgrade is impossible, restrict access to Postiz behind an authenticated administrative network boundary, disable self-registration where supported, limit access to credential-refresh and invitation workflows, and apply strong monitoring to account recovery and organization changes. These are compensating controls, not substitutes for the fixed release.
Organizations should also verify that the patched implementation separates token purposes, constrains claims on the server, and prevents users from retrieving tokens intended for unrelated workflows. If a local fork retains the shared-secret design or vulnerable routes, upgrading the base version may not fully remediate the deployment.