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.

[Abdxlrahman]

Yes, this is expected behavior in GitHub Actions secret masking.

GitHub masks any log output matching the secret value, even if it appears as part of another word. This is done intentionally to prevent accidental secret leakage.

Example:

• Secret: sib
• Output: Ansible
• Log becomes: An***le

This behavior is generally considered safe, but short secrets can cause excessive or confusing masking. Best practice is to avoid very short secrets and use long random values (tokens, UUIDs, hashes, etc.), which reduces false matches and improves security.

[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! 💬

[kartik99917]

This is expected behavior. GitHub's secret masking engine performs pattern-based redaction, so it can mask matching substrings even when the secret wasn't explicitly referenced in that step.

The masking is intentionally conservative to reduce the chance of leaking secrets, which can occasionally lead to over-masking of unrelated output. While it may affect log readability, it doesn't mean the secret itself has been exposed or that the masking engine is unsafe.