# SAPwned: SAP AI vulnerabilities expose customers’ cloud environments and private AI artifacts

SAP AI Core's admission controller allowed shareProcessNamespace and UID 1337, bypassing Istio network isolation to reach unauthenticated Tiller, Loki, and EFS, enabling full cluster takeover and customer secret theft.

- Payout: Research
- Severity: critical
- Program: SAP AI Core
- Credited: Wiz Research
- Disclosed: 2024-07-17
- Write-up quality: 9/10
- Original: https://www.wiz.io/blog/sapwned-sap-ai-vulnerabilities-ai-security
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-sapwned-sap-ai-vulnerabilities-ai-security
- Tags: domain:cloud impact:data-leak impact:internal-access impact:privesc kind:research platform:threat-intel sev:critical tech:kubernetes technique:chained technique:recon vuln:auth-bypass vuln:misconfiguration

**Target:** Managed AI training platform (Kubernetes, Argo Workflows, Istio)
**Root cause:** Admission controller failed to block shareProcessNamespace and arbitrary runAsUser (UID 1337 = Istio), letting tenant pods escape Istio's iptables traffic restrictions; internal services (Tiller, Loki, EFS) trusted the internal network with no auth.
**Steps:**
1. Create AI project and submit Argo Workflow spawning a pod with `shareProcessNamespace: true` to read Istio sidecar config and its Istiod access token.
2. Set `runAsUser: 1337` (Istio's UID) so pod traffic is excluded from Istio iptables rules, removing network restrictions.
3. Scan internal network; query Istiod with stolen token for config.
4. GET Loki `/config` to retrieve AWS S3 secrets; list/read log bucket.
5. Mount 6 EFS shares on port 2049 unauthenticated via NFS tools; list customer-ID-organized datasets.
6. Query Tiller gRPC on port 44134 unauthenticated to read Docker Registry and Artifactory credentials.
7. Use Tiller `install` with a malicious Helm package spawning a cluster-admin pod for full cluster takeover.
8. Query cluster secrets to read customer AWS, HANA, Docker Hub, and GCR (`sap-docker-registry-secret`) credentials in plaintext.
**How found:** Team hypothesized AI platforms are prone to tenant isolation bugs since running models equals running code. They started with legitimate AI training, noticed the pod was network-restricted by an Istio sidecar, then tried 'interesting' pod privileges; admission controller blocked root but not shareProcessNamespace or runAsUser, and they noticed Istio's UID was 1337, excluded from iptables.
**Exploitation:** Starting as a low-privilege SAP customer, the attacker runs arbitrary code by design in an AI training pod, then abuses unblocked pod security settings to escape Istio network isolation. From the internal network they harvest unauthenticated secrets from Loki, EFS, and Tiller, then use Tiller's write access to deploy a cluster-admin pod, escalating to read/modify internal registries and steal all customer cloud credentials.
**Escalation:** Chained pod-level misconfig -> network isolation bypass -> unauthenticated internal service compromise -> cluster-admin via Helm/Tiller -> cross-tenant data access and supply-chain poisoning of Docker images/Artifactory builds.
**Insight:** When a sidecar enforces network policy, check whether the admission controller blocks shareProcessNamespace (leaks sidecar tokens/config) and arbitrary runAsUser — running as the sidecar's own UID often exempts you from its iptables redirect rules entirely.