External risk intelligence

Wiki.js JWT Logout Token Replay Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2025-56643

Wiki.js is a web-based documentation platform typically deployed as a public-facing or organization-wide web application. Given its primary function as an accessible wiki, the authentication and session management endpoints are commonly exposed to the network to facilitate user access, making the GraphQL and authentication services likely to be reachable in standard web deployments.

Requarks Wiki Js

2.5.307

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory details a security vulnerability in Wiki.js where active user tokens are not properly invalidated after logout, potentially allowing unauthorized access to the system. The issue lies within the authentication logic, impacting both the GraphQL endpoint and the logout process, and could compromise session integrity.

Logged-out users may still access the system.
Confirms improper handling of user session security.
Verify relevance to internal Wiki.js deployments.

Attack Path

How an attacker could exploit the issue

An attacker could gain unauthorized access to Wiki.js by exploiting a flaw in how active login tokens are handled. Even after a user logs out, existing tokens might still be valid, allowing an attacker to reuse a compromised token to access the system. This vulnerability impacts the system's session integrity and authentication process.

No initial access needed.
Reuse of valid, logged-out tokens.
Unauthorized access to system data.

Live Threat

Current exploitation, exposure, and threat context

When JWT tokens are not properly revoked after a user logs out of Wiki.js, previously issued tokens remain valid. This compromised session integrity could allow unauthorized access to the system if an attacker obtains a valid token.

Unauthorized access to wiki data.
Reused tokens bypass logout security.
Compromised session integrity.

Operational Fix

Recommended remediation, mitigation, and detection steps

The requarks wiki.js authentication resolver is susceptible to JWT token reuse after logout, potentially allowing unauthorized access. Technical leaders and security teams must first identify all instances of requarks wiki.js, determine their exposure, and confirm their business criticality. Subsequently, accountable owners should be identified to plan remediation, prioritizing systems that are publicly accessible or handle sensitive information.

Platform teams likely own this issue.
Verify system exposure and asset owners.
Plan remediation based on risk assessment.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Requarks Wiki.js?

Wiki.js is a popular, open-source web application designed for knowledge management and team documentation. It typically runs as a centralized hub where organizations host internal or public-facing wikis. Because it serves as a content platform, it relies on authentication mechanisms, such as JSON Web Tokens (JWT), to manage user sessions and control access to the information stored within the platform.

What does CWE-613 mean for CVE-2025-56643?

CWE-613 identifies an Insufficient Session Expiration weakness. In the context of this CVE, it means that while the application provides a logout function, it fails to perform the backend cleanup required to kill the session. Even after a user clicks logout, the server does not mark their previously issued JWT as invalid, allowing that specific token to continue granting access to the system as if the user were still logged in.

How can an attacker trigger this token reuse flaw?

An attacker does not need special preconditions or an initial exploit to trigger this; they simply need a JWT that was previously issued to a user. If a user logs out, but the token is captured or remains in browser storage, that token remains active. Note that this flaw is specific to the handling of existing tokens; simply navigating to the login page without a valid, previously generated token will not trigger this specific session integrity bypass.

Is my Wiki.js instance at risk?

According to Halo Surface Signal, Wiki.js is typically deployed as a web-accessible application, making its authentication and GraphQL endpoints common targets. If your instance is exposed to the network, the risk is higher because tokens are more reachable. Even for internal-only deployments, you should evaluate the risk based on the sensitivity of the documentation hosted and the likelihood of token interception on your network.

What steps should I take if I run Wiki.js?

Start by identifying all deployed instances of Wiki.js within your environment to establish an inventory. Once you have a list, determine which instances are internet-facing versus internal, as these represent your highest priority for risk mitigation. Work with the designated system owners to assess the business impact of potential unauthorized access and prepare for software updates as they become available from the vendor.

References

github.com/0xBS0D27/CVE-2025-56643

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.