Quick answer
Direct answer
Risk scores
| CVSS metric | What it means |
|---|---|
| Attack vector (AV:A) | Adjacent network |
| Attack complexity (AC:L) | Low complexity |
| Attack requirements (AT:P) | Attack requirements present |
| Privileges required (PR:N) | No privileges required |
| User interaction (UI:N) | No user interaction |
| Confidentiality (VC:H) | High confidentiality impact |
| Integrity (VI:H) | High integrity impact |
| Availability (VA:H) | High availability impact |
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
About Ollama
CVE-2026-42248 affects Ollama, a product from Ollama. Before acting, confirm where Ollama runs in your estate, who owns it and whether it is reachable from the internet, because exposure decides real risk more than the score alone.
What the flaw is
In plain terms: Ollama for Windows does not perform integrity or authenticity verification of downloaded update executables. Unlike other platforms, the Windows implementation of the update verification routine unconditionally returns success so no digital signature or trust validation is performed before staging or executing update payloads, enabling attacker‑supplied executables to be accepted and later executed by the application. Critically, Ollama for Windows performs silent automatic updates, so the malicious payload may be installed automatically without user awareness. Maintainers of this project were notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Versions from 0.12.10 to 0.17.5 were tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.
Based on its CVSS vector, the flaw needs local or adjacent access, needs no login, and needs no user interaction. Apply the vendor fix and confirm exposure on internet facing and business critical assets first.
Affected versions and timeline
| Field | Detail |
|---|---|
| Product | Ollama |
| Affected versions | Ollama from 0.12.10 up to and including 0.17.5 |
| Published | Apr 29, 2026 |
| Last modified | Jun 17, 2026 |
| Added to CISA KEV | Not listed |
| Assigning CNA | cvd@cert.pl |
How to detect it
- Inventory every instance of Ollama and record the running version against the affected range above.
- Check external attack surface scans for internet facing instances of the component.
- Review logs on affected systems for unusual requests, errors or new processes around the vulnerable function.
- Confirm with an authenticated vulnerability scan once your scanner has a check for this CVE.
How to fix it
- Apply the fixed version of Ollama named in the vendor advisory.
- If patching must wait, restrict network access to the affected service and put it behind authentication or a web application firewall rule.
- Rescan after the change to prove the exposure is gone, then close the ticket.
CTEM action plan
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Add every business service that depends on Ollama to the current CTEM cycle. |
| Discover | Find all instances, including shadow and cloud deployments, and record versions and exposure. |
| Prioritize | Rank using EPSS and CVSS together with asset exposure and business impact. |
| Validate | Confirm the flaw is reachable and exploitable in your environment and that compensating controls work. |
| Mobilize | Assign the fix to the asset owner with a due date matched to the priority, then verify closure. |
CWE References
Technical References
Frequently asked questions
Related CVEs
Ollama for Windows contains a Remote Code Execution vulnerability in its update mechanism due to improper handling of attacker‑controlled HTTP response headers. When downloading updates, the application constructs local file paths using values derived from HTTP headers without validation. These values are passed directly to filepath.Join, allowing path traversal sequences (../) to be resolved and enabling files to be written outside the intended update staging directory. An attacker who can influence update responses can exploit this flaw to write arbitrary executables to attacker‑chosen locations accessible to the current user, including the Windows Startup directory. This allows execution of arbitrary executables. Critically, when chained with CVE‑2026‑42248 (Missing Signature Verification for Updates), an attacker can deliver malicious payloads that are written to sensitive locations and executed automatically. Because Ollama for Windows performs silent automatic updates and executes staged binaries without user interaction, this results in automatic and persistent code execution without user awareness. Maintainers of this project were notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Versions from 0.12.10 to 0.17.5 were tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.
Ollama 0.11.5-rc0 through current version 0.13.5 contain a null pointer dereference vulnerability in the multi-modal model image processing functionality. When processing base64-encoded image data via the /api/chat endpoint, the application fails to validate that the decoded data represents valid media before passing it to the mtmd_helper_bitmap_init_from_buf function. This function can return NULL for malformed input, but the code does not check this return value before dereferencing the pointer in subsequent operations. A remote attacker can exploit this by sending specially crafted base64 image data that decodes to invalid media, causing a segmentation fault and crashing the runner process. This results in a denial of service condition where the model becomes unavailable to all users until the service is restarted.
FastGPT is an AI Agent building platform. In versions 4.14.8.3 and below, the fastgpt-preview-image.yml workflow is vulnerable to arbitrary code execution and secret exfiltration by any external contributor. It uses pull_request_target (which runs with access to repository secrets) but checks out code from the pull request author's fork, then builds and pushes Docker images using attacker-controlled Dockerfiles. This also enables a supply chain attack via the production container registry. A patch was not available at the time of publication.
MOOS essential-moos pAntler through 10.0.1 contains a remote code execution vulnerability that allows unauthenticated attackers to execute arbitrary programs by publishing a crafted MISSION_FILE message to the MOOSDB. Attackers can publish a mission file containing malicious Run entries that pAntler parses and executes via execvp() without authentication validation.
The Angular Language Service VS Code Extension provides a rich editing experience for Angular templates. Prior to 21.2.4, the client-side Angular Language Service VS Code extension reads the custom TypeScript SDK paths typescript.tsdk and js/ts.tsdk.path directly from workspace configurations (.vscode/settings.json) without verifying VS Code Workspace Trust state or asking for user consent (located in client/src/client.ts). The client-side extension then passes the parsed settings path as a command-line argument (--tsdk) to the background Node.js language server process. During server initialization, the background language server resolves and dynamically imports (via standard Node.js require()) the module library tsserverlibrary.js relative to the workspace-specified custom directory path. An attacker can exploit this behavior by committing a repository containing a local malicious tsserverlibrary.js script inside a custom folder, and a crafted .vscode/settings.json file pointing to that folder. When a developer opens the repository folder in VS Code, the extension automatically attempts to initialize and load the server, which dynamically resolves, loads, and executes the malicious script silently in the background. This vulnerability is fixed in 21.2.4.
Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. An exception like NoHttpResponseException can indicate transient errors. If the errors persist after a maximum number of retries, Gradle would continue to the next repository. This behavior could allow an attacker to disrupt the service of a repository and leverage another repository to serve malicious artifacts. This attack requires the attacker to have control over a repository after the disrupted repository. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like CVE-2026-42248 with a free CTEM certification.
Beginner / Practitioner / Program Leader
Explore certifications