Wiki.js CVE-2026-92776

Requires a valid authenticated Wiki.js account (PR:L) that has been granted access to at least one folder via a page permission rule; the target unauthorized pages must share a literal path prefix with an authorized folder path (e.g. access to '/docs' exposing '/docs-internal'). No user interaction and no special server configuration are needed - the flawed prefix matching in the START/END page-rule engine is default behavior in all versions through 2.5.314. The primary limiting factor is that the attacker must already hold an account with some folder grant, so purely anonymous/unauthenticated users cannot exploit it.

This is a genuine authorization bypass (CWE-863) with meaningful risk despite requiring authentication. The vendor CVSS 4.0 vector (8.6, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) is internally consistent with the description: a low-privileged authenticated user who has been granted access to any folder can read and modify unrelated pages that merely share a literal path prefix, because the rule engine matches START/END rules without enforcing path-segment boundaries. VC:H/VI:H are justified (arbitrary read and write of unauthorized wiki content), while VA:N is correct since availability is unaffected. Publicly available exploit code exists (documented by VulnCheck / geo-chen writeup), which raises practical risk, but there is no CISA KEV listing and no EPSS score provided, so this reflects a disclosed-and-documented flaw rather than confirmed mass exploitation. The PR:L requirement is the key limiter - an attacker needs a valid Wiki.js account with at least some folder grant - so this is primarily a privilege-escalation / lateral-access issue within an already-authenticated user base rather than a remote-unauthenticated compromise. Note the input Tag 'Authentication Bypass' is inaccurate: CWE-863 and the described behavior are an authorization (access-control) failure, not authentication bypass.

An authenticated Wiki.js user who is legitimately granted access to a folder such as '/team' discovers that the permission engine also matches '/team-secret' or '/teamwork' because it only checks for a literal string prefix, not a path-segment boundary. Using the publicly available exploit technique, the user reads and edits sensitive pages in those sibling paths that they were never authorized to touch. Exploitation is low-complexity over the network but requires a valid low-privilege account.