Steeltoe: TLS private keys written to /tmp with default permissions, never deleted
Description
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//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.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1- Range: >=4.0.0, <=4.1.0
Patches
Vulnerability mechanics
Root cause
"TLS client credentials from VCAP_SERVICES are written to temporary files with world-readable permissions (0644) and are never deleted."
Attack vector
An attacker who can run any other process in the same container under a different UID (or who gains access to `/tmp`) can read the temporary files containing TLS private keys and certificates written by the Steeltoe Connectors library. The files are created world-readable (mode 0644) in a predictable temp directory and are never cleaned up, so they persist for the lifetime of the container. No authentication or special privileges are required beyond the ability to list and read files in `/tmp` on the same Linux host or container.
Affected code
The vulnerability is in `ConfigurationDictionaryMapper.cs` (the `MapFromToFile` method) and the MySQL/PostgreSQL post-processors (`MySqlCloudFoundryPostProcessor.cs`, `PostgreSqlCloudFoundryPostProcessor.cs`). These files write TLS client credentials from `VCAP_SERVICES` to temporary files in `Path.GetTempPath()` using `File.CreateText`, which on Linux creates world-readable files (mode 0644) that are never deleted. The patch modifies `ConfigurationDictionaryMapper.cs` to set `UnixCreateMode = UserRead | UserWrite` and adds `TrackTempFiles` / `Dispose` logic in `CloudFoundryPostProcessor.cs` to delete the temporary files when the processor is disposed.
What the fix does
The patch makes two changes in `ConfigurationDictionaryMapper.cs`: it replaces `File.CreateText` with a new `CreateTempFile` method that passes a `FileStreamOptions` with `UnixCreateMode = UnixFileMode.UserRead | UnixFileMode.UserWrite`, ensuring the file is only readable by the owner. Additionally, `CloudFoundryPostProcessor` now implements `IDisposable` and tracks all temporary file paths via `TrackTempFiles`; when the processor is disposed (e.g., when the `PostProcessorConfigurationProvider` is disposed), those files are deleted. The test assertions verify both the restricted file mode and that the files no longer exist after disposal.
Preconditions
- configThe application must be running on Linux (the issue does not apply on Windows).
- inputThe application must use MySQL or PostgreSQL service bindings from VCAP_SERVICES that include TLS client credentials (sslCert, sslKey, sslRootCert).
- authAn attacker must be able to execute a process in the same container under a different UID, or otherwise gain read access to /tmp.
Generated on Jun 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2- github.com/SteeltoeOSS/Steeltoe/commit/8dd97cc6c4b184121a4bd1f92f9ac16918433471mitrex_refsource_MISC
- github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-rxrh-4j9h-xgg9mitrex_refsource_CONFIRM
News mentions
0No linked articles in our index yet.