CVE-2026-47852: Spring AI: predictable ONNX cache path enables model swap
HIGHSpring AI's ONNX model loader writes downloaded models to a deterministic, predictable cache path, letting a local low-privileged user on a shared host pre-create that file with a malicious ONNX model before the legitimate application caches the real one. There's no public exploit or scanner template, it isn't in CISA KEV, and EPSS data isn't available, so this reads as low-noise but high-consequence: any environment that runs Spring AI workloads on shared multi-tenant infrastructure (shared CI runners, multi-user inference boxes, PaaS with shared filesystem) is exposed to integrity compromise of the model actually executed, without any network-facing exploitation required. Affected versions span the full current release lines — Spring AI 1.0.0-1.0.9, 1.1.0-1.1.8, and 2.0.0. Patch to the fixed Spring AI release referenced in the vendor advisory, and in the meantime ensure ONNX model caches sit on per-tenant, non-shared storage with restrictive file permissions so an unprivileged co-tenant can't win the race to the cache path. Detection-wise, alert on unexpected file creation events in the model cache directory that precede the application's own download/write.
What is the risk?
CVSS 7.5 (High) driven by a High integrity impact with no confidentiality or availability loss — consistent with an attacker substituting the model artifact the application trusts rather than stealing data or crashing the service. The description clarifies this requires local access on a multi-user host (the network AV in the vector likely reflects the app's remote-facing role rather than the attacker's actual foothold requirement), which meaningfully narrows real-world exposure to shared/multi-tenant deployments — single-tenant, isolated hosts are effectively unaffected. No public exploit, no Nuclei template, no KEV listing, and no EPSS score exist yet, so opportunistic mass exploitation is unlikely; this is a targeted, insider/co-tenant risk rather than an internet-scanning risk.
How does the attack unfold?
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade Spring AI to the patched version referenced in the vendor advisory (spring.io/security/cve-2026-47852) for the 1.0.x, 1.1.x, and 2.0.x lines. 2) Until patched, avoid running Spring AI ONNX-caching workloads on shared multi-user hosts; isolate per-tenant/per-app filesystems (dedicated containers, non-shared cache directories with restrictive ownership/permissions, e.g. 0700 with a unique service account). 3) Pre-create the cache directory with correct ownership/permissions before deployment rather than letting the app lazily create it on first write. 4) Verify model integrity via checksum/signature comparison against the known-good source before load, independent of the caching layer. 5) Monitor and alert on file-creation events in the ONNX cache path that occur outside the application's own download flow — an unexpected pre-existing file at that path is the exploitation signature.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-47852?
Spring AI's ONNX model loader writes downloaded models to a deterministic, predictable cache path, letting a local low-privileged user on a shared host pre-create that file with a malicious ONNX model before the legitimate application caches the real one. There's no public exploit or scanner template, it isn't in CISA KEV, and EPSS data isn't available, so this reads as low-noise but high-consequence: any environment that runs Spring AI workloads on shared multi-tenant infrastructure (shared CI runners, multi-user inference boxes, PaaS with shared filesystem) is exposed to integrity compromise of the model actually executed, without any network-facing exploitation required. Affected versions span the full current release lines — Spring AI 1.0.0-1.0.9, 1.1.0-1.1.8, and 2.0.0. Patch to the fixed Spring AI release referenced in the vendor advisory, and in the meantime ensure ONNX model caches sit on per-tenant, non-shared storage with restrictive file permissions so an unprivileged co-tenant can't win the race to the cache path. Detection-wise, alert on unexpected file creation events in the model cache directory that precede the application's own download/write.
Is CVE-2026-47852 actively exploited?
No confirmed active exploitation of CVE-2026-47852 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-47852?
1) Upgrade Spring AI to the patched version referenced in the vendor advisory (spring.io/security/cve-2026-47852) for the 1.0.x, 1.1.x, and 2.0.x lines. 2) Until patched, avoid running Spring AI ONNX-caching workloads on shared multi-user hosts; isolate per-tenant/per-app filesystems (dedicated containers, non-shared cache directories with restrictive ownership/permissions, e.g. 0700 with a unique service account). 3) Pre-create the cache directory with correct ownership/permissions before deployment rather than letting the app lazily create it on first write. 4) Verify model integrity via checksum/signature comparison against the known-good source before load, independent of the caching layer. 5) Monitor and alert on file-creation events in the ONNX cache path that occur outside the application's own download flow — an unexpected pre-existing file at that path is the exploitation signature.
What systems are affected by CVE-2026-47852?
This vulnerability affects the following AI/ML architecture patterns: model serving, RAG pipelines, agent frameworks.
What is the CVSS score for CVE-2026-47852?
CVE-2026-47852 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.35%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.003ModelAML.T0018.002Embed MalwareAML.T0037Data from Local SystemCompliance Controls Affected
What are the technical details?
Original Advisory
A local attacker on a multi-user host can pre-create the deterministic cache path and plant a malicious ONNX model file. Spring AI 2.0.0 Spring AI 1.1.0 - 1.1.8 Spring AI 1.0.0 - 1.0.9
Exploitation Scenario
An attacker with a low-privileged account on a shared multi-user host — for example, a co-tenant on a shared CI/CD runner or a shared ML inference box — reverse-engineers or observes how Spring AI derives its ONNX model cache file path (e.g., a hash or naming scheme based on the model URL/identifier). Knowing the path is deterministic, the attacker pre-creates that exact file and populates it with a crafted malicious ONNX model before the legitimate Spring AI application ever downloads the real one. When the victim application later requests that model, it finds a file already present at the expected cache path, treats it as validly cached, and loads the attacker's model instead of the legitimate one — compromising the integrity of every inference result the application produces from that point forward, with no network interaction or user click required.
Weaknesses (CWE)
CWE-377 — DEPRECATED: Insecure Temporary File: This entry has been deprecated. It was focused only on the affected resource (temporary file) and not the behavior or mistake that produced the insecure temporary file, which caused confusion and incorrect mappings.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
Timeline
Related Vulnerabilities
CVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same attack type: Supply ChainCVE-2024-291210.0BentoML: RCE via insecure deserialization (CVSS 10)
Same attack type: Supply ChainCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same attack type: Supply ChainCVE-2025-512010.0smolagents: sandbox escape enables unauthenticated RCE
Same attack type: Supply ChainCVE-2026-2185810.0n8n: Input Validation flaw enables exploitation
Same attack type: Code Execution