SAP CAP multitenancy: unauth request wyciąga credentials, a potem nimi zastępuje lub usuwa tenant data — kiedy biblioteka NPM staje się cross-tenant control-plane findingiem

8 września 2026 SAP opublikował Security Note 3798315 dla CVE-2026-76969 (@sap/cds-mtxs, Critical 9.4). Affectedness nie zależy wyłącznie od tego, czy package jest w package-lock.json — podatność dotyczy multitenant CAP applications with extensibility enabled. Potrzeba trójwymiarowego modelu: package/version + multitenancy + extensibility enabled.

CVE-2026-76969 (CVSS AV:N/AC:L/PR:N/UI:N/C:L/I:H/A:H): unauthenticated crafted request → niewystarczające kontrole w cds-mtxs → sensitive credentials disclosed → reuse → replace/delete tenant data.

Affected: ≤1.18.3, ≤2.7.6, ≤3.9.6, ≤4.0.2 (SAP Note); GHSA na moment analizy niepełne/unreviewed.

Pierwszy impact ≠ final impact

Credentials nie są celem — są środkiem: unauth request → insufficient check → credentials disclosed → reused → tenant data replace/delete. Dlatego C:L, ale I:H/A:H — credential disclosure nie zawsze oznacza C:H; znaczenie sekretu ujawnia to, co pozwala zrobić dalej. Lokalny risk: ilu tenantów na instancję, czy credential scope jest tenant-specific czy szerszy, regulatory/high-value tenants, backup/restore, czy deletion jest odwracalne.

SCA widzi package, VE feature state

package: "@sap/cds-mtxs" cap_multitenancy: true/false extensibility_enabled: true/false public_reachability: true/false tenant_count: ...

Jeśli extensibility wyłączone, warunek podatnego feature path może nie być spełniony — silny enrichment do triage (ale nie automatyczny VEX not_affected bez potwierdzenia/testu). GHSA bywa spóźniony (GHSA → normalized npm package → affected range potrzebuje czasu), więc primary vendor advisory jest szybszym i precyzyjniejszym źródłem. I nie zgaduj fixed version z affected upper bound (1.18.4 itp.) — remediation reference to SAP Note 3798315.

Multitenancy zmienia jednostkę impactu

Zamiast asset = app instance — graf CAP instance → tenant A/B/C…. Przy szerszym credential scope jeden finding reprezentuje ryzyko dla wielu klientów: 1 vulnerable workload → 500 tenant data domains. Blast radius nie liczy się w hostach.

Remediacja, rotacja i weryfikacja

Podstawa: SAP Note 3798315. Bez natychmiastowego patcha (jeśli vendor potwierdza, że usuwa attack path): ograniczyć reachability, wyłączyć extensibility, zawęzić credential privileges, odseparować tenant management plane, monitorować nietypowe operacje na tenant data. Po ekspozycji: potencjalnie ujawnione credentials mogą nadal być ważne → patch + review telemetry + rotate/revoke (vulnerability vs compromise remediation). Weryfikacja: runtime package version, wszystkie deploymenty CAP, brak starych pod/images, feature state, w K8s image updated ≠ all old pods terminated. Brak potwierdzonej active exploitation — nie podnoś statusu tylko dlatego, że PR:N/AC:L wyglądają groźnie.

Wniosek

CVE-2026-76969 pokazuje, jak niewielki package może być częścią krytycznego multitenant control plane. Dopiero po dodaniu multitenancy, extensibility, reachability, credential scope i liczby tenantów „9.4” staje się realnym priorytetem.

Powiązane na blogu

Ceph: read-only do root — credential transitivity i blast radius
Budibase: admin aplikacji ≠ root — efekt sekretu, nie etykieta

Źródła

SAP — Security Patch Day September 2026, Note 3798315 (08.09.2026) — support.sap.com
GitHub Advisory Database — GHSA-955m-rr6m-2f9v / CVE-2026-76969 — github.com/advisories

Nota redakcyjna: stan informacji 8 września 2026. CVE-2026-76969 (@sap/cds-mtxs, CVSS 9.4): w multitenant CAP z extensibility unauth request ujawnia credentials umożliwiające replace/delete tenant data. Artykuł koncentruje się na configuration-aware affectedness i blast radius liczonym w tenantach.