CVE-2026-104467 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an authorization bypass vulnerability in ApiService::isAuthorized() that allows unauthenticated attackers to call admin-only API routes when public API mode is enabled. Attackers can send requests to endpoints like api/ci/update_config and api/archives to overwrite configuration and list, download, or delete backup archives.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical authorization bypass within the ApiService::isAuthorized() method. This flaw specifically impacts systems where public API mode is enabled, creating a scenario where authentication checks are effectively circumvented for administrative endpoints. The root cause lies in the logic governing access control for API routes, which fails to properly validate user privileges when operating under specific configuration states. Consequently, unauthenticated actors can interact with functions that are intended to be restricted to administrators only, undermining the fundamental security principle of least privilege and allowing external parties to execute privileged operations without valid credentials.
From a technical perspective, the defect resides in how the application determines authorization status for API requests. When public mode is active, the system appears to relax or incorrectly implement access control checks, permitting direct invocation of administrative methods such as api/ci/update_config and api/archives. The update_config endpoint allows attackers to modify core configuration parameters, potentially altering security settings, database connections, or other critical application behaviors. Meanwhile, the archives endpoint exposes functionality that permits listing, downloading, and deleting backup files. This exposure is particularly dangerous because backups often contain sensitive data including user information, content history, and system configurations, making them high-value targets for adversaries seeking to exfiltrate data or disrupt service availability through deletion.
The operational impact of this vulnerability is severe due to the breadth of actions an attacker can perform without authentication. By manipulating configuration files via the update_config endpoint, an adversary could potentially disable security features, inject malicious code into system settings, or redirect traffic to external servers for phishing or malware distribution. Furthermore, access to backup archives enables data exfiltration on a large scale, as these archives typically represent comprehensive snapshots of the wiki's state at various points in time. The ability to delete backups also introduces significant availability risks, removing critical recovery options and complicating incident response efforts if an attack occurs. This combination of confidentiality, integrity, and availability impacts elevates the severity of the issue beyond a simple access control flaw.
In terms of industry classification standards, this vulnerability aligns with CWE-284 Improper Access Control, as it involves unauthorized actors gaining privileges they should not possess. It also maps to MITRE ATT&CK technique T1078 Valid Accounts if an attacker were to use stolen credentials, but in the context of unauthenticated access via a logic flaw, it reflects aspects of privilege escalation and exploitation of application configuration errors. The specific actions taken by attackers, such as modifying configurations or accessing backups, correspond to techniques like Configuration Change (T1562) and Data from Information Repositories (T1005), highlighting the multifaceted nature of the threat posed by this single code defect.
To mitigate this vulnerability, organizations running YesWiki must immediately upgrade to version 4.6.7 or later where the authorization logic in ApiService::isAuthorized() has been corrected to properly enforce access controls regardless of public API mode settings. Until an upgrade is feasible, administrators should disable public API mode entirely if it is not strictly required for legitimate operations. Additionally, implementing network-level restrictions such as firewall rules that limit access to API endpoints to trusted IP addresses can provide a layer of defense in depth. Regular auditing of configuration files and backup integrity checks are also recommended to detect any unauthorized modifications or deletions that may have occurred prior to remediation. Monitoring logs for unusual activity on administrative routes will aid in identifying potential exploitation attempts during the transition period.