Skip to content

CVE-2026-7482 - Ollama GGUF memory disclosure

Ollama before 0.17.1 contains a heap out-of-bounds read in GGUF model loading. A malicious GGUF file can declare tensor offsets and sizes that exceed the actual file length. When the vulnerable server processes that model during creation or quantization, it can read beyond the intended heap buffer.

This is a secure-context issue, not only a model-server dependency issue. GitHub’s advisory notes that exposed memory may include environment variables, API keys, system prompts, and other users’ conversation data. The same deployment often also gives the server a model push path, so the remediation needs to address both the vulnerable version and unauthenticated access to model creation and push endpoints.

Affected versions

  • Vulnerable: Ollama <0.17.1
  • Fixed: Ollama 0.17.1+
  • High-risk exposure: Ollama is reachable by untrusted users and permits unauthenticated or weakly authenticated access to model creation or push routes, especially when OLLAMA_HOST=0.0.0.0 or equivalent bind settings expose the service beyond loopback.

Indicator-of-exposure

  • The repository builds, installs, packages, configures, or deploys Ollama.
  • A deployable binary, container image, package pin, installer, or SBOM resolves Ollama <0.17.1.
  • Docker, Compose, Kubernetes, systemd, Terraform, Ansible, Nix, shell scripts, or runbooks set OLLAMA_HOST=0.0.0.0, publish the Ollama port, or place Ollama behind an ingress, reverse proxy, agent gateway, workspace gateway, or MCP-adjacent service.
  • Untrusted users, agents, notebooks, CI jobs, web applications, or automation can reach model creation, model import, or model push workflows.
  • The Ollama process has environment variables or mounted files containing model-provider keys, registry tokens, internal service credentials, system prompts, tenant context, or conversation data.

Quick checks:

# macOS / Linux
rg -n "ollama|OLLAMA_HOST|/api/create|/api/push|GGUF|Modelfile|ollama/ollama" .
rg -n "0\\.17\\.0|0\\.16\\.|0\\.15\\.|ollama[:/@]|OLLAMA_HOST=0\\.0\\.0\\.0" Dockerfile* docker-compose*.yml .github charts deploy k8s manifests systemd scripts docs 2>/dev/null
ollama --version
docker image ls | rg "ollama"

# Windows PowerShell
Get-ChildItem -Recurse -File | Select-String -Pattern "ollama|OLLAMA_HOST|/api/create|/api/push|GGUF|Modelfile|ollama/ollama"
Get-ChildItem -Recurse -File -Include Dockerfile*,docker-compose*.yml,*.yaml,*.yml,*.ps1,*.md | Select-String -Pattern "0\.17\.0|0\.16\.|0\.15\.|ollama[:/@]|OLLAMA_HOST=0\.0\.0\.0"
ollama --version
docker image ls | Select-String "ollama"

Remediation strategy

  • Upgrade every controlled Ollama install, image, package recipe, base image, workstation bootstrap, and deployment manifest to 0.17.1+; prefer the latest available patched release.
  • Regenerate lockfiles, image digests, SBOMs, checksums, rendered manifests, golden deployment output, and version evidence for every path that ships Ollama.
  • Bind Ollama to loopback or private service networks by default. Do not expose OLLAMA_HOST=0.0.0.0 to untrusted networks without an authenticated gateway, allow-list, and explicit route policy.
  • Restrict model creation, model import, and model push workflows to trusted administrators or controlled automation. Block unauthenticated access to /api/create, /api/push, and any equivalent proxy route.
  • Allow-list trusted model sources and registries. Prefer digest-pinned models and signed or provenance-checked model artifacts for production deployments.
  • If exposure was possible, rotate model-provider keys, model registry tokens, service credentials, API keys, and other secrets present in the Ollama process environment. Treat untrusted model artifacts created during the window as suspect.

The prompt 

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-7482 / GHSA-x8qc-fggm-mpqg (Ollama GGUF
out-of-bounds read that may disclose server process memory). Produce exactly
one output:

- A reviewer-ready PR/change request that upgrades Ollama, restricts model
  creation and push exposure, adds verification, and documents operator
  cleanup, or
- TRIAGE.md if this repository does not own an affected Ollama deployment,
  install path, image, gateway policy, or safe patch path.

## Rules

- Scope only CVE-2026-7482 and directly related Ollama exposure hardening.
- Treat environment variables, API keys, model registry tokens, provider
  credentials, system prompts, conversation data, tenant context, model files,
  and Ollama logs as sensitive.
- Do not create or commit a malicious GGUF file, exploit payload, heap-memory
  disclosure artifact, or proof that attempts to read process memory.
- Do not push models or test artifacts to external registries.
- Do not expose a local Ollama service publicly to reproduce the issue.
- Do not auto-merge.

## Steps

1. Inventory every Ollama reference controlled by this repository:
   Dockerfiles, base images, Compose files, Helm charts, Kubernetes manifests,
   Terraform, Ansible, Nix, package recipes, workstation bootstrap scripts,
   systemd units, CI jobs, developer-container config, gateway/proxy policy,
   MCP or agent runtime config, SBOMs, checksums, docs, and runbooks.
2. Determine every resolved Ollama version. A target is vulnerable if it
   resolves to `<0.17.1`.
3. Determine every exposure path:
   - bind address and `OLLAMA_HOST` value;
   - published ports, ingress routes, reverse proxy rules, service mesh policy,
     firewall rules, workspace gateway routes, and agent gateway routes;
   - reachability of `/api/create`, `/api/push`, and equivalent proxy or UI
     actions;
   - whether callers are authenticated and authorized before model creation,
     model import, or model push.
4. If this repository does not deploy, package, configure, or route traffic to
   Ollama, stop with `TRIAGE.md` listing files checked, likely runtime owner,
   fixed target `Ollama 0.17.1+`, and operator actions the owner must perform.
5. Upgrade all controlled Ollama targets to `0.17.1+`, preferably the latest
   patched release available through the repository's normal distribution
   channel.
6. Regenerate all derived artifacts controlled by the repository: lockfiles,
   image digests, SBOMs, checksum allowlists, rendered manifests, deployment
   snapshots, package metadata, and version evidence.
7. Add fail-closed exposure controls where this repository owns routing or
   runtime configuration:
   - bind Ollama to loopback or a private service network by default;
   - require authentication and admin authorization for model creation, model
     import, and model push;
   - block unauthenticated or tenant-user access to `/api/create` and
     `/api/push`;
   - remove `OLLAMA_HOST=0.0.0.0` unless a documented gateway policy protects
     the service;
   - add network policy or firewall constraints for non-public deployments.
8. Add model-source controls where this repository owns model supply:
   - allow-list trusted model registries, buckets, or artifact repositories;
   - prefer digest-pinned model artifacts;
   - document how model provenance or signatures are checked before production
     use;
   - reject arbitrary user-supplied GGUF uploads unless a human-reviewed
     ingestion path exists.
9. Add safe verification without exploiting memory disclosure:
   - dependency/image/SBOM assertions prove every Ollama target is `>=0.17.1`;
   - gateway or policy tests prove unauthenticated callers cannot reach
     `/api/create` or `/api/push`;
   - render tests prove public ingress does not expose Ollama without auth;
   - config tests fail if `OLLAMA_HOST=0.0.0.0` is set without an approved
     gateway policy;
   - secret scanning proves no real tokens, prompts, logs, or model files were
     committed.
10. Add a PR body section named `CVE-2026-7482 operator actions` that states:
    - Ollama versions before and after the change;
    - whether Ollama was bound to loopback, private network, or public
      interfaces;
    - whether `/api/create` or `/api/push` was reachable by untrusted callers;
    - which model artifacts or registries need quarantine or review;
    - which environment variables, provider keys, registry tokens, or service
      credentials should be rotated;
    - which access logs should be reviewed for model creation, import, or push
      activity during the vulnerable window.
11. Run relevant validation: dependency resolution, image build, deployment
    render, gateway policy tests, unit/integration tests, SBOM refresh, secret
    scan, and security scan available in this repository.
12. Use PR title:
    `fix(sec): remediate CVE-2026-7482 in Ollama`.

## Stop conditions

- No Ollama deployment, install path, image, package recipe, gateway route, or
  runtime config is controlled by this repository.
- The resolved Ollama version can only be confirmed from production access the
  agent does not have.
- A fixed Ollama release cannot be consumed through the allowed distribution
  channel without a broader platform migration.
- Proving exposure would require a malicious GGUF file, reading process memory,
  exfiltrating model artifacts, or exposing a service to an untrusted network.
- Existing product requirements intentionally allow untrusted users or agents
  to create and push arbitrary models; document the risk and require a
  product/security decision.
- Validation fails for unrelated pre-existing reasons; document the failure
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled Ollama binary, package, image, SBOM, deployment manifest, or bootstrap path resolves to <0.17.1.
  • Unauthenticated or tenant-level callers cannot reach model creation or model push routes.
  • Public or shared-network exposure of OLLAMA_HOST=0.0.0.0 is removed or protected by explicit gateway authorization and network policy.
  • Model-source controls prevent arbitrary untrusted GGUF ingestion in production.
  • Operator actions cover secret rotation, model artifact review, and access-log review when exposure was possible.

Watch for

  • Updating a developer install script while production containers or Helm values still pin an older Ollama image.
  • Treating loopback defaults as proof of safety when deployment manifests set OLLAMA_HOST=0.0.0.0.
  • Blocking /api/create but leaving /api/push or a proxy alias reachable.
  • Adding tests that create exploit-like GGUF payloads or commit model binaries.
  • Logging environment variables, prompts, model metadata, or conversation content while adding verification.

References