Description

openssl_encrypt (pip: openssl-encrypt) versions before 1.4.9 contain a path traversal flaw in PluginSandbox._is_safe_path, which authorized file access using a bare string-prefix match. A sandboxed plugin without the READ_FILES permission could read or write another plugin's directory that merely shares a name prefix (e.g., .../plugins/foobar matching allowed .../plugins/foo), breaking per-plugin isolation within the same user. Fixed by matching each allowed directory exactly or with a trailing path separator.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.2",
  "pubDate": "2026-08-27T17:21:01.877Z",
  "pubdate": "2026-08-27T17:21:01.877Z",
  "executiveSummary": "The openssl-encrypt package for Python, in versions prior to 1.4.9, is susceptible to a path traversal vulnerability originating from flawed directory validation logic within the PluginSandbox._is_safe_path function.\nThe vulnerability type is categorized as an improper path validation flaw, which breaks the security isolation model between plugins.\nAn attacker controlling a sandboxed plugin with restricted permissions can bypass sandbox constraints to read or write files within the directories of other plugins.\nThis occurs because the affected component utilizes a loose string-prefix comparison for file path validation, enabling unauthorized cross-directory access.\nThe risk implication is a significant breach of multi-tenant plugin isolation, potentially allowing unauthorized data access, code injection, or configuration tampering.\nExploitation requires the attacker to possess control over a sandboxed plugin within the affected environment; no external network access is strictly required if the plugin mechanism is locally exploitable.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the PluginSandbox._is_safe_path function, which is intended to enforce sandbox isolation by ensuring that plugins only access their designated directories.\nThe logic employed for path verification used a simplistic string-prefix match. By performing a bare prefix comparison, the sandbox engine fails to account for directory boundary characters.\nSpecifically, the check validates if a requested path starts with the authorized base path string. Because this check does not enforce a trailing path separator, any directory name that shares a common prefix with an authorized directory will be incorrectly flagged as 'safe'.\nFor example, if an authorized plugin path is defined as '.../plugins/foo', the vulnerable logic incorrectly validates paths such as '.../plugins/foobar'.\nThe exploitation flow proceeds as follows: 1) An attacker identifies a target plugin directory that shares a common path prefix with their own sandboxed plugin. 2) The attacker crafts a file path traversal payload that leverages this prefix ambiguity. 3) The PluginSandbox._is_safe_path function performs the prefix match, perceives the malicious path as residing within the authorized boundary, and grants filesystem access. 4) The sandboxed process executes read or write operations against the unauthorized plugin directory.\nThis vulnerability effectively circumvents the READ_FILES permission constraints imposed by the plugin system. The impact is critical within environments relying on plugin isolation for multi-user security or multi-application resource separation.\nThe affected component is the PluginSandbox class within the openssl-encrypt package, affecting all versions prior to 1.4.9. The vulnerability does not require authentication beyond the ability to run or manipulate a plugin within the sandbox environment.\nPost-exploitation, an attacker can manipulate sensitive plugin files, extract credentials, inject malicious logic into other plugins, or cause a denial of service by corrupting the files of adjacent plugins sharing the same host environment."
}