Back

Oxide Security Advisory 20260804-1: Silo TLS private key disclosure in the Oxide Terraform provider debug log

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_silo resource with tls_certificates are 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_certificates is 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.

Table 1. Revision History
RevisionDate (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 the oxide_silo resource 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 cert and key attributes 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

  1. 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 for PRIVATE KEY.

  2. 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.

  3. Upgrade to terraform-provider-oxide 0.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.