CVE-2026-18948

The CVSS 9.9 score for this CVE conflates two distinct attack paths, and the 'unauthenticated RCE' label is misleading. Feast separates the registry (where UDFs are stored) from the feature server (where UDFs execute). The registry backed by PostgreSQL, GCS, S3, or file storage does not expose unauthenticated write APIs by default. To inject a malicious dill-serialized UDF, an attacker must first gain write access to the registry storage layer itself—which is a separate trust boundary that CVSS treats as ambient but in practice requires its own compromise. The feature server only pulls UDFs from the registry; it doesn't expose a write surface to unauthenticated actors. What matters practically: verify your registry backend enforces authentication and that the feature server cannot be redirected to a registry under attacker control. The 9.9 score is defensible as a worst-case composite, but it overstates the realistic unauthenticated surface. The real risk is that a single registry compromise poisons every tenant simultaneously, with the malicious UDF executing on every feature request until remediated—persistent, invisible, and tenant-wide. This is the pattern to watch: ML tooling repeatedly makes the same 'trusted environment' tradeoff with serialization libraries (dill, pickle, cloudpickle) because they solve real engineering friction. Expect similar issues in other feature stores and ML platforms. Prioritize locking down the registry-to-feature-server trust boundary and audit any configuration that allows the feature server to pull UDFs from external or shared registries.

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