Steeltoe: TLS private keys written to /tmp with default permissions, never deleted

published 2026-06-17 4 mo ago modified 2026-10-26 14 d ago also GHSA-rxrh-4j9h-xgg9 , EUVD-2026-37820

cvss: 4.7; version 3.1, CNA
cisa kev: Not listed; not in CISA's catalog
epss: 0.1%; EPSS 0.1% chance of exploitation in 30 days, percentile 0%
public exploits: 0; none known

Steeltoe is an open source project that provides a collection of libraries that helps users build cloud-native applications. In Steeltoe.Configuration.Abstractions 4.0.0 through 4.1.0, when MySQL or PostgreSQL service bindings from `VCAP_SERVICES` include TLS client credentials, the Connectors library writes those credentials to temporary files in `Path.GetTempPath()` using `File.CreateText`. On Linux, `File.CreateText` creates files with mode `0644` (world-readable) under the process umask, and the files are never deleted. The same key material is protected at mode `0400` in `/proc/<pid>/environ`. Steeltoe.Configuration.Abstractions version 4.2.0 patches the issue. If an immediate upgrade is not possible, prevent other processes from running in the container under a different UID with access to `/tmp`.

Patch / fix

fixed in 1 links 1

nuget Steeltoe.Configuration.Abstractions 4.2.0

github.com/SteeltoeOSS/Steeltoe@8dd97cc commit

CISA SSVC

Exploitation: none
Automatable: no
Technical impact: partial
Assessed: 4 mo ago (2026-06-18)

Exploit prediction

0.07% chance of exploitation in the next 30 days, higher than 0% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by	version	score	vector
CNA	3.1	4.7	CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
GitHub	3.1	4.7	CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Affected packages

ecosystem	package	affected	fixed in
nuget	Steeltoe.Configuration.Abstractions	>=4.0.0, <4.2.0	4.2.0

Affected products

SteeltoeOSS Steeltoe.Configuration.Abstractions

Classification

Weakness

CWE-312 Cleartext Storage of Sensitive Information
CWE-732 Incorrect Permission Assignment for Critical Resource

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

Summary