Description

Finding
MaterializeRequest.feature_views is Optional[List[str]] = None (line 86). When the client omits this field, the permission-check loop iterates zero times — assert_permissions is never called — and store.materialize(..., None) materializes every feature view in the project. The same flaw exists for /materialize-incremental (lines 624-638).

File: sdk/python/feast/feature_server.py:593-638
Repository: red-hat-data-services/feast
ASVS: V4.1.3, V4.2.1 (function-level access control)
CWE: CWE-285 / CWE-862 (Missing Authorization)
Severity: High

RHOAI Impact
This affects RHOAI deployments. The /materialize and /materialize-incremental endpoints are part of the feature server deployed by the feast-operator in RHOAI. The vulnerable code ships in the RHOAI feature-server image.

Denial of Service attack: An attacker can trigger full re-materialization of all tenants' feature views by sending a simple POST /materialize request with the feature_views field omitted. This:

Overwrites online-store state — corrupting or replacing current feature data for all tenants

Incurs significant offline-store compute cost — re-reading and processing all historical data

Can be repeated indefinitely — no rate limiting or cooldown exists on the endpoint

Affects all tenants — the feature server serves all projects in a FeatureStore CR

Auth dependency:

With default no_auth (F-04, also the operator default): unauthenticated — anyone with network access can trigger this

With kubernetes/oidc auth enabled: any authenticated user can trigger it regardless of their Feast permissions, since the authz check loop runs zero times

Remediation
When feature_views is None, enumerate store.list_feature_views() and assert WRITE_ONLINE on each before calling store.materialize. Reject the request if the caller lacks permission on any view.