CVE-2026-104467: YesWiki protects its administrator API with a check that never runs
Small publishing platforms sit in an awkward security position. They hold real content and real credentials, they are maintained by a handful of volunteers, and their administrator interfaces are exposed to the internet because they are also the editing interface. CVE-2026-104467 in YesWiki below 4.6.7 is a case study.
The flaw in the authorization layer
The vulnerable function is ApiService::isAuthorized(). When the wiki runs in public API mode, the authorization routine fails to enforce the access it is meant to enforce. An unauthenticated attacker can then call administrator API routes.
The consequence is not limited to reading. The disclosure states that the attacker can rewrite configuration, list backup archives, download them, and delete them.
That list is more serious than it first appears. A configuration rewrite on a wiki changes what code runs and where it reads from. An attacker who can list and download backups is holding an archive of the entire site, including any secrets the wiki held. Deleting the backups afterwards removes the operator's ability to restore.
Why "public API mode" is the risky configuration
Public API mode exists to let external tools read the wiki without a session. That is a reasonable feature, and the risk is in how it is scoped. When the same routing layer serves both public read endpoints and administrator write endpoints, the authorization decision has to be precise about which is which.
The failure mode here is a check that returns a permissive result in the configuration where it should be strictest. From a testing standpoint, the gap is easy to find: enable public API mode, then call an administrator endpoint without a session and see whether it answers.
What to do
Upgrade to YesWiki 4.6.7 or later, then confirm the running version from the application's own status page rather than the directory listing.
If the wiki was internet-reachable in public API mode, treat the content and the backups as exposed. Because the API can delete archives, verify that your own off-host backup copy still exists before you start remediation. A wiki whose only backup lived on the wiki is a data loss incident, not just a breach.
Rotate every credential the wiki configuration holds: database user, mail relay, any single-sign-on client secret. Configuration changes made through the bypass may have introduced a new data source or a modified secret, and a rotation covers both possibilities.
Review the web server access log for requests to the API routes that did not carry a session cookie. That is the signature of the bypass and it produces a list of source addresses to investigate.
Finally, consider turning public API mode off unless it is actively used. A feature that is not needed is pure attack surface.
Top comments (0)