Patch
1/10 — A cryptographic signature check failed.
The application treated it as valid anyway.
CVE-2026-52767 is a high-severity YesWiki vulnerability caused by one dangerous assumption about the return value of "openssl_verify()".
2/10 — The vulnerable logic was effectively:
if (!openssl_verify(...)) {
throw new Exception("Signature verification failed");
}
At first glance, it looks correct.
The problem is that "openssl_verify()" does not return only true or false.
3/10 — PHP’s "openssl_verify()" may return:
1 → valid signature
0 → invalid signature
-1 → verification error
false → invalid arguments
The application used loose boolean negation instead of checking explicitly for "1".
4/10 — In PHP, "-1" is truthy.
Therefore:
!(-1) === false
The exception was skipped, even though verification had failed internally.
A failure state was silently converted into an authentication success.
5/10 — An attacker could trigger the error state by combining a DSA or EC public key with an RSA-only verification algorithm.
OpenSSL returned "-1", YesWiki accepted the request, and the ActivityPub payload continued to processing.
6/10 — No authenticated session, valid signature or user interaction was required.
On ActivityPub-enabled forms, an attacker could create, update or delete Bazar entries through a single unauthenticated request per operation.
7/10 — The practical impact included:
• content injection and defacement
• spam and SEO poisoning
• modification of federated content
• deletion of legitimate entries
• poisoning of federation state
8/10 — The root cause was not broken cryptography.
OpenSSL reported the verification result correctly.
The vulnerability existed because application logic collapsed several distinct return states into a simple truthy/falsy decision.
9/10 — A safer implementation would be:
$result = openssl_verify(...);
if ($result !== 1) {
throw new Exception("Signature verification failed");
}
Security-sensitive APIs must be checked against their exact documented success value.
10/10 — The broader AppSec lesson:
Never assume that “non-zero” means success.
For authentication, authorization and cryptographic checks, fail closed and handle every return state explicitly.
Affected: YesWiki 4.6.2–4.6.5
Fixed: 4.6.6
#AppSec #CyberSecurity
Post summary
The write‑up details CVE-2026-52767, a high‑severity YesWiki authentication flaw stemming from incorrect handling of openssl_verify return values, outlines its implications and confirms the issue is fixed in version 4.6.6.
