CVE-2026-52767 in YesWiki
Summary
by MITRE • 09/05/2026
YesWiki is a wiki system written in PHP. From version 4.6.2 to before version 4.6.6, HttpSignatureService::verifySignature() checks the result of PHP's openssl_verify() with a loose boolean negation - if (!openssl_verify(...)) { throw ... }. PHP's openssl_verify has four possible return values: 1, 0, -1, and "false". The -1 row is the bypass: PHP's truthiness rules make -1 a truthy value, so !(-1) === false, the throw is skipped, and the controller proceeds to processActivity(). Any condition that makes OpenSSL's EVP_VerifyFinal() return -1 triggers the bypass. The reachable consequence is the controller silently treats a failed verification as success and processes the attacker's payload. This issue has been patched in version 4.6.6.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/05/2026
YesWiki, a wiki system implemented in PHP, contains a critical authentication bypass vulnerability within its HTTP signature verification mechanism affecting versions from 4.6.2 up to but not including 4.6.6. The flaw resides specifically in the HttpSignatureService::verifySignature() method, which is responsible for validating cryptographic signatures attached to incoming requests. This function relies on PHP's openssl_verify() extension to perform the actual cryptographic verification of the signature against a provided public key and message digest. However, the implementation fails to correctly interpret all possible return values from this underlying OpenSSL library call, leading to a logic error that allows attackers to bypass authentication checks entirely.
The technical root cause is a misuse of PHP's loose boolean negation operator in conjunction with openssl_verify(). The vulnerable code structure uses an if statement checking for a false condition using the logical NOT operator: if ((-1) evaluates to false because the negation of a truthy value is falsy. This logical inversion causes the conditional block that throws an exception or rejects the request to be skipped entirely.
As a result of this logic error, any condition that triggers OpenSSL's EVP_VerifyFinal() function to return -1 will cause the verification process to silently succeed from the perspective of the application logic. The controller then proceeds to execute the activity associated with the incoming HTTP request without confirming its authenticity or integrity. This effectively neutralizes the security mechanism intended to protect against unauthorized modifications and spoofing, allowing an attacker who can influence the input parameters or headers to craft malicious payloads that are accepted as legitimate by the server.
The operational impact of this vulnerability is severe, as it constitutes a complete authentication bypass for any endpoint protected by HTTP signature verification in affected versions. An attacker could potentially forge requests from trusted parties, modify wiki content without authorization, execute arbitrary actions on behalf of authenticated users, or escalate privileges if administrative functions rely on these signatures. This aligns with CWE-287, which describes Improper Authentication, and specifically relates to the failure to correctly validate credentials or security tokens. In terms of offensive security frameworks, this vulnerability facilitates techniques associated with ATT&CK T1078, Valid Accounts, by allowing unauthorized access through credential forgery rather than brute force or theft.
Mitigation for this issue requires an immediate upgrade to YesWiki version 4.6.6 or later, where the developers have corrected the boolean logic in the HttpSignatureService::verifySignature() method. The fix ensures that only a return value of 1 is treated as successful verification, while both 0 and -1 are correctly identified as failures requiring rejection of the request. Until an upgrade can be performed, administrators should consider implementing strict input validation at the web server level or using a Web Application Firewall to block requests with malformed cryptographic headers if such patterns are identifiable in traffic logs. Additionally, reviewing access logs for unusual activity during the window when vulnerable versions were in production is recommended to assess potential exposure and unauthorized modifications.