AWS access keys and hexadecimal signature strings are being masked incorrectly

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

I have an AWS command that performs S3 presigning. The output of this command is in the form:

https://BUCKETNAME.s3.us-east-1.amazonaws.com/FILENAME?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=[MASKED]&X-Amz-Date=20251117T170415Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=[MASKED]

The problem here is that the first masked value is an AWS access key followed by several other strings. None of those strings are in any of my masked CI/CD variables, and the additional text after the key would also never be part of the variables. This first masked value is of the form:

AKIA3XT7BTWZ49W02PKZ%2F20251117%2Fus-east-1%2Fs3%2Faws4_request

(note, this is not a real key, what's written here is for example purposes)

Even if the key itself was in a masked variable (it isn't), the remainder of the string ("%2Fus-east-1...aws4_request") ought not to be masked.

The second masked string is merely a hex hash. It is generated mathematically by the aws s3 presign command, and therefore could not possibly be in a masked variable. I have many examples of various values of this second masked string, even if somehow one was in a masked variable, they could not all be.

Here is an example of such a signature:

a5e28241748b55cd287e43609a78dba1e6a2beba284a787cdce040e9ed399f33

(again, not an actual value, but representative of one).

What's going on here? I know there's talk of performing additional pattern matching for masking (such as for base64 of masked values, etc.) but I didn't think any of those tests are in production.

For GitLab employees with support access to my account, here is a real-world case of a masked output (line 2268):

https://gitlab.com/conning/advise/advise/-/jobs/12068453438

Edited Dec 11, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading