Bug 2511118 (CVE-2026-18942)

Summary:	CVE-2026-18942 feast-operator: Feast: feast apply CronJob runs user Python with feature-server SA — tenant code to SA token escalation
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the Feast operator. A malicious tenant could inject arbitrary code into their feature repository. This code would be executed by an automated process with elevated privileges, allowing the tenant to steal sensitive credentials. This could lead to a direct escalation of privileges, granting the tenant administrative control over the Kubernetes cluster.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-04 17:51:58 UTC

Description

Finding
The operator builds a batch/v1.CronJob that mounts the user's feature repository and runs feast apply. feast apply (sdk/python/feast/repo_operations.py) imports every .py in the repo — arbitrary Python by design.

The CronJob runs as the same ServiceAccount as the long-lived feature-server Deployment:

cronjob.go:149 — ServiceAccountName: feast.initFeastSA().Name

matches services.go:459

No automountServiceAccountToken: false is set on the CronJob pod spec

File: infra/feast-operator/internal/controller/services/cronjob.go
Repository: red-hat-data-services/feast
K8s Top 10: K01
ASVS: V5.2.4
CWE: CWE-94 (Code Injection) / CWE-250 (Execution with Unnecessary Privileges)
Severity: High

Attack Chain
Tenant controls their FeatureStore CR's git source (feature repository)

Operator creates CronJob that runs feast apply on the repo content

feast apply imports all .py files — tenant code executes in the CronJob pod

CronJob pod has the feature-server SA token auto-mounted

Tenant code reads /var/run/secrets/kubernetes.io/serviceaccount/token

That SA is bound to a Role created by the operator via the cluster-wide RBAC verbs in F-02 (RHOAIENG-68304: Feast: Operator ClusterRole grants RBAC self-escalation, pods/exec, and cluster-wide secret read
Review
)

Tenant also gains the feature-server's network position and mounted store credentials (Redis/Postgres/S3)

Impact
A tenant who controls their feature repository content obtains the feature-server SA token on a recurring schedule (CronJob). Combined with F-02 (RHOAIENG-68304: Feast: Operator ClusterRole grants RBAC self-escalation, pods/exec, and cluster-wide secret read
Review
 — operator ClusterRole grants RBAC self-escalation, pods/exec, cluster-wide secrets), the chain from tenant-controlled git content to cluster-admin equivalent is direct.

Remediation
Run feast apply in a dedicated minimally-privileged SA with automountServiceAccountToken: false

Apply restricted securityContext to the CronJob pod

Restrict network egress to the registry endpoint only

Separate the CronJob SA from the feature-server SA