CVE-2026-78189 in WebDyne
Summary
by MITRE • 10/31/2026
WebDyne versions from 3.007 before 3.022 for Perl execute .psp files outside the document root via path traversal in the PSGI API route fallback.
When a request matches no file, the PSGI handler retries it as an API route through api_filename. That keeps .. segments in the request path and only checks that the joined path starts with the document root, which a request for /../private passes.
A remote attacker can run the embedded Perl in any .psp file the server can read, such as one uploaded to a directory outside the document root.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability identified in WebDyne versions ranging from 3.007 up to but not including 3.022 represents a critical path traversal flaw within its PSGI API route fallback mechanism. This issue stems from an insufficient validation of user-supplied input when the web server attempts to resolve requests that do not correspond directly to existing files on disk. In standard web application architectures, if a requested resource is not found as a static file, the request is often passed to a backend framework or handler for dynamic processing. WebDyne employs such a mechanism where unmatched requests are retried through an API route defined by the api_filename configuration. However, this fallback logic fails to sanitize the input path before joining it with the document root directory. Specifically, the implementation retains relative path traversal sequences, commonly known as dot-dot-slash or .. segments, within the request URI during this resolution process.
The technical core of the flaw lies in the validation logic used by the PSGI handler. When constructing the final file system path to execute a Perl Server Page (.psp) script, the application checks only whether the resulting joined path begins with the configured document root string. This check is superficial and easily bypassed using standard directory traversal techniques. For instance, if an attacker submits a request containing /../private/secret.psp, the server joins this with the document root, such as /var/www/html. The resulting path becomes /var/www/html/../private/secret.psp. While many file system operations normalize paths and resolve these sequences to prevent access outside the intended directory, WebDyne's specific implementation or underlying Perl libraries may not perform adequate canonicalization before executing the script. Consequently, a request for /../private passes this basic prefix check because the normalized path might still technically start with the root if the logic is flawed, or more likely, the application fails to resolve the .. segments entirely and uses them literally in subsequent file operations that do not enforce strict containment.
This architectural weakness allows a remote attacker to execute arbitrary .psp files located anywhere on the server's file system where the web server process has read permissions. The impact is severe because .psp files are Perl scripts embedded with HTML, meaning they can contain complex logic and direct access to system resources. By targeting files uploaded or stored outside the document root, such as configuration backups, database credentials, or other sensitive data that might be inadvertently placed in accessible directories, an attacker gains the ability to run code within the context of the web server process. This effectively results in remote code execution (RCE), granting the attacker full control over the underlying Perl environment and potentially leading to complete compromise of the host system.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements that can cause paths to transition outside of restricted directories. Furthermore, in terms of offensive security frameworks like MITRE ATT&CK, this behavior is indicative of T1059: Command and Scripting Interpreter, specifically through the execution of Perl scripts via path traversal techniques often categorized under initial access or privilege escalation vectors depending on the context. The failure to validate input against directory boundaries before processing represents a classic example of insecure direct object references combined with path manipulation errors.
Mitigation for this vulnerability requires an immediate upgrade to WebDyne version 3.022 or later, where the developers have presumably corrected the logic in the PSGI API route fallback. In environments where upgrading is not immediately feasible, administrators should implement strict input validation at a reverse proxy level before requests reach the application server. This includes rejecting any HTTP request that contains .. sequences within the URI path. Additionally, ensuring that the web server process runs with minimal privileges and adhering to the principle of least privilege can limit the damage if an exploitation attempt occurs. It is also critical to audit file storage practices to ensure no sensitive .psp files or other executable scripts are stored in directories accessible by the web server outside of the designated document root, thereby removing the attack surface entirely even if the software flaw persists.