CVE-2026-55563: Feast: `pull_request_target` integration tests run untrusted fork code with production cloud secrets; the `ok-to-test` label guard is bypassable via label persistence on `synchronize`
Feast is the open source feature store for AI and machine learning. Prior to 0.65.0, .github/workflows/printegrationtests.yml uses pullrequesttarget with the synchronize event and preserves ok-to-test, approved, or lgtm labels across newly pushed commits, allowing a fork contributor to obtain approval for a benign revision and then run changed code from refs/pull/${{ github.event.pullrequest.number }}/merge through privileged make targets. The job exposes GCP, AWS, and Snowflake credentials to that code, enabling runner code execution, credential disclosure, and possible access to downstream cloud resources. An external label-removal integration could mitigate the condition, but no repository workflow provided that protection. This issue is fixed in version 0.65.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.65.0
Event History
Frequently Asked Questions
Which repositories are exposed to this issue?
Feast repositories using versions prior to 0.65.0 are exposed when their PR integration-test workflow uses pull_request_target on synchronize events, checks persistent ok-to-test, approved, or lgtm labels, and makes cloud credentials available to the job. Fork-based pull requests are the relevant attack path.
What does an attacker need to exploit the workflow?
An attacker needs to submit a fork pull request that receives an allowed label for a benign revision, then push a new commit to the same pull request. Because the label persists on synchronize, the changed fork code can run through privileged make targets using the pull request merge ref.
What access could an attacker obtain?
The untrusted code can execute on the runner and access the GCP, AWS, and Snowflake credentials exposed to the job. This can lead to credential disclosure and possible access to downstream cloud resources permitted by those credentials.
What can be done if upgrading is not immediately possible?
An external integration that removes the approval labels when new commits are pushed can mitigate the condition. The affected repository workflow did not include that protection, so do not rely on the existing label guard alone.
How can I determine whether the issue has been remediated?
Upgrade Feast to version 0.65.0. For older deployments, review the PR integration-test workflow for pull_request_target with synchronize and persistent ok-to-test, approved, or lgtm labels, particularly where GCP, AWS, or Snowflake credentials are available to the job.