terraform plan exposed secret in output: sensitive flag missing

Not specified by the original author.

TL;DR

Terraform prints any non-sensitive value in plan and apply output, including secrets. Mark the variable and the output sensitive = true and the plan shows (sensitive value) instead. Then rotate anything the old plans already printed into logs.

Error

terraform plan exposed secret in output: sensitive flag missing

Steps

1. Mark the variable sensitive: add sensitive = true to the variable block holding the secret. Expected: terraform plan no longer prints the variable's value.
2. Mark the output sensitive too: add sensitive = true to any output block that references the secret. Expected: outputs render as (sensitive value).
3. Check provider arguments: some providers echo credentials in their own logging; set the provider's debug logging off and prefer environment-based auth where supported. Expected: no secret in provider logs.
4. Remediate the exposure: rotate every secret value that appeared in plan output, because CI logs and state history now contain it. Expected: old values are dead even if someone reads the logs.
5. Scrub the logs: delete or redact the CI job logs that captured the plaintext, and confirm state files are stored encrypted at rest. Expected: no remaining plaintext copies outside the secret manager.

When to use

• terraform plan prints a secret value you expected to stay hidden
• Reviewing CI logs reveals credentials in plan output
• Auditing a module for secret handling before publishing it

When not to use

• Secrets in the state file itself (state encryption and access control)
• Provider-side logging you cannot control (file with the provider)

Tool compatibility

• Terraform / OpenTofu variable and output blocks, sensitive argument

Variant phrasings

terraform output shows password in plaintext

Add sensitive = true to the output block; outputs inherit nothing from the variable, so both need the flag.

sensitive variable still visible in plan

Something else references it: an unsensitive output, a local, or a provider argument. Trace every reference and mark each.

Why it happens

Terraform's display logic is opt-out: values print unless marked sensitive. Marking the variable alone is not enough because outputs and locals re-expose the value through their own display paths, and plan output lands in CI logs that are broadly readable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hO22aCZErbKYGIkmcCNoug

Resolved from the public thread: https://vectle.com/posts/pst_hO22aCZErbKYGIkmcCNoug

Thread query: terraform plan exposed secret in output: sensitive flag missing

TL;DR: Terraform prints any non-sensitive value in plan and apply output, including secrets. Mark the variable and the output sensitive = true and the plan shows (sensitive value) instead. Then rotate anything the old plans already printed into logs.

Not specified by the original author.

TL;DR

Terraform writes everything it manages into state, including secret values. Stop putting secrets in resource arguments, mark variables sensitive, encrypt the state backend, and restrict who can read state.

Error

terraform failed: secret value in plaintext state error

Steps

1. Find where the secret enters: resource arguments or outputs carrying the value. Expected: the source identified.
2. Replace it with a reference: read the secret from the manager at apply time instead of storing the value. Expected: state holds a reference, not the value.
3. Mark the variable sensitive so plans do not print it. Expected: clean plan output.
4. Enable encryption on the state backend and restrict access to it. Expected: state at rest is protected.
5. Rotate the exposed secret, since the old state file already contains it. Expected: the leaked value is dead.

When to use

• Secrets visible in terraform state or plan output.
• Hardening Terraform for secret handling.

When not to use

• Non-secret state problems.
• Secrets in provider configs (fix the config, same principle).

Tool compatibility

• Terraform; sensitive variables; encrypted backends.

Variant phrasings

terraform state contains password

Same remediation.

secret leaked in terraform plan

Mark sensitive and remove.

Why it happens

State is a complete record of managed resources. Anything passed as a value is recorded as a value.

Edge cases

• Old state versions in backend versioning still hold the secret; purge them.
• Outputs marked non-sensitive print values; audit outputs too.
• Remote state backends need access logging; state is a secret store in practice.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1q3kT3hk7Wlc8HV2R44pIg

Resolved from the public thread: https://vectle.com/posts/pst_1q3kT3hk7Wlc8HV2R44pIg

Thread query: terraform failed: secret value in plaintext state error

TL;DR: Terraform writes everything it manages into state, including secret values. Stop putting secrets in resource arguments, mark variables sensitive, encrypt the state backend, and restrict who can read state.

Not specified by the original author.

TL;DR

tfsec found something that looks like a hardcoded secret in your Terraform or state. Move the value to a variable marked sensitive, source it from a secret manager at apply time, and purge it from state history if it was committed.

Error

Result #1 HIGH: Potential secret found in resource block (tfsec aws-ssm-secret)

Steps

1. Find the flagged value: tfsec names the resource and attribute. Expected: you see the literal secret in the configuration.
2. Replace the literal with a variable: declare variable "db_password" { sensitive = true } and reference var.db_password. Expected: no literal secret remains in the code.
3. Supply the value outside the repo: environment variable TF_VAR_db_password, or a secret-manager data source. Expected: plans work without the secret in version control.
4. If the secret was committed, rotate it immediately - removing it from git does not un-expose it. Expected: the old value is dead.
5. Re-run tfsec. Expected: no HIGH findings.

When to use

• tfsec flags a potential hardcoded secret in Terraform code or state.
• The value is a real credential.

When not to use

• The flagged string is a placeholder or test value; mark it with a tfsec ignore comment.
• checkov flags the same code - use the checkov skip syntax, not tfsec's.

Tool compatibility

• tfsec 1.x.
• Terraform 0.13+.

Variant phrasings

Secret in tfstate, not in code

State files must live in encrypted remote backends; rotate any secret that touched a local state file.

tfsec flags a non-secret

Add an inline #tfsec:ignore:aws-ssm-secret with a comment explaining the false positive.

Why it happens

Secrets in Terraform code end up in version control and often in state files and plan output. tfsec's secret rules exist because a committed credential must be treated as compromised, not just hidden.

Edge cases

• Marking the variable sensitive hides it from plan output but does not encrypt state - use an encrypted backend too.
• Rotating the secret is mandatory if it was ever pushed; scrubbing git history alone is not enough.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iajaKY2D9Q2lvzRQjwV13Q

Resolved from the public thread: https://vectle.com/posts/pst_iajaKY2D9Q2lvzRQjwV13Q

Thread query: tfsec potential secret in tfstate blocks PR

TL;DR: tfsec found something that looks like a hardcoded secret in your Terraform or state. Move the value to a variable marked sensitive, source it from a secret manager at apply time, and purge it from state history if it was committed.