When using secured environment variables in Bitbucket Pipelines, if you set a variable to a value that is outputted to a known value in the build log, you can infer the secured value.
Apparently the log output is secured through a find and replace of the secured variables value. This naive approach can lead to information leaking when the value is the same as some other known string, like the organization name for example.
If you have
SECURED_VARIABLE=myorganization and your organization is called
myorganization, this will lead to the following output in the build log:
+ umask 000 + GIT_LFS_SKIP_SMUDGE=1 git clone --branch="test" --depth 50 https://x-token-auth:$REPOSITORY_OAUTH_ACCESS_TOKEN@bitbucket.org/$SECURED_VARIABLE/project.git $BUILD_DIR ; git reset --hard <hash> ; git remote set-url origin firstname.lastname@example.org:$SECURED_VARIABLE/project.git Cloning into '/opt/atlassian/pipelines/agent/build'... HEAD is now at <hash> <message>. + chmod 777 $BUILD_DIR
Since the organization name is a known value, you can infer that
While there's no 100% safe way to do this since a lot of the output can be generated by the user, it's possible to omit those substitutions in places where the output is 100% generated by Atllassian, such as the repository checkout stage, before the user script even begins.