YesWiki Unauthenticated SQL Injection in Form Import Handler

Vulnerability Description: The vulnerability exists in FormManager::create() at line 258, where the bn_id_nature POST parameter is concatenated directly into an SQL INSERT statement without quoting or parameterization. This is a classic first-order SQL injection in the VALUES clause. The root cause is unsafe string concatenation in database query construction. Impact is severe: attackers gain unrestricted SELECT/INSERT/UPDATE/DELETE capabilities, with immediate access to credential material in yeswiki_users table.

Proof-of-Concept Significance: The disclosed PoC validates exploitation against a dockerized default installation, proving the vulnerability is reliably exploitable with minimal setup. The attack requires zero authentication and can be triggered via POST to the Bazar form-import endpoint (/?BazaR&vue=formulaire). The PoC's success demonstrates that default configurations lack protective mechanisms (Web Application Firewall, input validation, parameterized queries).

Detection Guidance: Monitor HTTP POST requests to /?BazaR&vue=formulaire for suspicious bn_id_nature parameter values containing SQL metacharacters (quotes, parentheses, SQL keywords: UNION, SELECT, SLEEP, BENCHMARK, etc.). Log ingestion should flag requests with URL-encoded payloads like %27, --, /*, or comment sequences. Database query logs should capture malformed or high-cardinality INSERT statements. Web server access logs showing POST requests from non-admin IPs to this endpoint warrant immediate investigation.

Mitigation Steps:

1. Immediate: Upgrade YesWiki to a patched release once available; apply vendor security advisories.
2. Interim (High Priority): Implement input validation on bn_id_nature—whitelist alphanumeric characters and reject queries containing SQL metacharacters.
3. Code-Level Fix: Replace string concatenation with prepared statements using parameterized queries (e.g., ? placeholders with bound parameters).
4. Network Control: Restrict access to / endpoints containing BazaR to authenticated users only via WAF rules or reverse proxy authentication.
5. Hardening: Enforce principle of least privilege on the database user running INSERT queries; revoke SELECT on yeswiki_users if read access is not required for form imports.

Risk Assessment: This vulnerability presents extreme risk for public-facing YesWiki instances. Exploitation requires no credentials, no user interaction, and reliably yields full database compromise. Threat actors actively scan for YesWiki installations; once CVE details are public, automated exploitation will likely follow within hours. Legacy or unmaintained YesWiki deployments in the wild represent a high-probability target. Organizations running YesWiki should treat patching as emergency-priority work.