CVE-2026-116824 in YesWiki
Summary
by MITRE • 10/27/2026
YesWiki before 4.7.0 contains a stored cross-site scripting vulnerability in handlers/page/referrers_sites.php that allows unauthenticated attackers to inject scripts via crafted Referer headers. Attackers can send a Referer hostname containing HTML metacharacters that renders unescaped, executing JavaScript for any referrer-sites page visitor to perform same-origin authenticated actions.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in YesWiki versions prior to 4.7.0 represents a critical security flaw rooted in the improper handling of HTTP Referer headers within the application's backend logic. Specifically, the defect resides in the file handlers/page/referrers_sites.php, which is responsible for processing and displaying information about sites that have linked to or referenced the current page. This component fails to adequately sanitize user-supplied input derived from the HTTP Referer header before rendering it on a web page intended for site administrators or users with specific access levels. The vulnerability classifies as Stored Cross-Site Scripting, also known as Persistent XSS, because the malicious payload is not executed immediately upon request but is instead stored in the application's data store and subsequently served to other users during their normal interaction with the system.
From a technical perspective, the exploitation mechanism relies on the attacker crafting an HTTP Referer header that contains HTML metacharacters or executable JavaScript code rather than a standard URL hostname. When this crafted request reaches the YesWiki server, the application processes the referrer information and stores it without applying appropriate output encoding or escaping mechanisms. Consequently, when another user visits the page that displays these referrers, the browser interprets the stored content as active script code. This failure to enforce strict input validation and context-aware output encoding allows arbitrary JavaScript to execute within the security context of the victim's session. The flaw is particularly severe because it does not require any form of authentication or interaction from the attacker beyond sending a single crafted HTTP request, making it an unauthenticated attack vector that can be automated easily.
The operational impact of this vulnerability extends far beyond simple script execution. Because the injected scripts run in the same origin as the YesWiki application, they inherit all cookies and session tokens associated with the user's current login state. This enables attackers to perform authenticated actions on behalf of the victim without their knowledge or consent. Potential consequences include account takeover, where an attacker hijacks a legitimate user's session to gain unauthorized access; data exfiltration, where sensitive information displayed on the page is stolen and sent to an external server; and defacement, where the visual presentation of the site is altered maliciously. In environments where YesWiki serves as a collaborative platform or intranet tool, this could lead to significant social engineering attacks if attackers use the compromised session to send phishing messages to other users within the same organization.
This vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The specific nature of storing and later executing malicious scripts places it firmly in the persistent category rather than reflected XSS. Furthermore, from a tactical perspective related to the MITRE ATT&CK framework, this exploit maps to techniques involving Client-side Injection such as DOM-based or Stored XSS (T1059) and potentially Credential Access through Browser Session Hijacking if session tokens are stolen. The lack of authentication requirements for exploitation highlights a critical gap in input validation controls at the entry point of the application's data processing pipeline.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. For existing deployments, upgrading to YesWiki version 4.7.0 or later is the primary solution as it addresses this specific flaw by implementing proper sanitization routines for referrer data. In cases where an upgrade is not immediately feasible, administrators should implement a Web Application Firewall rule that inspects HTTP Referer headers and blocks requests containing suspicious characters such as angle brackets, quotes, or script tags before they reach the application logic. Additionally, developers must ensure that all dynamic content rendered to the browser undergoes rigorous context-aware encoding based on where it appears in the HTML structure, whether inside an attribute, a JavaScript block, or plain text body. Implementing Content Security Policy headers can also provide a layer of defense by restricting the sources from which scripts are allowed to execute, thereby mitigating the impact even if XSS is successfully injected.