# Ollama: model import is a separate memory and access boundary

Model-management permissions can be more sensitive than inference permissions. A shared service should establish who may import, create, quantize and export models, alongside who may submit prompts.

## Which deployment does this concern?

The record concerns attacker-controlled GGUF tensor offsets and sizes processed during model creation/quantization. It is not a finding that an ordinary prompt in every local Ollama installation exposes memory.

**Affected scope:** The reviewed registry identifies versions before 0.17.1. Exploitation depends on supplying a malformed GGUF to the affected model-creation path; the reported export scenario also uses model push.

## Response and remediation evidence

Upstream PR #14406 validates expected tensor sizes during model creation. The registry identifies 0.17.1 as patched. The linked release is dated 24 February while the PR merge is dated 25 February; those records alone do not prove that a particular 0.17.1 artifact contains the change.

**Remediation record:** Registry patched-version field: 0.17.1. Confirm inclusion of the upstream tensor-size fix in the deployed artifact.

## What clients can learn

Patch the affected path with artifact-level evidence, restrict model-management operations and keep the service on approved networks. A gateway access policy supports admission but cannot repair an inference runtime’s model loader.

Keep an endpoint inventory, the effective configuration and the running artifact together. A configuration or model change should trigger a review of the boundary it changes. Assign an owner to the evidence and to any required action.

## Questions for your provider

- Can application users invoke create, import, quantization or push operations?
- What installed artifact and commit establish the tensor-size fix?
- Does the local service remain on loopback or have an authenticated network boundary?
- Are model sources and export destinations approved separately?

Use the [inference guide](/resources/llm-inference-security-and-operations) and [evaluation worksheet](/assets/downloads/ai-gateway-evaluation-worksheet.pdf) to record the answer in your deployment context.

### Technical detail: source scope and identifiers

The registry’s version field is attributed to the registry. This documentary review did not reproduce the reported memory disclosure or verify every release artifact.

- Finding identifier: GHSA-x8qc-fggm-mpqg; CVE mapping: CVE-2026-7482.
- Preserve the registry’s 0.17.1 patch statement alongside the upstream release/merge chronology. Request build or backport evidence rather than widening an affected range or declaring the artifact verified.

## Primary and supporting records

- [GHSA-x8qc-fggm-mpqg / CVE-2026-7482 · reviewed registry record](https://github.com/advisories/GHSA-x8qc-fggm-mpqg)
- [Upstream tensor-size validation, PR #14406](https://github.com/ollama/ollama/pull/14406)
- [Upstream v0.17.1 release](https://github.com/ollama/ollama/releases/tag/v0.17.1)
- [Local versus cloud API authentication](https://docs.ollama.com/api/authentication)
- [Network binding and deployment settings](https://docs.ollama.com/faq)

---
Published: 2026-10-07. Modified: 2026-10-07. Sources reviewed: 2026-10-07.

Author: OneQuill Research. Affiliation: OneQuill develops OneVir. Documentary review; selected case totals are not vendor security rankings.