Skip to content

ECLI-014: Buildkite PR builds may execute branch-controlled code on a Vault-capable agent #520

Description

@margaretjgu

Severity: Medium

Problem

catalog-info.yaml:41 sets build_pull_requests: true. The following code path then executes during PR builds without any repository-level contributor guard:

  1. .buildkite/pipeline.yml:51
    — Cloud smoke tests are triggered from the pipeline without a branch or
    contributor check.
  2. .buildkite/run-cloud-tests.sh:24
    — runs branch-controlled npm ci, followed by the branch-controlled build.
  3. .buildkite/run-cloud-tests.sh:35
    — sources branch-controlled .buildkite/setup-env.sh.
  4. .buildkite/setup-env.sh:18
    — invokes Vault and writes a Cloud admin key to ~/.elasticrc.yml.

If fork or otherwise untrusted PR builds run on an agent that is authorized for that Vault path, no nvm or jq compromise is required: the attacker modifies setup-env.sh, package.json lifecycle code, or build scripts in their PR branch and directly retrieves or exfiltrates the Vault credential.

Repository code does not show whether PR agents can authenticate to Vault. Confirm the fork-build policy, agent identity, Vault role, and agent reuse settings in Buildkite and Vault.

Fix

  • Ensure untrusted PR code cannot execute with a Vault-capable identity. Confirm fork behavior, build-source conditions, agent identity, and Vault authentication in Buildkite administration. A build.source == "pull_request" condition in .buildkite/pipeline.yml is branch-controlled code: a malicious PR can remove it. Enforce the gate in protected Buildkite configuration (e.g., a pipeline-level trigger condition, agent queue selection, or a Vault authentication policy that rejects PR build tokens), not in repository-controlled pipeline files.
  • If PR Cloud tests are required, require maintainer approval and use a separate, narrowly scoped test credential and Vault role. Do not expose the Cloud administration credential to branch-controlled code.
  • Restrict the Vault identity's policy to exactly secret/ci/elastic-cli/cloud-access. Keep only the credential required by this job at that dedicated path; -field=api_key is client-side output selection, not field-level Vault authorization. Store the expected path in protected Buildkite configuration to prevent accidental redirection, but do not treat the variable as an authorization boundary: branch-controlled code with the Vault identity can ignore it and invoke vault read directly.
  • Use single-use, ephemeral agents for every build that accesses Vault.

Risk

Medium on currently demonstrable facts; potentially Critical if confirmed.
If fork PR builds execute branch-controlled scripts on agents authorized for Vault, treat as Critical and disable secret access for PR builds immediately. The file-mode gap (ECLI-013) and the nvm bootstrap gap (ECLI-003) are secondary to this boundary question.


Copied from the security review in elastic/infosec#27626 (ECLI-014).

Metadata

Metadata

Assignees

Labels

securitySecurity related

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions