CVE-2026-118988 in CallBackery
Summary
by MITRE • 10/30/2026
CallBackery versions before 0.60.1 for Perl let unauthenticated clients read the POD of any file via path traversal in the /doc route.
Every CallBackery application mounts its documentation plugin at /doc, ahead of any session check. The route passes the requested name to Pod::Simple::Search->find without validation. find splits the name on "::" and joins the parts into a file path, so a name such as "..::..::..::etc::motd" escapes @INC.
Any file the server process can read is reachable. Only POD is rendered, but a file with a POD directive and no "=cut" is POD to the end of the file.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in CallBackery versions prior to 0.60.1 represents a critical path traversal flaw within the application's documentation serving mechanism. This security issue stems from an improper validation of user-supplied input passed through the /doc route, which is designed to serve Perl POD (Plain Old Documentation) files. The core technical failure lies in how the application processes file names before passing them to the Pod::Simple::Search->find method. Instead of sanitizing or restricting the input to valid module identifiers, the system allows arbitrary strings containing directory traversal sequences such as ".." and "::". Because Perl modules are typically separated by double colons (::), which correspond to forward slashes (/) in file paths on most operating systems, an attacker can manipulate this delimiter structure to navigate up the directory hierarchy. By constructing a request with a name like "..::..::..::etc::motd", the application resolves these sequences into parent directories, effectively bypassing any intended scope restrictions and allowing access to files outside of the designated documentation root.
The operational impact of this vulnerability is significant because it enables unauthenticated remote attackers to read arbitrary files on the server's file system that are accessible by the user account running the CallBackery process. Although the application intends to render only POD content, a clever exploitation technique allows for the exfiltration of sensitive data even from non-POD files. This is possible because Perl interprets any text following a POD directive as documentation until it encounters an explicit "=cut" command. If a target file contains at least one valid POD start marker but lacks a corresponding end marker, the entire remainder of that file is treated as POD and rendered to the attacker's browser. Consequently, configuration files containing database credentials, private keys, environment variables, or other sensitive system information can be disclosed if they happen to contain such markers. This effectively turns what appears to be a documentation viewer into a powerful arbitrary file read tool.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal or directory traversal. The lack of input validation on the filename parameter directly facilitates unauthorized access to restricted resources. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is consistent with techniques used for Data from Local System Retrieval, specifically under Tactic TA0009: Collection and Technique T1083: File and Directory Discovery. The attacker leverages the application's legitimate functionality to enumerate and extract sensitive data without needing valid credentials or exploiting a separate authentication bypass flaw, as the documentation route is mounted before session checks are enforced.
To mitigate this vulnerability, immediate action should be taken by upgrading CallBackery to version 0.60.1 or later, where the path traversal issue has been addressed through proper input sanitization and validation. For organizations unable to upgrade immediately, a temporary mitigation involves configuring the web server or reverse proxy in front of the application to block requests containing directory traversal sequences such as ".." within the /doc route parameters. Additionally, ensuring that sensitive files do not contain POD start markers can reduce the risk of data exfiltration via this specific vector, although upgrading remains the only definitive solution. Regular security audits and static code analysis should be employed to detect similar input validation weaknesses in other routes or plugins where file paths are constructed from user-supplied data.