CVE-2026-34054: vcpkg OpenSSL Path Traversal Vulnerability

CVE-2026-34054 Overview

CVE-2026-34054 affects vcpkg, Microsoft's free and open-source C/C++ package manager. Windows builds of OpenSSL produced by vcpkg prior to version 3.6.1#3 hardcode the openssldir configuration value to a path on the build machine. When the resulting binaries run on customer machines, OpenSSL searches that build-time path for configuration and certificate data. An attacker with the ability to create that path on the target system can place attacker-controlled files where OpenSSL will load them, leading to local code execution in the context of the consuming process. The flaw maps to CWE-427: Uncontrolled Search Path Element.

Critical Impact
Attackers with local write access to the embedded build path can hijack OpenSSL configuration loading and execute code in any application built with the vulnerable vcpkg-produced OpenSSL.

Affected Products

Microsoft vcpkg Windows OpenSSL builds prior to 3.6.1#3
C/C++ applications statically or dynamically linked against vcpkg-produced OpenSSL on Windows
Downstream software distributing OpenSSL binaries built via vulnerable vcpkg ports

Discovery Timeline

2026-03-31 - CVE-2026-34054 published to NVD
2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34054

Vulnerability Analysis

The vulnerability stems from vcpkg's OpenSSL port hardcoding the openssldir value at build time. OpenSSL uses openssldir to locate openssl.cnf, trusted certificate stores, and engine configuration. When the port baked in a path specific to the vcpkg build machine, the compiled binaries shipped to customers contained references to a path the customer does not control. This is a classic uncontrolled search path issue [CWE-427] applied to a configuration file rather than a DLL.

Root Cause

vcpkg's Windows OpenSSL build scripts passed an absolute path from the build environment into OpenSSL's --openssldir configure option. The resulting binaries hold that absolute path as a runtime default. Customer systems running these binaries inherit the build machine's directory layout as an implicit trust boundary.

Attack Vector

A local attacker who can create or write to the embedded build-time path on the target Windows system can drop a malicious openssl.cnf file. When any application using the vulnerable OpenSSL initializes, it parses that configuration. The configuration file can reference attacker-supplied engines or providers, resulting in arbitrary code execution within the host process. Exploitation requires local access and the ability to create the referenced directory, which on many Windows systems is achievable by low-privileged users since the build path typically resides outside protected system directories.

For technical specifics, see the GitHub Security Advisory GHSA-p322-v6vw-vrq9 and the remediation pull request.

Detection Methods for CVE-2026-34054

Indicators of Compromise

Presence of unexpected openssl.cnf files at paths matching vcpkg build machine directory structures on production Windows hosts
Unknown OpenSSL engine or provider DLLs loaded by applications linked against vcpkg-built OpenSSL
New directories created by non-administrative users that mirror build-time openssldir locations

Detection Strategies

Inspect deployed OpenSSL binaries with strings or openssl version -d to identify embedded build paths inherited from vcpkg
Inventory applications shipping OpenSSL produced by vcpkg versions prior to 3.6.1#3
Monitor file creation events on Windows for directories matching common vcpkg build path patterns under non-system locations

Monitoring Recommendations

Alert on process loads of openssl.cnf from user-writable directories
Track DLL loads of unsigned or untrusted OpenSSL engines and providers across endpoints
Audit software bills of materials (SBOMs) for OpenSSL components originating from vcpkg builds and correlate with version metadata

How to Mitigate CVE-2026-34054

Immediate Actions Required

Upgrade vcpkg to a release that includes OpenSSL port revision 3.6.1#3 or later and rebuild dependent binaries
Redistribute updated application binaries to all customer and production endpoints
Audit existing Windows hosts for the presence of the build-time openssldir path and remove any unauthorized contents

Patch Information

Microsoft patched the issue in vcpkg OpenSSL port version 3.6.1#3. The fix replaces the hardcoded build-machine path with a runtime-resolved location. See the upstream commit 5111afdf for the source change.

Workarounds

Set the OPENSSL_CONF and SSL_CERT_DIR environment variables in application launchers to point to trusted locations, overriding the embedded default
Pre-create the embedded openssldir path with strict ACLs limiting write access to administrators only
Rebuild OpenSSL locally with a corrected --openssldir argument until vcpkg upgrade is feasible

bash

# Configuration example: override openssldir at runtime via environment
setx OPENSSL_CONF "C:\Program Files\Common Files\SSL\openssl.cnf"
setx SSL_CERT_FILE "C:\Program Files\Common Files\SSL\cert.pem"

# Verify the path embedded in a built OpenSSL binary
openssl version -d