CVE-2026-18941

CVE-2026-18941 isn't a configuration mistake. It's a design philosophy failure: Feast's 'no_auth' default treats authentication as optional rather than foundational, making it a feature store that ships insecure by design. This matters because Feast occupies a structurally privileged position in ML infrastructure—sitting between data engineering, training pipelines, and online inference—with cross-tenant data access baked into its architecture. Three attack vectors compound the severity. Malicious UDF storage achieves RCE through the feature-server's legitimate API path, weaponizing a core capability. Forced re-materialization exhausts tenant resources through an intended workload feature. Cross-tenant data access isn't a bug—it's structurally enabled when authentication is absent. The feast-operator dimension elevates this from an application compromise to a cluster-wide risk. Kubernetes operators typically run with elevated cluster permissions to manage Custom Resources. When feast-operator accepts no_auth, it exposes permissions that likely include namespace-wide resource creation, modification, and deletion. An RCE on the feature-server gives you ML data; an RCE on the operator potentially gives you cluster-admin-equivalent access through an undocumented trust path. The CVSS 7.7 score measures exploitability, not blast radius. A feature store with cross-tenant access and operator-level permissions has a detonation radius that exceeds what CVE metrics capture. The supply-chain positioning of Feast—feeding models across multiple tenants—means compromise extends into training data pipelines and feature engineering intellectual property, with the added concern that forced re-materialization can poison future model iterations. Beyond patching, examine your Feast deployment holistically: verify whether feast-operator runs with cluster-scoped permissions and whether those permissions are genuinely necessary; audit historical usage of no_auth tutorials, Terraform modules, and StackOverflow configurations that may have propagated the permissive default across your infrastructure; and treat the authenticated code paths with heightened scrutiny—paths that see less real-world traffic due to no_auth defaults may have atrophied. The window between when no_auth became documented default and this CVE's issuance represents accumulated exposure time with no exploitation audit trail. Assume that window was open longer than the disclosure timeline suggests.

Reviewed through automated stages and approved by a human before publication.