CVE-2026-78191 in WebDyne
Summary
by MITRE • 10/31/2026
WebDyne versions from 2.031 before 3.022 for Perl execute files with .psp anywhere in the name as Perl pages.
WebDyne decides whether to run a requested file as a page by matching its name against WEBDYNE_PSP_EXT_RE, which has no end anchor.
An application that accepts uploads by checking only the final extension lets a remote attacker upload a file such as report.psp.pdf and run its embedded Perl by requesting it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability in WebDyne versions ranging from 2.031 to just before 3.022 represents a critical misconfiguration within the web server's request handling logic, specifically concerning how dynamic script files are identified and executed. The core technical flaw stems from the regular expression pattern WEBDYNE_PSP_EXT_RE used by the application to determine if an incoming file should be processed as a Perl Server Page. This regex lacks an end anchor, meaning it matches any filename that contains .psp anywhere within its string rather than requiring it to be at the very end of the filename. Consequently, files with names such as report.psp.pdf are incorrectly identified and executed by the Perl interpreter instead of being served as static content or rejected based on their actual file type extension.
This architectural oversight creates a severe security risk known as unvalidated upload execution. In typical web application architectures, developers often rely solely on checking the final file extension to validate uploaded files against an allowlist of safe types like images or documents. When this validation is performed without considering how the server subsequently interprets that filename, attackers can bypass these controls by embedding a dangerous script extension within the filename itself. By uploading a file named report.psp.pdf, which might appear benign due to its .pdf suffix during upload verification, an attacker ensures that when they request this specific URL path, the WebDyne engine parses it as executable Perl code rather than a PDF document.
The operational impact of this vulnerability is significant, allowing for remote code execution with the privileges of the web server process. Once an attacker successfully uploads and triggers such a file, they can inject arbitrary Perl commands that interact directly with the underlying operating system or database backend managed by WebDyne. This capability enables attackers to exfiltrate sensitive data stored within the application's scope, modify configuration settings, install backdoors for persistent access, or pivot further into the internal network infrastructure depending on the server's connectivity and permissions. The lack of proper input validation regarding filename structure effectively neutralizes standard upload restrictions designed to prevent script injection attacks.
To mitigate this vulnerability, immediate remediation requires upgrading WebDyne to version 3.022 or later where this regular expression logic has been corrected to enforce strict end-of-string matching for file extensions. For environments that cannot immediately upgrade, a temporary mitigation involves configuring the web server's access control lists to explicitly deny execution of any files containing .psp anywhere in their path unless they are located within designated script directories with restricted permissions. Additionally, implementing stricter upload validation mechanisms that inspect both the MIME type and the full filename structure against a whitelist can help prevent such bypasses until the software patch is applied. This issue aligns with CWE-434 which describes the unrestricted uploading of files leading to code execution, as well as MITRE ATT&CK technique T1505.003 for Server Side Request Forgery or web shell deployment via uploaded content that exploits server misconfiguration rather than application logic flaws alone.