Bazel is a popular build tool from Google, trusted by large companies and open-source developers to manage fast, reliable builds and tests. But like any complex software, it sometimes faces security issues. One such risk was discovered in 2022—CVE-2022-3474—and it's important you learn what happened, why it matters, and how to protect yourself.

What is CVE-2022-3474?

This vulnerability (see its entry on NVD) affects Bazel versions prior to 5.3.2 and 4.2.3. At its core, this bug caused Bazel to send all user-provided credentials to remote asset servers—even those intended for unrelated services—whenever a build accessed a remote asset.

Why is this dangerous?  
Credentials might include tokens, passwords, or authentication headers used for other services. If Bazel sends all of them with every remote asset request, a malicious or compromised server could potentially collect secrets meant for other endpoints.

Technical Details: What's Happening Under the Hood?

When Bazel fetches resources remotely (for example, using the remote REST API), it must authenticate its requests. Normally, you might configure separate credentials for different backends:

Repo B needs Token Y

Before the patch, Bazel included all credentials in every outbound request, rather than only the credential necessary for that specific endpoint.

Suppose you had a configuration like this

# bazelrc or workspace configuration (simplified)
remote_credentials = {
    "https://cache.example.com";: "Bearer CACHE_TOKEN",
    "https://assets.example.org";: "Bearer ASSETS_TOKEN",
}

When Bazel requests something from https://assets.example.org, it should only use ASSETS_TOKEN. However, with the vulnerability, Bazel might send *both* CACHE_TOKEN and ASSETS_TOKEN headers to both servers:

GET /some/path HTTP/1.1
Host: assets.example.org
Authorization: Bearer CACHE_TOKEN
Authorization: Bearer ASSETS_TOKEN
...

A remote server (say, assets.example.org) could snoop both tokens, even though it should never have seen CACHE_TOKEN.

Exploit Details: How Bad Could This Get?

This issue is labeled medium severity (see Bazel's GitHub issue #16529), but the real risk depends on your environment and setup:

If you use the same credentials everywhere, an attacker learns nothing new.

- If you use separate secrets for different services (as recommended), a remote asset server could collect and misuse tokens for other services (e.g., push to your private cache, rewrite history, or access confidential builds).
- Attack vector: Any remote or third-party server you configure Bazel to access, intentionally or indirectly, could collect stray secrets.

Note: This issue is NOT about remote code execution, but rather about credential exposure: your tokens reach places they shouldn't.

1. Setup Credentials

# ~/.bazelrc
build --remote_cache=https://cache.example.com
build --remote_rest_api=https://assets.example.org

# Credentials (pseudo, can be added via environment variables or config files)
CACHE_TOKEN="TopSecret1"
ASSETS_TOKEN="TopSecret2"

2. Trigger Asset Fetch

When your build system runs and requests a remote asset, *both* credentials might go to either endpoint, due to this flaw.

If you control assets.example.org, you’d receive

Authorization: Bearer TopSecret1
Authorization: Bearer TopSecret2

Even though only TopSecret2 was intended for you.

How Was This Fixed? (And How Should You Protect Yourself?)

From 5.3.2 onward (and 4.2.3 for LTS), Bazel’s core code was updated to send only the relevant credential for each request.

Upgrading Your Bazel Version

Action Required:

Quick Upgrade Guide

bazel version  # see your current version

# To upgrade (example with Homebrew on macOS):
brew upgrade bazel

# Or download from Bazel's release page

References

- Official Bazel GitHub Issue #16529 (Security Disclosure)
- NVD Entry for CVE-2022-3474
- Bazel Security Releases

Conclusion

CVE-2022-3474 is a great reminder that even developer tools can leak credentials in subtle ways. It’s essential to keep your build systems up to date, review how credentials are handled, and rotate secrets if they might have been exposed.

If you’re running Bazel < 5.3.2 (or < 4.2.3 LTS), you are at risk. The fix is simple: upgrade Bazel, and check your credential usage practices.

Timeline

Published on: 10/26/2022 19:15:00 UTC
Last modified on: 10/28/2022 18:19:00 UTC