Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#520 0 comments 0 reactions 1 assignee View on GitHub

@margaretjgu is already working on this.

Since Aug 6, 2026.

Assessment

This issue has not been assessed yet.

Description

security

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).

Dominant language
TypeScript
Stars
43
Forks
24
Avg merge
1d 5h
Merged PRs (30d)
61

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from elastic/cli

All issues in elastic/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.