YesWiki 4.5.1 - Unauthenticated Path Traversal

YesWiki < 4.5.2 — Unauthenticated Path Traversal (CVE-2025-31131)

This article explains the path traversal (local file inclusion style) vulnerability reported in YesWiki prior to version 4.5.2 (CVE-2025-31131). It covers impact, detection, mitigation, safe coding patterns to prevent recurrence, and operational hardening advice for administrators and developers.

Quick facts

Product	YesWiki
Affected versions	All releases prior to 4.5.2
CVE	CVE-2025-31131
Vulnerability type	Unauthenticated path traversal / LFI
CVSS v3.1	8.6 (High) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Vendor	https://yeswiki.net/

What the vulnerability is

A path traversal vulnerability lets an attacker influence a file path used by the application to access resources on disk. When user-supplied input is used to determine which file to load without proper validation or canonicalization, an attacker can request files outside the intended directory (for example system files or application source files). In this YesWiki issue the vulnerability is reachable without authentication, increasing the severity because remote attackers can attempt to read files directly.

Potential impact

• Disclosure of sensitive files (for example /etc/passwd, configuration files with credentials, private keys if accessible).
• Leakage of application source code or other internal artifacts that could aid further attacks.
• In multi-tenant or privileged environments, total compromise or privilege escalation may follow if secret material is exposed.

Detection and indicators

Detection involves both proactive scanning and retrospective log analysis. Look for abnormal access patterns targeting templates or rendering endpoints and for accesses that include unusual characters or request parameters intended to alter file paths.

• Search web server or application logs for requests that include template-related parameters (for example look for requests that contain the parameter name used by the application). Example safe pattern to search logs: search for accesses where the template-selection parameter is present.
• Monitor for unexpected 200 responses on endpoints that normally return HTML when requests should yield an error.
• Inspect unexpected responses for fragments typical of system files (for example OS user account listings or configuration file syntax).

Immediate mitigation (what to do now)

• Upgrade: Apply the vendor fix by upgrading YesWiki to version 4.5.2 or later. This is the primary and recommended remediation.
• Application-level mitigations until upgrade: disable or restrict access to any endpoints that accept template/file selection parameters from unauthenticated users.
• WAF rules: deploy a web application firewall rule to block requests attempting to traverse directories (requests containing suspicious path segments) or to block the vulnerable endpoint entirely if permissible.
• Least privilege: ensure the web server process and application run with minimal filesystem privileges and cannot read sensitive files (use filesystem ACLs and ownership to restrict access to sensitive paths).

Secure coding patterns to prevent path traversal

The safest approach to prevent path traversal is to avoid using raw user input to form filesystem paths. Use allowlists (catalogs of permitted templates), canonicalization checks, and filesystem APIs designed to resolve and verify paths.

// Example (PHP): safe template resolution using allowlist + canonicalization
$allowed_templates = [
  'default' => '/srv/yeswiki/templates/default.html',
  'margot'  => '/srv/yeswiki/templates/margot.html',
];

$param = $_GET['squelette'] ?? '';
if (!isset($allowed_templates[$param])) {
  // deny or fallback to a safe default
  http_response_code(404);
  exit;
}

$template_path = $allowed_templates[$param];
// include or render $template_path securely
$content = file_get_contents($template_path);
echo $content;

Explanation: This PHP example avoids constructing filesystem paths from user input. Instead it maps a small set of allowed logical names to absolute template files and refuses any unknown values. This is the recommended pattern — prefer allowlists over blacklists.

// Alternative (language-agnostic): canonicalize + base directory check
base_dir = "/srv/yeswiki/templates"
user_choice = get_request_param("template")  // do not use directly
candidate = join_paths(base_dir, user_choice)
canonical = canonicalize(candidate)          // equivalent to realpath()
if not canonical.startswith(canonicalize(base_dir) + "/"):
    deny_request()
else:
    serve_file(canonical)

Explanation: This pseudo-code shows canonicalization: join the base directory with the user-provided fragment, compute the canonical (resolved) path, and verify the resolved path begins with the expected base directory. This prevents traversal attempts that use ../ or symlink tricks to escape the base directory.

Runtime and infrastructure hardening

• Filesystem permissions: Ensure sensitive files (configurations, private keys) are owned by a dedicated user and not readable by the web server user.
• Containerization or chroot: Run the application in an environment where the application’s view of the filesystem is constrained to only the resources it needs.
• Disable unsafe features: If the application offers anonymous template editing or file-selection features, restrict those features to authenticated, authorized users only.
• Log and monitor: Enable detailed access logs for endpoints that control file access, and set alerts for anomalous volumes of requests or unexpected 200 responses.

Detection signatures for defenders (conceptual)

Defensive signatures can be used in IDS/WAF systems to flag attempts to manipulate filesystem paths or to access template-selection endpoints anomalously. Use these signatures cautiously and tune to avoid false positives.

• Block or alert on requests containing directory traversal sequences in path components — treat this as suspicious input to template or include parameters.
• Alert on unexpected 200 responses from endpoints that typically render templates when parameters were previously absent or default.
• Instrument the application to log rejected template requests and to record source IP, parameter values (sanitized), and response codes for forensic analysis.

Forensic steps after suspected exploitation

• Preserve logs (web server, application, system) immediately and capture a timeline of events.
• Search logs for requests to the vulnerable endpoints or for template selection parameters around the time of suspected activity.
• Check for read access to sensitive files, and confirm whether any secrets were exposed. Rotate credentials and keys that may have been leaked.
• Rebuild or restore compromised components from a known-good baseline and remediate the vulnerability before returning services to production.

Responsible disclosure and timeline

If you discover a vulnerability in YesWiki or any other project:

• Report it privately to the vendor or maintainer with reproducible details and any logs you can share; avoid publishing exploit payloads publicly before a fix is available.
• Coordinate on a patch timeline and public disclosure that gives administrators a reasonable window to update.
• When publishing advisories, include mitigation steps, CVE references, and links to vendor updates.

References and follow-up

• YesWiki project home: https://yeswiki.net/
• YesWiki source and releases: https://github.com/YesWiki/yeswiki
• Official advisory: apply YesWiki 4.5.2 or later (verify vendor release notes for the exact fix and any backports).

Summary

CVE-2025-31131 is a high-severity unauthenticated path traversal issue affecting YesWiki versions before 4.5.2. The primary remediation is to upgrade to 4.5.2 or later. Administrators should apply the vendor patch, harden runtime permissions, and use defensive controls (WAF, monitoring, allowlists) to reduce risk. Developers should adopt allowlist-based template selection and canonicalization checks to prevent similar vulnerabilities in future releases.