Incorrect concealment of secrets

[KDS4wexp]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

When using secrets, I noticed that parts of words containing secret characters are replaced in Github action logs.
Example:
secret: sib
Ansible => An***le

however, the secret itself in the form {{ secret }} was not used in this block in the pipeline
This may lead to compromise of the secret in certain scenarios.
Is this behavior of the secrets engine safe?

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[iamwujiabao]

What you are experiencing is the intentional behavior of the GitHub Actions redaction engine. It is designed as a "fail-safe" to prevent secrets from leaking, even if a third-party tool prints them unexpectedly.

How it works:
GitHub Actions keeps a list of all secret values used in a job. Before the logs are displayed, it performs a global "search and replace." If any string in the log matches a secret value exactly, it is replaced with ***. It does not matter if the string came from the secret variable or was just part of a normal word like "Ansible"—if the characters match, they are masked.

Is this safe?
Yes, it is safer than the alternative. If GitHub only masked the specific variable calls, your secrets could still leak if a tool (like Ansible or a debugger) printed the "resolved" value to the console in plain text.

How to fix your logs:
The best way to stop this from happening is to avoid using short or common words as secrets.

• Use High-Entropy Secrets: Secrets should ideally be long, random strings (like API keys or UUIDs).
• Avoid Short Strings: A secret like sib is too short and will frequently collide with common words. Replacing it with a longer, more unique value will stop the engine from masking unrelated parts of your logs.

[Gecko51]

Yeah, this is expected behavior but your concern about it being a potential security issue is valid.

The redaction engine does a simple string match across the entire log output. If your secret value is sib, it'll mask every occurrence of sib in the logs, including inside words like "Ansible" becoming "An***le". It doesn't care about context or word boundaries.

The security angle you're pointing at: if someone sees "An***le" in the logs, they can pretty easily reverse-engineer that the secret contains "sib". With a 3-character secret, that's basically giving it away. So yes, short secrets and the redaction engine don't mix well.

The fix isn't on GitHub's side though, it's in how you set up your secrets:

• Never use short strings as secret values. A 3-character secret like sib is fundamentally too short for this system to handle safely. API keys, tokens, passwords should all be long random strings.
• If you're using something like a Sendinblue/Brevo API key, the full key would be long enough that it wouldn't collide with normal words in your logs.
• You can also use ::add-mask:: in your workflow to dynamically mask values at runtime:

- run: echo "::add-mask::${{ steps.something.outputs.token }}"

This adds values to the redaction list on the fly, which is useful for derived values that aren't stored as repo secrets.

One more thing: the redaction only applies to log output. It doesn't protect against secrets being written to files, artifacts, or $GITHUB_OUTPUT. If your workflow writes a secret to a file and then uploads that file as an artifact, it won't be masked there. Always be careful about where secrets end up beyond just the console output.