Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
Striga and CERT Polska documented a chained flaw in Ollama for Windows 0.12.10 through 0.22.0: attacker-influenced update responses could provide malicious ETag or Content-Disposition path values, the updater could write a payload outside its staging directory such as the Windows Startup folder, Windows signature verification was a no-op, and the payload could run persistently on later logins. Ollama first shipped the hardened update flow in v0.23.3.
ASSESSED SYSTEM
Representative configuration: an Ollama for Windows desktop installation in an affected release (0.12.10 through 0.22.0) on a user workstation, whose tray application checks for updates in the background, stages downloaded installers, and runs pending updates silently at startup, where an attacker can influence the update response that reaches the client. Scored in the pre-fix state, before the hardened update flow shipped in v0.23.3.
OUT OF SCOPE
Ollama on other operating systems and releases from v0.23.3 onward; the means by which an attacker gains influence over the update response (Striga's demonstration used an update URL override), which is a precondition rather than an assessed control; the local models served by Ollama, which are not modified; post-exploitation payloads such as stealers, droppers, or reverse-shell tooling, which are attacker tooling; and privilege escalation beyond the current user, which is not described.
Architecture: Standalone LLM / Generative AI (decision tree Q5) — Host-inheritance rule: the architecture is that of the AI workload the component serves. Ollama is a local runtime that serves generative language models; the record describes no inference-time retrieval, tool or function calling, autonomous planning, or agent coordination inside the assessed boundary, so Q1-Q4 resolve NO and Q5 resolves YES. The updater compromise enters as Ro-4 artifact-admission evidence and as Containment, As, and Cp evidence. Tier 3: Tier 3 Internal: a desktop local-model runtime on an individual user's workstation that does not serve the public; the persistent user-level code execution reaches that workstation's data and credentials, but the assessed system has no public-facing decision authority.
Documented attack or failure path
- The attacker studies the affected Ollama for Windows update path: the tray application checks for updates in the background, stages downloaded installers, and can run pending updates silently when it starts from the Windows Startup folder.
- An attacker able to influence the update response returns a malicious installer body and controlled HTTP metadata; Striga's demonstration used an update URL override, while the flaw applied to any attacker-controlled response that reached the client.
- The updater derived the local staging path from the HTTP ETag and Content-Disposition values and passed them to filepath.Join without checking that the resolved path remained inside the staging directory.
- A traversal value writes the payload into the user's Windows Startup folder, outside the updater staging tree.
- The Windows verifyDownload routine returned success and DoUpgradeAtStartup did not re-verify the staged installer, so the unsigned payload was neither rejected nor removed.
- On a later login Windows launches the dropped executable as the current user, giving the attacker persistent user-level code execution until the file is removed.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The dropped payload ran as the current user: the traversal could write only to paths the current user can write, and the record describes user-level execution with no elevation beyond that account.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–0.80 (midpoint 0.40), Tier 3 MVT 0.40 indeterminate | |||
| Ro-5Supply-Chain Artifact Admission Integrity | 0.00w 0.20 | The 0.00 anchor: an executable update artifact was admitted with no effective signature, hash or provenance verification - the only verification step was a no-op. The 0.25 anchor requires pinning or allow-listing for at least some artifact classes, and none is evidenced on the update channel. (Moved from Ro-4; the evidence concerns admission of an unverified executable artifact, not content poisoning.) | In affected releases 'the Windows verifyDownload routine returned success without verifying the download, and DoUpgradeAtStartup did not re-verify the staged installer', so an unsigned attacker payload delivered through the update response 'was neither rejected nor removed' and ran persistently on later logins. The runtime's own update artifact was admitted on the strength of the HTTP response alone.source: secureflow |
| Fairness (Fa) NOT APPLICABLE — axis-level applicability rule (Person-Outcome Surface test): The assessed system is the Ollama for Windows local serving runtime's auto-update path, whose outputs are staged installer files and startup execution on a user workstation; the updater allocates, ranks, classifies or describes no natural person and no protected-class attribute or proxy in the update-response inputs influences that outcome. Its tier weight is redistributed across the remaining axes and its MVT is not evaluated. | |||
| Transparency (Tr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate | |||
| Containment (Cn) — scenario interval 0.03–0.91 (midpoint 0.47), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.12 | The 0.25 anchor: a basic boundary exists (a dedicated update staging directory, bounded by the current user's write permissions) but parameter manipulation through response headers exceeded the intended scope. The 0.50 anchor requires core scope controls that block common violations such as path traversal, and none operated. | The updater derived its local staging path from attacker-influenced HTTP ETag and Content-Disposition values and passed them to filepath.Join without checking that the resolved path stayed inside the staging directory, so a traversal value wrote the payload into the user's Windows Startup folder, from which it launched on later logins.source: secureflow |
Unknown, not N/A: 20 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Architecture-based NOT APPLICABLE: excluded with the Fairness axis.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.20 | The updater checks, downloads, stages, and silently runs pending updates at startup without per-update user confirmation, executing a routine action autonomously within a pre-defined boundary; it makes no other consequential decisions, so 0.75 is not supported. |
| AsAttack Surface Exposure | 0.75w 0.25 | The client ingests update responses, including installer bodies and HTTP metadata, from an external network source, and the flaw applied to any attacker-controlled response that reached it; that source is partially trusted, and no multi-agent or MCP surface supports 1.00. |
| CpCascade Potential | 1.00w 0.30 | No verified System Dependency Graph with DGC at least 0.90 is public for this boundary, so the specification's worst-case graph default governs rather than an assessor-estimated blast radius.GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.00w 0.25 | Deterministic fix: Ollama first shipped a hardened update flow in v0.23.3, a software update that changes no model. Removing a payload already dropped in the Startup folder is a host clean-up step, not a model change. It does not assert fleet-wide closure. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.35 | The public record identifies the representative configuration, attack path, and principal control boundaries, but does not provide a complete asset manifest, verified dependency graph, configuration export, or assessment evidence manifest. |
| Ec — Public evaluation coverage | 0.08 | coverage 0.09 (2 of 22 applicable sub-metrics) × independence 1.00 × fidelity 0.85. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.52 | Evidence dated 2026-04-29; age 172 days on the workpaper reference date. Components: T_calendar 0.52 · C_monitor 0.65 · C_event 0.65 · C_evidence 0.85. Binding term: T_calendar. Evidence age is measured from the Striga disclosure dated 2026-04-29 to the 2026-10-18 evidence reference date. C_monitor 0.65: no client-side detection of the traversal or unsigned payload is described. C_event 0.65: no in-the-wild exploitation is reported. C_evidence 0.85: closure depends on each installation updating to the hardened release and removing any dropped payload, which the public record cannot confirm. agentic = false and baw = false: the local runtime has no runtime tool, credential, memory, or configuration mutation inside the boundary. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.24 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
3.5 midpoint, interval 1.2–5.8; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS · 2 records
CVE-2026-42248 CVSS 4.0 Base 7.7 High
| Published score | 7.7 |
|---|---|
| CVSS version | 4.0 |
| Metric group | Base |
| Severity | High |
| Vector | CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L |
| Scored by | CERT-PL |
| Source record | https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/42xxx/CVE-2026-42248.json (accessed 2026-10-18) |
| Affected component | Ollama |
| Scope note | CNA affected product and described vulnerability match the scored assessed_system and are not excluded by out_of_scope. |
| Record SHA-256 | c0e4764901f25c117931faaf862842f8403f3f6d82f44a736c46327af9badd19 |
CVE-2026-42249 CVSS 4.0 Base 7.7 High
| Published score | 7.7 |
|---|---|
| CVSS version | 4.0 |
| Metric group | Base |
| Severity | High |
| Vector | CVSS:4.0/AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L |
| Scored by | CERT-PL |
| Source record | https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/42xxx/CVE-2026-42249.json (accessed 2026-10-18) |
| Affected component | Ollama |
| Scope note | CNA affected product and described vulnerability match the scored assessed_system and are not excluded by out_of_scope. |
| Record SHA-256 | e3de2637ed5e0171d5d5e45682f64e2395467785ba58025062df6049abefc2ea |
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-D-004.001 | Static Artifact Integrity Re-verification & Drift MonitoringExact SecureFlow defense-map identifier (flow aidefend-research-sf0023-ollama-windows-auto-update-persistent-rce), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-4. Presence supplies no score credit. | Candidate evidence route | Ro-5 Tr-3 Cn-7 Cn-9 |
| AID-H-003.010 | Deployed AI Software Vulnerability Remediation LifecycleExact SecureFlow defense-map identifier (flow aidefend-research-sf0023-ollama-windows-auto-update-persistent-rce), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | Ro-4 Ro-5 Tr-4 |
| AID-E-004 | Incident Exploit-Path Closure VerificationExact SecureFlow defense-map identifier (flow aidefend-research-sf0023-ollama-windows-auto-update-persistent-rce), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | ACI:C_event recovery ACI:containment/behavioral re-attestation |
| AID-E-003.003 | Confirmed Malicious Code & Persistence EvictionExact SecureFlow defense-map identifier (flow aidefend-research-sf0023-ollama-windows-auto-update-persistent-rce), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-7. Presence supplies no score credit. | Candidate evidence route | Ro-4 |
WHAT THIS CASE TEACHES
A local AI runtime's updater is part of its supply chain: a no-op signature check and an unconstrained staging path place the case at Ro-5 = 0.00 and Cn-1 = 0.25 without any model being touched, while a deterministic vendor fix keeps Rf at 0.00.
Sources: AIDEFEND SecureFlow — Ollama Windows Auto-Update Persistent RCE · Ollama Updates Itself Into Persistent RCE on Windows (Striga) · Vulnerabilities in Ollama software (CERT Polska) · CVE-2026-42248 Detail (NVD) · CVE-2026-42249 Detail (NVD) · app: harden update flows (#16100) (Ollama)
SecureFlow attack flow
This record mirrors an AIDEFEND SecureFlow flow (AIDEFEND curated research flow): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.
| Primary research | Striga and CERT Polska (2026-04-29) |
|---|---|
| Primary evidence date | 2026-04-29 |
| SecureFlow record updated | 2026-07-07 |
| AI layers | AI supply chain, Edge and client AI |
| Risk impact | System compromise / RCE, Model poisoning / integrity |
| Affected components | Ollama for Windows updater, update check and download response handling, ETag and Content-Disposition path construction, update staging directory, Windows Startup folder, Windows verifyDownload routine |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Profile Silent Windows Updater PathThe attacker studies the disclosed Ollama for Windows desktop update path in affected releases: the tray application checks for updates in the background, stages downloaded installers, and can run pending updates silently when the application starts from the Windows Startup folder. | AML.TA0002 AML.T0010.001 |
| 2 | Serve Attacker-Controlled Update ResponseAn attacker who can influence the update response returns a malicious installer body and controlled HTTP metadata to an affected updater. Striga's demonstration used an update URL override, while the underlying flaw applied to any attacker-controlled update response that reached the vulnerable client. | AML.TA0003 AML.T0010.001 |
| 3 | Traverse Staging Path Through Response HeadersIn affected releases, the updater derived the local staging path from HTTP ETag and Content-Disposition values and passed them to filepath.Join without checking that the resolved path remained inside the intended update staging directory. | AML.TA0005 AML.T0010.001 |
| 4 | Write Payload Into Windows Startup FolderA traversal value such as a relative path to the user's Windows Startup folder causes the downloaded payload to be written outside the updater staging tree to an attacker-chosen path that the current user can write. | AML.TA0006 AML.T0112.000 |
| 5 | Accept Payload Because Windows Verification Is No-OpIn affected releases, the Windows verifyDownload routine returned success and DoUpgradeAtStartup did not re-verify the staged installer, so the unsigned attacker payload was neither rejected nor removed after the write. | AML.TA0007 AML.T0010.001 |
| 6 | Launch Payload on User LoginOn a later login, Windows enumerates the Startup folder and launches the dropped executable as the current user, giving the attacker code execution without Ollama needing to find the payload in its normal update staging directory. | AML.TA0005 AML.T0112.000 |
| 7 | Maintain Persistent User-Level Code ExecutionThe dropped executable persists until removed from Startup. The attacker retains recurring user-level execution and can run realistic payloads such as stealers, droppers, or reverse-shell tooling. | AML.TA0006 AML.T0112.000 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=aidefend-research-sf0023-ollama-windows-auto-update-persistent-rce; AIDEFEND content CC BY 4.0).