VAULT_TOKEN leakage in Vault docker testcluster environment using version v0.25.1.

[brettbergin]

Hello,

While reviewing some of our Github Actions logging, we noticed leakage of our vault tokens in plain text. After reviewing the source code for the sdk, we found this line that prints the plaintext VAULT_TOKEN to STDOUT.

Offending Code:

vault/sdk/helper/testcluster/docker/environment.go

Line 454 in 2edd6c9

dc.Logger.Trace("cluster started", "helpful_env", fmt.Sprintf("VAULT_TOKEN=%s VAULT_CACERT=/vault/config/ca.pem", dc.GetRootToken()))

[dosubot]

Hi @brettbergin! I'm Dosu and I'm helping the HashiCorp, an IBM Company team.

Thanks for reporting this. The token printing code is indeed still present in sdk/helper/testcluster/docker/environment.go. There are actually two locations where the root token is logged in plaintext:

1. Line 454 — during cluster startup, logged at Trace level with a "helpful_env" label [1]
2. SetRootToken method — logs whenever the root token changes [2]

Both use dc.Logger.Trace(...) and format the token as an environment variable string (e.g., VAULT_TOKEN=<token> VAULT_CACERT=...), which appears to have been designed as a developer convenience for local test cluster usage. However, as you've observed, this becomes a real concern when CI/CD systems like GitHub Actions capture and store these logs.

I didn't find any existing issues or PRs that specifically address this token leakage in the docker testcluster. There have been related security improvements in other areas — for example, PR #30388 fixed sensitive data exposure in schema validation error logs — but none targeting this test infrastructure code.

Could you provide the following additional details?

• Vault Version: Which version of Vault are you running?
• Environment / OS: What operating system and environment are you using?

This will help the team assess the impact and prioritize accordingly.

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[brettbergin]

Hi there! I am using Vault v0.25.1, running the ubuntu-latest Github Action runner. Would it be possible to optionally set an ENV VAR to calculate a hash of the plaintext token strings and log those for environments like ci, in these two code locations you mentioned? Happy to help create a pull request here, if this sounds helpful.

When the SDK is configured with a non-test VAULT_ADDRESS, this logger will print the actual plaintext VAULT_TOKEN key material from the environment the sdk has been configured with. I think doing this can help optionally avoid this condition and still offer the developer to see the plaintext token with an unset ENV VAR.

[heatherezell]

Do you mean the hashicorp/vault-plugin-auth-jwt v0.25.1? Vault Server's current version is 2.0.x :)
Also, for security concerns, please always email security@hashicorp.com. That will get a much faster response time. Thank you!

[brettbergin]

Thanks @heatherezell!

Clarification on the version: I don't mean the auth-jwt plugin. The v0.25.1 is the github.com/hashicorp/vault/sdk module and the file that leaks the token, sdk/helper/testcluster/docker/environment.go, ships from that module in the hashicorp/vault repo.

I think "Vault v0.25.1" in my title was confusing. The SDK submodule versions separately from Vault Server 2.x.

Sorry for the mixup. Ill share the info with security@hashicorp.com as well. 👍

[heatherezell]

Thanks so much for the clarification! The security team is definitely the best way to get these sorts of issues handled. Appreciate the clarification!

[janderik]

VAULT_TOKEN Leakage via stdout in Docker Test Cluster

This is a legitimate security concern. Plaintext token output to STDOUT in test infrastructure can lead to token exposure in CI/CD logs, Docker container logs, and log aggregation systems.

Offending Code Analysis

The leak occurs in sdk/helper/testcluster/docker/environment.go:454 where VAULT_TOKEN is printed directly via fmt.Println or similar stdout output.

Recommended Fix

Immediate: Use the Vault SDK's built-in token redaction or log at debug level only:

// Instead of printing the token directly:
if os.Getenv("VAULT_LOG_LEVEL") == "debug" {
    log.Printf("[DEBUG] Generated test cluster token (length=%d)", len(token))
} else {
    log.Printf("[INFO] Test cluster initialized successfully")
}

If the token must be accessible programmatically, return it through a structured type rather than STDOUT:

type TestClusterResult struct {
    Token     string `json:"-"` // explicitly excluded from serialization
    Config    *api.Config
    Client    *api.Client
}

func (r *TestClusterResult) Redacted() string {
    return fmt.Sprintf("token:%s...%s", r.Token[:4], r.Token[len(r.Token)-4:])
}

Broader Recommendations

1. Audit all fmt.Println / fmt.Printf calls in sdk/helper/testcluster/ for any other sensitive values (keys, passwords, connection strings).

2. Add a CI lint rule to catch plaintext secret output:

# .github/workflows/secret-leak.yml
- name: Check for secret leaks in test output
  run: |
    go test ./sdk/helper/testcluster/... 2>&1 | \
      grep -iE "(token|password|secret|api.key)" && \
      echo "::warning::Possible secret in test output"

3. Consider environment variable isolation - Docker test clusters should use --env-file with restricted permissions rather than exporting tokens to the container environment where they may be captured by log drivers.

This pattern (fmt.Println of credentials) should be flagged in the Vault SDK's security review checklist.