High priorityDisclosed

Advisory · CVE-2026-114217

Konflux CI leaves GitHub tokens in plaintext on runners

Konflux CI automation scripts store sensitive GitHub access tokens in plaintext on the runner without cleaning them up, so a local attacker with CI environment access can read them and gain repository access.

Vendor
Konflux
Product
Konflux CI
Identifier / CWE
CVE-2026-114217
CWE-312
Action timing
Immediate
ELI5

Explain it like I’m five

The build machine writes the house key on a sticky note and leaves it on the desk after the job ends. Anyone who can walk into that room can pick up the key and use it on the repository.

SIMPLIFIED_ATTACK_PATH05 STEPS
  1. 01CI job runs

    A Konflux CI automation script runs on a runner and holds a sensitive GitHub access token.

  2. 02Token stored in plaintext

    The token is stored in plaintext on the runner instead of being handled as a secret.

  3. 03No cleanup

    The token is not cleaned up after execution, so it remains on the runner.

  4. 04Local attacker reads it

    A local attacker with access to the CI environment reads the stored token.

  5. 05Repository access

    The attacker uses the token for unauthorized repository access, potentially modifying source code or release artefacts.

What happened

A flaw in Konflux CI automation scripts stores sensitive GitHub access tokens in plaintext on the runner without cleaning them up after execution. A local attacker with access to the CI environment can read these stored credentials to gain unauthorized repository access, potentially allowing them to modify source code or release artefacts. NVD rates it CVSS 3.1 8.6 (CWE-312), and lists versions 0.2.2 and 0.2.3-rc.0 (and main) as affected.

No fixed release is stated in the sources checked, so none is claimed here. Until a fix ships, the exposure is controlled by who can reach the runner environment and by how long tokens remain valid and usable.

What to do

  1. Inventory Konflux CI runners and identify where GitHub tokens are stored or left behind after jobs.
  2. Restrict access to runner environments to only the operators who need it, and treat runner filesystems as credential-bearing.
  3. Rotate any GitHub tokens that were used on affected runners, and review repository and release-artefact changes for unauthorized modifications.
  4. Check runner logs and filesystem state for leftover token material after jobs complete.
  5. Track the vendor fix and apply it when released, then verify tokens are no longer left in plaintext.

Management note

A leaked CI token bypasses the usual account controls, so this is a credential incident waiting to happen rather than a patch-and-move-on bug. Rotate first, then tighten runner access, and do not assume a token that touched an affected runner is still safe.