CVE-2026-55563

Executive Summary

CVE-2026-55563 is a CI/CD trust-boundary flaw in Feast, the open-source feature store for AI/ML, affecting versions prior to 0.65.0. The repository's .github/workflows/pr_integration_tests.yml workflow was configured with pull_request_target combined with the synchronize event, and it preserved privileged labels (ok-to-test, approved, lgtm) across newly pushed commits. A fork contributor could therefore obtain approval on a benign revision, then push additional commits to the same pull request and have the changed code executed through privileged make targets inside a job that holds GCP, AWS, and Snowflake credentials. Impact includes arbitrary code execution on the CI runner, disclosure of long-lived cloud credentials, and potential pivot into downstream cloud resources (CWE-863 — Incorrect Authorization).

Technical Analysis

The defect is an authorization/integrity failure in GitHub Actions workflow trust semantics, not a memory-safety or network-service vulnerability.

Three configuration properties combine to produce the flaw:

1. pull_request_target trigger. Unlike pull_request, the pull_request_target event runs in the context of the base repository, meaning the job has access to repository secrets and a privileged GITHUB_TOKEN. In exchange, GitHub does not automatically check out the contributor's code — but the workflow can still fetch and execute any ref it chooses, including the merge ref of the untrusted PR.
2. synchronize event inclusion. The synchronize action type fires whenever new commits are pushed to the head branch of an open pull request. This means a PR that has already been reviewed and approved can be updated with different content without re-triggering review gating.
3. Label persistence across commits. The workflow honored ok-to-test, approved, or lgtm labels as authorization signals, but those labels were not automatically removed when the PR head changed. Approval was bound to the PR, not to the specific revision that was reviewed.

The NVD description states that changed code is run from refs/pull/${{ github.event.pull_request.number }}/merge through privileged make targets. The job then exposes GCP, AWS, and Snowflake credentials to that code. The CI runner therefore becomes an execution proxy: any contributor with a merged-from-fork PR and a preserved approval label can execute arbitrary commands in an environment holding cloud credentials with whatever privilege the CI service account carries in those three environments.

The NVD description notes that "an external label-removal integration could mitigate the condition, but no repository workflow provided that protection." This is a governance gap as much as a code gap — the repository relied on convention (reviewers re-reviewing after pushes) rather than enforcement.

Attribution to CWE-863 (Incorrect Authorization) is accurate: the approval label is an authorization token, and it was applied to an object (the PR) whose contents changed after the authorization decision. This is the classic time-of-check/time-of-use problem expressed in a software-supply-chain context.

No CVSS vector or score has been assigned by NVD (CVSS Score: N/A). No EPSS score is published. The vulnerability is not in CISA KEV. No public PoC, Nuclei template, or exploit code was observed at time of writing.

Exploitation Scenarios

The attack chain follows the vulnerability class (CI/CD trust-boundary abuse) rather than a specific published exploit. No public PoC exists; the sequence below is derived directly from the workflow semantics described in the NVD entry.

1) Reconnaissance / target identification. The attacker identifies a public repository that (a) uses pull_request_target, (b) triggers on synchronize, (c) gates privileged jobs on review labels, and (d) executes contributor-controlled content in a job with cloud credentials. Feast's .github/workflows/pr_integration_tests.yml matched all four conditions prior to 0.65.0, and the fork-PR model means no repository write access is required.

2) Approval acquisition against a benign revision. The attacker opens a pull request from a fork containing an innocuous change — documentation, a formatting fix, a trivial test — that is likely to pass review and receive the ok-to-test, approved, or lgtm label. The approval is legitimate. Nothing about this step is anomalous to a reviewer.

3) Commit substitution via the synchronize event. After the label is applied, the attacker pushes a new commit to the same PR head branch. GitHub emits the synchronize activity type. The workflow re-runs. Because the labels persisted across the push, the job considers itself still authorized and proceeds to the privileged execution path rather than halting for re-review. The privileged step checks out refs/pull/${{ github.event.pull_request.number }}/merge — a ref whose content the attacker now controls — and runs it through make targets.

4) Credential access and post-exploitation. Code running in that job inherits the workflow's environment, which the NVD description states includes GCP, AWS, and Snowflake credentials. At the vulnerability-class level, the attacker's objectives are: read the credential material from environment variables or credential-helper configuration, exfiltrate it off the runner, and then authenticate to the downstream cloud providers directly from attacker-controlled infrastructure. From there, impact is bounded only by the IAM permissions granted to the CI service identities — typical outcomes include access to model artifacts, feature-store data stores, cloud storage buckets used for training data, and any secrets the CI role can read.

A representative make invocation is not documented in the NVD text beyond the statement that "privileged make targets" are used; the exact target names are not available and are deliberately not fabricated here. The critical property is that the make target executes repository content, and the repository content is attacker-supplied at that moment.

Mitigating condition that was absent: an automated integration that strips approval labels on push would have broken step 3 by forcing re-authorization. Per NVD, no repository workflow in Feast provided that protection prior to 0.65.0.

Impact Assessment

Confidentiality — High. GCP, AWS, and Snowflake credentials are exposed to attacker-controlled code. These are typically long-lived service credentials for CI pipelines, meaning disclosure grants durable access rather than a single-session token. Data reachable through those identities (feature-store backends, training data, model registries, cloud storage) is at risk.

Integrity — High. An attacker with valid cloud credentials can modify, poison, or delete data and artifacts those credentials can write to. In an AI/ML feature-store context, integrity compromise of training features or model artifacts is a downstream supply-chain risk that can propagate to any model retrained or served from that data.

Availability — High at scope-changed boundaries. Destruction or corruption of feature-store tables, storage buckets, or inference infrastructure is achievable with write/delete permissions. The S:C (Scope: Changed) property applies because the runner compromise escapes the CI boundary and impacts cloud environments that the vulnerable component does not itself govern — a consequence consistent with CWE-863 classed authorization failures.

Attack complexity — Low, with user interaction. The attacker needs a PR to be approved (UI:R), but approval for a benign change is a normal cooperative event. No exploit primitives, no memory corruption, no race window. The PR:L reflects that any fork contributor can attempt it.

Blast radius. Every fork contributor to the affected repository, plus every downstream cloud resource the CI service accounts can reach. Because Feast is a widely used component in ML infrastructure, a compromise of its cloud credentials also carries a supply-chain dimension for projects consuming Feast release artifacts produced by that pipeline. No evidence of in-the-wild exploitation was observed; no threat actor campaign is associated with this CVE in available sources.

Detection Guidance

Detection must focus on GitHub Actions audit logs, runner process telemetry, and anomalous cloud authentication from CI-associated identities. Because the vulnerable component is a library and a workflow file, network-layer signatures are weak signals at best and are included below only for completeness around credential exfiltration behavior.

Sigma Rule

title: Feast CI Privileged Workflow Execution From Untrusted PR Merge Ref
id: 8f3c1a92-7b44-4e0d-9c21-6a5f0d3e7b18
status: experimental
description: Detects execution of repository build targets inside a privileged pull_request_target workflow on a merge ref, consistent with CVE-2026-55563 abuse.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-55563
author: valtersit.com Threat Intelligence
date: 2026/01/01
logsource:
  product: linux
  category: process_creation
detection:
  selection_make:
    Image|endswith:
      - '/make'
      - '/gmake'
  selection_merge_ref:
    CommandLine|contains: 'refs/pull/'
  selection_ci_env:
    ParentImage|contains:
      - 'Runner.Worker'
      - 'Runner.Listener'
      - 'actions-runner'
  condition: selection_make and selection_merge_ref and selection_ci_env
falsepositives:
  - Legitimate trusted-branch CI builds that reference pull refs internally
level: high
tags:
  - attack.initial_access
  - attack.t1195
  - cve.2026.55563

YARA Rule

rule CVE_2026_55563_Feast_PR_Target_Workflow
{
    meta:
        description = "Detects Feast workflow definitions using pull_request_target with synchronize and privileged label gating (CVE-2026-55563)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-55563"
        date = "2026-01-01"
        severity = "high"

    strings:
        $prt  = "pull_request_target" ascii nocase
        $sync = "synchronize" ascii nocase
        $lbl1 = "ok-to-test" ascii nocase
        $lbl2 = "approved" ascii nocase
        $lbl3 = "lgtm" ascii nocase

    condition:
        $prt and $sync and any of ($lbl*)
}

Suricata IDS Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2026-55563 Possible Feast CI Credential Exfiltration to External Host"; flow:established,to_server; http.method; content:"POST"; http.header; content:"User-Agent"; content:"GitHubActions"; http.uri; pcre:"/(gcp|aws|snowflake|token|credential)/i"; threshold:type both, track by_src, count 3, seconds 60; classtype:trojan-activity; reference:cve,2026-55563; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-55563; sid:20265556; rev:1;)

Note: this signature targets post-compromise exfiltration traffic from a CI runner and is a low-fidelity indicator; it should be correlated with CI audit events rather than alerted on in isolation.

Elastic Detection

sequence by process.parent.entity_id with maxspan=5m
  [process where event.type == "start" and
     process.parent.name in ("Runner.Worker", "Runner.Listener")]
  [process where event.type == "start" and
     process.name in ("make", "gmake") and
     process.args : "*refs/pull/*"]

This EQL sequence fires when a GitHub Actions runner worker spawns a make process operating on a pull-request merge ref — the execution pattern described in the NVD entry for CVE-2026-55563.

Splunk SPL Query

index=github sourcetype=github:audit action="workflows.completed_workflow_run" OR action="workflows.created_workflow_run"
| eval repo = coalesce(repo, repository)
| eval actor = coalesce(actor, user)
| lookup approved_forks actor OUTPUT trusted
| where isnull(trusted)
| stats count values(workflow_name) as workflows dc(actor) as actors by repo
| where count > 0
| sort - count

Companion query for label-persistence abuse — flag PRs where an approval label was added and a pushed event followed without an intervening unlabeled event:

index=github sourcetype=github:audit action="pull_request_review" OR action="pull_request"
| transaction pull_request_id maxspan=24h
| eval label_added = if(match(action,"labeled"),1,0)
| eval label_removed = if(match(action,"unlabeled"),1,0)
| eval code_pushed = if(match(action,"synchronize"),1,0)
| where label_added=1 AND code_pushed=1 AND label_removed=0
| table _time, repo, pull_request_id, actor, action

Wazuh OSSEC Rule

<group name="github,ci,cve-2026-55563,">
  <rule id="100563" level="12">
    <decoded_as>json</decoded_as>
    <field name="event">workflow_run</field>
    <field name="action">completed</field>
    <field name="workflow_name">pr_integration_tests</field>
    <field name="conclusion">success</field>
    <description>CVE-2026-55563: Privileged Feast PR integration workflow completed from fork-originated pull request</description>
    <mitre>
      <id>T1195</id>
    </mitre>
    <group>supply_chain,pci_dss_10.2.5,</group>
  </rule>

  <rule id="100564" level="14">
    <decoded_as>json</decoded_as>
    <field name="action">synchronize</field>
    <field name="pull_request_label">ok-to-test|approved|lgtm</field>
    <description>CVE-2026-55563: Commit pushed to approved PR with persistent authorization label - possible commit substitution</description>
    <mitre>
      <id>T1195</id>
    </mitre>
    <group>supply_chain,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source.

The NVD description states the issue is fixed in version 0.65.0, but no upstream advisory, commit SHA, release signature, or distribution artifact has been verified by the sources feeding this report. Treat the 0.65.0 reference as an unverified claim until it is confirmed against the project's own release notes and signed tags.

1) Immediate mitigations (apply before any upgrade is verified):

• Remove label trust entirely. Do not use ok-to-test, approved, or lgtm labels as authorization gates for jobs holding credentials. Require an explicit re-review action (for example, a maintainer-issued /run-tests comment) that is evaluated per-commit and cannot be satisfied by a prior label.
• Split the workflow by trust level. Run untrusted fork code only in a pull_request-triggered workflow with no secrets, read-only GITHUB_TOKEN, and no cloud credential injection. Move the credential-bearing integration tests to a workflow that runs only on trusted branch refs or on an explicit maintainer-triggered workflow_dispatch/workflow_call from the base repository.
• Do not check out attacker-controlled refs into privileged jobs. Where pull_request_target must be used, restrict all actions/checkout steps to base-repository refs and never fetch refs/pull/${{ github.event.pull_request.number }}/merge into a job with secrets.
• Replace long-lived cloud credentials with OIDC federation. Exchange short-lived, repository- and ref-scoped tokens with GCP Workload Identity Federation, AWS IAM OIDC roles, and Snowflake external OAuth. Apply subject conditions (repo:org/repo:ref:refs/heads/main) so a fork-originated run cannot assume the role even if it reaches the credential-exchange step.
• Add a label-removal automation. Deploy the external integration the NVD description notes was absent — on any synchronize event, strip ok-to-test, approved, and lgtm from the pull request. This restores the missing authorization recheck.
• Rotate and audit now. Any repository that met the vulnerable configuration should assume GCP, AWS, and Snowflake credentials used in its CI were exposed. Rotate them and review cloud audit logs for anomalous use of the CI service identities.

2) Patch / upgrade steps:

• Upgrade to Feast 0.65.0 or later once the release is independently verified from the project's canonical distribution channel. Verify package provenance and artifact signatures before deployment.
• Audit any forked or vendored copies of Feast's .github/workflows/ directory — the fix is in the workflow definition, so downstream forks inherit the vulnerability until they rebase or manually apply the corrected workflow.
• After upgrade, diff .github/workflows/pr_integration_tests.yml against the vulnerable revision to confirm the pull_request_target/synchronize/label-gating combination is actually gone rather than merely adjusted.

3) Long-term hardening:

• Adopt a policy that no workflow with secrets may execute code from an untrusted ref. Encode this as an organization-level ruleset and enforce it in CI configuration review.
• Enable GitHub Actions organizational policies restricting pull_request_target usage and require approval for workflow changes from forks.
• Enable full CI audit log streaming to the SIEM and alert on the label-add → push → no-label-removal pattern shown in the Elastic and Splunk queries above.
• Add secret scanning and credential-leak detection to CI output, and treat any CI job log containing credential material as an incident.
• Map CI service identities to least-privilege cloud roles and review those role bindings on a recurring schedule, not only at incident time.
• Pin all third-party Actions to full commit SHAs and review workflow files as security-relevant code in pull request review.

References

• NVD — CVE-2026-55563: https://nvd.nist.gov/vuln/detail/CVE-2026-55563
• CWE-863: Incorrect Authorization — https://cwe.mitre.org/data/definitions/863.html
• GitHub Docs — Security hardening for GitHub Actions (pull_request_target and script injection risks): https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
• GitHub Docs — Events that trigger workflows (pull_request_target and synchronize activity types): https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows
• MITRE ATT&CK T1195 — Supply Chain Compromise: https://attack.mitre.org/techniques/T1195/

Exploit-in-the-wild status: No public PoC, no exploit code, no Nuclei template, and no CISA KEV listing were observed for CVE-2026-55563 at time of writing. No threat actor campaign is associated with this CVE in available sources. The attack chain described in this report is inferred from the vulnerability class and the workflow semantics stated in the NVD description; it has not been validated against a working exploit.