CVE-2026-104446 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an authentication bypass in the contact mail AJAX handler that allows unauthenticated attackers to send email through the wiki's SMTP server. Attackers can POST an XMLHttpRequest to the mail handler without field or type parameters, supplying arbitrary recipient, sender, subject and body for spam and phishing.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in YesWiki versions prior to 4.6.7 represents a critical authentication bypass within the application's contact mail AJAX handler. This flaw stems from an insufficient validation of input parameters during the processing of HTTP POST requests directed at the email sending endpoint. Specifically, the server-side logic fails to enforce mandatory field presence or type checking for essential components of the email transmission process. By omitting required fields such as specific form identifiers or security tokens that are typically associated with authenticated user sessions, an attacker can exploit this gap in access control mechanisms. The absence of these validation checks allows unauthenticated actors to interact directly with the mail handler without undergoing any form of authentication or authorization verification.
From a technical perspective, the exploitation vector involves crafting a malicious XMLHttpRequest via HTTP POST requests that target the vulnerable AJAX endpoint. Because the application does not strictly validate the structure and content of incoming data before processing it for email dispatch, attackers can supply arbitrary values for critical parameters including recipient addresses, sender identities, subject lines, and message bodies. This lack of input sanitization effectively turns the YesWiki instance into an open relay or a tool for automated spam distribution. The attacker bypasses standard security controls by manipulating the request payload to include valid SMTP configurations while omitting any credentials that would normally be required to prove legitimate user status.
The operational impact of this vulnerability is significant, primarily due to its potential for abuse in large-scale malicious campaigns. Unauthenticated attackers can leverage the compromised wiki server to send unsolicited bulk emails, commonly known as spam, which degrades the reputation of the associated IP address and domain. Furthermore, the ability to forge sender addresses facilitates sophisticated phishing attacks where messages appear to originate from trusted entities or internal sources within an organization. This capability undermines trust in digital communications and can lead to successful social engineering attempts against end-users who receive these deceptive emails. Additionally, excessive use of the SMTP server for such activities may result in resource exhaustion, potentially leading to denial-of-service conditions for legitimate users attempting to access wiki features that rely on email notifications or contact forms.
To mitigate this risk, immediate action is required by upgrading YesWiki to version 4.6.7 or later, where these authentication and validation checks have been properly implemented. In the interim, administrators should implement network-level controls such as web application firewalls (WAF) that can detect and block anomalous POST requests lacking expected parameters. It is also advisable to restrict direct access to AJAX endpoints through IP whitelisting if feasible, although this may not be practical for public-facing wikis. Regular monitoring of SMTP server logs for unusual spikes in outbound traffic or repeated failed authentication attempts can help identify ongoing exploitation activities early.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify the identity of a user prior to allowing access to sensitive functionality. It also relates to CWE-601, URL Redirection to Untrusted Site in an Error Page or Other Response, if the redirect logic is involved, but more accurately fits CWE-798 due to the use of hardcoded credentials or lack thereof in API endpoints, though primarily it is a case of missing access control. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1566.001, Phishing: Spearphishing Attachment, and T1566.002, Phishing: Spearphishing Link, as the primary outcome is the ability to send deceptive emails. The exploitation method also reflects aspects of T1190, Exploit Public-Facing Application, by targeting a web application interface that is accessible from external networks without proper authentication safeguards.