The vulnerability arises from improper handling of the openssl_verify() return value in YesWiki's HttpSignatureService::verifySignature() method. The code uses if (!openssl_verify(...)) to detect signature verification failure. However, openssl_verify() can return four values: 1 (valid), 0 (invalid), -1 (internal error), and false (argument validation failure). The check incorrectly treats -1 as a successful verification due to PHP's truthiness rules, skipping the exception throw. An attacker can exploit this by providing a DSA public key with an RSA-SHA256 algorithm, causing openssl_verify() to return -1 and bypass signature verification. The attacker can then send unauthenticated POST requests to the actor inbox endpoint, which YesWiki processes, allowing unauthorized state mutations. This affects YesWiki versions >=4.6.2 and <4.6.6.

The vulnerability allows unauthenticated attackers to bypass signature verification and submit malicious ActivityPub requests to YesWiki's actor inbox endpoint. This can lead to unauthorized creation, update, or deletion of entries within the application, compromising data integrity. There is no requirement for a valid session or CSRF token, making exploitation straightforward once the attacker controls an actor document with a crafted public key. The digest header is enforced but easily satisfied by the attacker. The impact is high due to the ability to perform unauthorized state changes without authentication.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, users should consider mitigating by avoiding use of PHP 8.3 with OpenSSL 3.x in affected YesWiki versions or by implementing stricter signature verification logic that correctly handles the -1 return value from openssl_verify(). Specifically, the code should explicitly check for the -1 return and treat it as a verification failure. Monitor vendor channels for an official patch and apply it promptly once released.