CVE-2026-93767 in Tainacan Plugin
Summary
by MITRE • 10/16/2026
The Tainacan plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 1.3.0 via the 'guid' parameter parameter. This makes it possible for authenticated attackers, with subscriber-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information. This vulnerability is exploitable only when the uploads/tainacan directory does not exist on the server, as this condition causes realpath() to return false, collapsing the base path to an empty string and rendering the containment check ineffective.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The Tainacan plugin for WordPress contains a critical Directory Traversal vulnerability affecting all versions up to 1.3.0. This flaw is located within the handling of the guid parameter, which allows authenticated attackers with subscriber-level access or higher to read arbitrary files from the server's filesystem. The security issue stems from an improper validation mechanism that fails to correctly sanitize user-supplied input before using it in file system operations. By manipulating this parameter, an attacker can bypass intended restrictions and access sensitive data stored on the web server, potentially leading to further compromise of the WordPress installation or underlying infrastructure.
The technical root cause of this vulnerability lies in a flawed implementation of path normalization logic involving the PHP realpath function. Under normal circumstances, developers use realpath() to resolve symbolic links and relative paths into absolute paths, ensuring that file access remains within an expected directory boundary. However, in this specific scenario, if the uploads/tainacan directory does not exist on the server, the realpath() call returns false instead of a valid path string. This return value causes subsequent logic to collapse the base path variable to an empty string. Consequently, when the application performs its containment check to verify that the requested file resides within the allowed upload directory, it compares against this empty or nullified baseline, effectively rendering the security control ineffective and allowing traversal outside of restricted areas.
From a classification perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as the application fails to restrict file access to intended directories. Additionally, it relates to CWE-732: Incorrect Permission Assignment for Critical Resource due to the reliance on directory existence rather than robust path validation logic. In terms of offensive security frameworks, this exploit maps to ATT&CK technique T1083: File and Directory Discovery, where an adversary uses file traversal techniques to enumerate sensitive files within a compromised environment. The vulnerability is particularly dangerous because it requires only low-privilege authentication, meaning that any registered user can potentially leverage it without needing administrative rights or complex exploitation chains.
The operational impact of this flaw extends beyond simple data leakage. Accessing arbitrary server files may expose configuration files containing database credentials, API keys, and other secrets essential for the application's operation. It could also allow attackers to read source code from plugins or themes, facilitating further reverse engineering and identification of additional vulnerabilities. In severe cases, if combined with other weaknesses such as insecure file uploads or deserialization flaws, this traversal capability could serve as a stepping stone toward remote code execution. The dependency on the non-existence of a specific directory adds an element of environmental specificity, meaning that while many installations may be unaffected due to proper setup practices, any instance missing this default structure is immediately vulnerable upon authentication.
Mitigation strategies should focus on immediate patching and defensive coding improvements. Administrators running affected versions must upgrade Tainacan to version 1.3.1 or later, where the developers have addressed the path validation logic. For environments that cannot be patched immediately, ensuring that the uploads/tainacan directory exists can serve as a temporary workaround by preventing the realpath() function from returning false and collapsing the base path. However, this is not a robust long-term solution because it relies on server configuration rather than code-level fixes. Developers should implement strict input validation using functions like basename() to strip directory components before processing paths, or utilize realpath() with explicit fallbacks that reject requests if the resolved path does not start with the expected base directory prefix. Regular security audits and static analysis tools can help identify similar patterns in custom WordPress plugins to prevent recurrence of such logic errors.