The CVSS 8.5 rating for CVE-2026-18947 is misleading. This is not a commodity denial-of-service — it's a multi-tenant data-integrity weapon where the authorization bypass works specifically because omitting the feature_views parameter collapses the permission model into a default-allow state. The endpoint interprets 'no feature views specified' as 'materialize everything,' which is a design-level flaw, not merely an implementation bug.
The technical mechanism deserves scrutiny. Feast's materialization API treats absence of specification as implicit wildcard permission rather than explicit denial. When a caller omits feature_views, the operation executes against all feature views across all tenants. The privilege escalation isn't about what you can access — it's about what you can silently overwrite. That distinction is the key to understanding why this vulnerability deserves separation from typical DoS CVEs.
The real detonation path runs through your ML inference pipelines. Feast materialization writes feature data that downstream models consume for real-time predictions. Forced mass re-materialization doesn't just consume resources — it overwrites the feature store state that your fraud detection, recommendation engines, and credit scoring models depend on. Corrupted feature state propagates silently into every prediction made during the contamination window. You discover the compromise when your recommendations start failing in production, not when the attack occurs. That's a detection gap that compounds severity far beyond what CVSS captures.
The multi-tenant dimension amplifies this further. A single unauthenticated request can trigger cross-tenant resource starvation and data corruption. If Feast's shared feature store architecture means one tenant's corrupted materialization bleeds into shared feature views that other tenants' models consume, the attack becomes adversarial contamination of prediction infrastructure that victims have no visibility into.
Three operational priorities: First, verify whether your Feast deployment maintains tenant isolation at the storage layer or whether materialized features are shared across tenants. Second, audit your logging to determine if you can distinguish attacker-triggered mass re-materialization from legitimate jobs — if not, you have an observability debt problem that predates this CVE. Third, assume the batch and streaming materialization variants share this parameter-omission vulnerability until proven otherwise; this pattern clusters across endpoints that share authorization abstractions.