openssl-encrypt EUVD-2026-67066

Exploitation requires all of the following to be true simultaneously: the target system runs openssl-encrypt in a version before 1.4.9 with the plugin sandbox active; the attacker controls or can install a sandboxed plugin within the system; and a co-located plugin exists whose directory name begins with the attacker-controlled plugin's directory name as a literal string prefix (e.g., attacker in .../plugins/foo, target in .../plugins/foobar). Without a sibling plugin sharing a name prefix, no path confusion occurs and exploitation is not possible. The attacking plugin does not require READ_FILES permission - the flaw exists precisely because the permission check is bypassed via the prefix match. Exploitation is limited to the same-user plugin isolation boundary and does not appear to extend to cross-user or OS-level privilege escalation. The CVSS 4.0 vector's AV:N and PR:N ratings are inconsistent with these prerequisites; defenders should treat this as requiring at minimum plugin-installation access in a multi-plugin deployment.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 8.7) implies remote unauthenticated exploitation, but this conflicts materially with the description, which situates the attacker as a sandboxed plugin already operating within the application - not an anonymous network adversary. The PR:N rating appears incorrect given that the attacker must have a plugin installed and executing inside the system; this discrepancy should be verified against the vendor advisory at GHSA-vr4h-5xqv-xxxf before using the published score for prioritization. No EPSS data was provided and there is no CISA KEV listing, leaving exploitation probability unquantified from public signals. Real-world impact is tightly bounded by deployment model: only environments that load plugins from multiple distinct, mutually distrusting sources - such as a platform accepting user-submitted plugins - face meaningful cross-plugin data leakage risk. Deployments running only internally developed or single-author plugins face negligible practical exposure despite the high numeric score.

An attacker who controls a sandboxed plugin named 'foo' - without READ_FILES permission - constructs file paths targeting the co-located plugin directory 'foobar'. Because _is_safe_path treats 'foo' as an authorized prefix for 'foobar', the malicious plugin reads sensitive configuration data or overwrites files belonging to the 'foobar' plugin, breaking inter-plugin isolation within the same user context. No public exploit code has been identified at time of analysis.