The oxide_silo resource in the Oxide Terraform provider
(terraform-provider-oxide) 0.10.0 through 0.20.1 writes the PEM-encoded TLS
private keys supplied in the tls_certificates argument into the Terraform
debug log, which allows anyone with read access to that log output to obtain the
private key for a silo’s external API and console endpoints via TF_LOG=DEBUG
or TF_LOG=TRACE during an apply that creates a silo.
Racks and rack software are not affected. No rack update is required and no action is needed on the rack itself.
Exposure depends on how the provider was run:
Only Terraform configurations that create an
oxide_siloresource withtls_certificatesare affected, and only when Terraform debug logging was enabled during the apply that created the silo. With the default of debug logging off the key is never written anywhere.The key is not written to Terraform state.
tls_certificatesis a write-only attribute, so state files do not contain it. Exposure is limited to debug log output.
Customers who ran an apply with debug logging enabled should treat the silo’s TLS private key as disclosed to everyone who can read those logs. This issue was found by Oxide’s internal automated code scanning; it was not reported externally, and Oxide has no indication it has been exploited. No CVE has been assigned.
| Revision | Date (YYYYMMDD) | Changes |
|---|---|---|
1.0 | 20260804 | Initial Release |
Impacted Products
Oxide Terraform provider (
terraform-provider-oxide) 0.10.0 through 0.20.1. The disclosure was introduced together with theoxide_siloresource in 0.10.0 and is present in every release since.Oxide rack hardware and rack software are not affected. Silo TLS certificates installed by any means other than the Terraform provider are not affected.
The fix removes the offending log statement and marks the nested
certandkeyattributes sensitive. It is fixed in provider releases 0.20.2 and 0.21.0.
Impact
Running terraform apply with debug logging enabled emits the silo’s TLS
private key, in plaintext PEM form, into the Terraform debug log. Anyone who can
read that log output obtains the private key for the silo’s external API and
console TLS endpoints.
With that key, an attacker who is also able to intercept or redirect network traffic destined for the silo’s endpoints can present a certificate that clients accept as valid. That enables impersonation of the silo’s API and console and the capture of credentials, session tokens, and API request contents from users who connect to the impersonated endpoint, or interception of sessions in transit. Because the endpoints negotiate forward-secret cipher suites, the key alone does not permit retroactive decryption of previously recorded traffic.
The private key by itself does not authenticate to the Oxide API, does not grant access to silo or instance data, and does not confer any privilege on the rack. No other secrets handled by the provider are disclosed by this issue.
The attacker requires no privileges on the rack. The only prerequisites are read
access to the log output and the ability to execute a terraform apply.
Action Required
For each silo created through the Oxide Terraform provider, establish whether debug logging was enabled during the apply that created it. Search logs for the string
Silo creation parameters:or forPRIVATE KEY.If a key is found in the logs, treat the silo’s TLS private key as compromised. Obtain a new key and certificate for the silo’s external API and console endpoints, install them on the silo, and revoke the previous certificate. Then purge or restrict access to the log artifacts that contain the old key.
Upgrade to
terraform-provider-oxide0.20.2, 0.21.0, or greater which removes the log statement. Until then, apply the mitigation below.
Mitigations
When using a vulnerable version, do not run Terraform with
TF_LOG=DEBUG, TF_LOG=TRACE, or the equivalent TF_LOG_PROVIDER setting for
configurations that manage oxide_silo resources. Debug logging is off by
default. Leaving it off prevents the disclosure entirely.
Technical Background
The oxide_silo resource’s Create method assembles an
oxide.SiloCreateParams value. The tls_certificates argument becomes
params.Body.TlsCertificates, a []oxide.CertificateCreate whose Key field
is populated directly from the configuration (Key: tlsCert.Key.ValueString())
and holds the PEM-encoded private key. Immediately before calling SiloCreate,
Create executes:
tflog.Debug(ctx, fmt.Sprintf("Silo creation parameters: %+v", params.Body.TlsCertificates), nil)The %+v verb serializes every field of every element in the slice, including
Key. The formatted result becomes the log message, so the private key is
emitted verbatim whenever the provider’s debug log level is active.
In the resource schema, tls_certificates and its nested attributes including
cert and key are declared WriteOnly: true but not Sensitive: true.
WriteOnly keeps the values out of Terraform state, which is why state files
are unaffected, but it does not cause the plugin framework to redact the values
elsewhere.
This is an instance of MITRE CWE-532, Insertion of Sensitive Information into Log File.
The log statement was introduced in the same commit that added the oxide_silo
resource first released in provider version 0.10.0.
The fix removes the log statement and marks the nested cert and key
attributes Sensitive: true.