YesWiki CVE-2026-116826

Requires an authenticated YesWiki administrator account: both a route-level ACL (@admins) and an in-method denyAccessUnlessAdmin() check at ApiController.php:596 are enforced, and the GHSA confirms the public-API-mode bypass does not reach this route. The duplication API (/api/pages/{tag}/duplicate) is enabled by default. The attacker must control the files[] array in the POST body (trivially satisfiable alongside the required originalContent, sourceUrl, originalTag, type keys). For secret exfiltration the files/ directory must be web-accessible, which is the default layout. The practical limiting factor is the admin-privilege requirement (robustly enforced by two independent checks); there is no additional non-default configuration, user interaction, or platform-specific requirement beyond having PHP curl support for the file:// scheme.

Signals are consistent and point to a genuine but privilege-gated issue rather than a mass-exploitation emergency. The CVSS 4.0 base score of 8.2 (High) is driven by network vector, low complexity, no user interaction, and a scope/subsequent-system confidentiality impact (SC:H) - the latter because fetched responses land in the publicly readable files/ directory, so secrets (wakka.config.php DB credentials, cloud IAM metadata, /etc/passwd) become readable by any unauthenticated visitor. The critical tempering factor is PR:H: exploitation requires an authenticated administrator, robustly enforced by two independent checks (route ACL @admins plus in-method denyAccessUnlessAdmin()), and the GHSA confirms the public-API-mode bypass (GHSA-v527-6r4j-j2w2) does NOT reach this route. The other intelligence signals corroborate low urgency: EPSS is 0.24% (15th percentile), the SSVC decision is Exploitation=none / Automatable=no / Technical Impact=partial, and the vulnerability is NOT in CISA KEV - exploitation status is 'no public exploit identified at time of analysis' beyond the advisory PoC. The vuln.today priority of 'this_week' aligns with that: a credible, detailed advisory with a working proof-of-concept warrants prompt patching, but the admin-only precondition and absence of automatability make widespread opportunistic exploitation unlikely. CONFLICTING DATA TO VERIFY: the description, EUVD, and Packagist footer state the fix is 4.7.0 ('fixed in: 4.7.0') and patch is 'Available from vendor', yet the GHSA advisory body states 'Fix status: not fixed', 'No fix exists on any branch', and lists the latest checked release as v4.6.7 - defenders should independently confirm that 4.7.0 actually exists and contains the SsrfUrlValidator::curlPin() fix before relying on it.

An attacker who has obtained or been granted a YesWiki administrator account (e.g. via a compromised admin credential or a malicious/over-privileged internal user) POSTs to the default-enabled /api/pages/{tag}/duplicate endpoint with file:// or internal URLs placed in the files[] array. Because downloadFile() passes these URLs straight to curl_init() with CURLPROTO_ALL and no SSRF validation, the server reads local files or cloud metadata and streams the response into the web-accessible files/ directory under a predictable name. A detailed proof-of-concept with working curl commands is published in the GHSA advisory, so the attacker then simply fetches https://target/files/wakka.config.php or /files/meta-data to retrieve database credentials or IAM tokens.