LiveActive security incident?Get immediate response
CVE Record

CVE-2019-1552: Windows builds with insecure path defaults

OpenSSL has internal defaults for a directory tree where it can find a configuration file as well as certificates used for verification in TLS. This directory is most commonly referred to as OPENSSLDIR, and is configurable with the --prefix / --openssldir configuration options. For OpenSSL versions 1.1.0 and 1.1.1, the mingw configuration targets assume that resulting programs and libraries are installed in a Unix-like environment and the default prefix for program installation as well as for OPENSSLDIR should be '/usr/local'. However, mingw programs are Windows programs, and as such, find themselves looking at sub-directories of 'C:/usr/local', which may be world writable, which enables untrusted users to modify OpenSSL's default configuration, insert CA certificates, modify (or even replace) existing engine modules, etc. For OpenSSL 1.0.2, '/usr/local/ssl' is used as default for OPENSSLDIR on all Unix and Windows targets, including Visual C builds. However, some build instructions for the diverse Windows targets on 1.0.2 encourage you to specify your own --prefix. OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue. Due to the limited scope of affected deployments this has been assessed as low severity and therefore we are not creating new releases at this time. Fixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c). Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k). Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s).

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysislow

Security readout for executives and security teams

Plain-English summary

Some Windows builds of OpenSSL used insecure default directories that could point into C:/usr/local. If that location was writable by untrusted local users, they could alter OpenSSL configuration, trusted certificates, or engine modules used by affected applications. OpenSSL rated the issue low because only limited deployment patterns are affected.

Executive priority

Treat this as a hygiene and supply-chain exposure, not an emergency internet-facing vulnerability. Prioritize systems where untrusted users share Windows hosts or where OpenSSL is embedded in critical software.

Technical view

CVE-2019-1552 affects OpenSSL 1.1.1-1.1.1c, 1.1.0-1.1.0k, and 1.0.2-1.0.2s in certain Windows build configurations. The issue is insecure OPENSSLDIR and prefix defaults for Windows targets, especially mingw, causing libraries to search writable Windows paths for configuration, CA material, or engines.

Likely exposure

Exposure is most likely in Windows software that embeds or ships OpenSSL built with affected defaults. Standard Unix deployments are not the main concern. Risk depends on whether C:/usr/local or related OpenSSL directories exist and are writable by untrusted users.

Exploitation context

The supplied sources do not show active exploitation, and KEV is false. Practical abuse appears local or post-access: an attacker needs ability to write to the relevant path before influencing OpenSSL behavior in affected applications.

Researcher notes

The key question is build provenance. Confirm whether the vulnerable defaults were compiled in, then evaluate whether writable directories can influence runtime trust stores, config loading, or engines. The source bundle does not provide exploit examples or product-specific impact beyond referenced advisories.

Mitigation direction

  • Upgrade OpenSSL to 1.1.1d, 1.1.0l, 1.0.2t, or later supported versions.
  • Review vendor advisories for embedded OpenSSL products and apply vendor-provided updates.
  • Ensure OpenSSL configuration, certificate, and engine directories are not writable by untrusted users.
  • For custom Windows builds, set explicit safe --prefix and --openssldir paths.

Validation and detection

  • Inventory Windows applications and appliances bundling OpenSSL 1.1.1, 1.1.0, or 1.0.2.
  • Confirm the OpenSSL build version and configured OPENSSLDIR for each candidate component.
  • Inspect permissions on C:/usr/local and OpenSSL configuration, certificate, and engine paths.
  • Check vendor bulletins for products that package OpenSSL rather than relying on system libraries.
Prepared
Confidence
high
Sources
6

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2019-1552 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
0Timeline events
0ADP providers
22Source links

CVSS and timeline data

No CVSS vectors or timeline events were available in the normalized CVE source material.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
OpenSSLOpenSSLFixed in OpenSSL 1.1.1d (Affected 1.1.1-1.1.1c), Fixed in OpenSSL 1.1.0l (Affected 1.1.0-1.1.0k), Fixed in OpenSSL 1.0.2t (Affected 1.0.2-1.0.2s)Listed
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.