Ollama before 0

CVE-2026-7482 is a heap out-of-bounds read in Ollama’s GGUF loader affecting versions before 0.17.1. A crafted GGUF can declare tensor offsets and sizes that exceed the real file length; when Ollama processes that file during model creation and quantization, it reads past the intended heap buffer and can pull adjacent process memory into the generated model artifact. That memory can include environment variables, API keys, system prompts, and other users’ in-flight chat data.

The vendor’s 9.1 CRITICAL score is technically defensible for an exposed instance, but too broad for enterprise prioritization. The decisive real-world friction is exposure shape: Ollama serves locally by default on 127.0.0.1, and the vulnerable path is the model-management flow (/api/create, often plus /api/push), not the normal inference path alone. That keeps this out of universal-CRITICAL territory, but any internet-reachable or weakly proxied deployment is still a serious no-auth remote secret leak.

Why this verdict

• Downgrade for exposure shape: vendor scoring assumes network reach, but Ollama serves on 127.0.0.1 by default and only becomes remotely reachable when admins deliberately publish it via OLLAMA_HOST, port forwarding, or a reverse proxy.
• Downgrade for path specificity: the attacker needs access to the model-management workflow, especially /api/create, not just any chat/inference endpoint. In real deployments that sharply narrows the exploitable population.
• Held at HIGH because blast radius is real when exposed: no auth is required on the local API path, the leak can include secrets and user data, and /api/push gives a clean exfil route. Public PoC material means this is not theoretical.

Why not higher?

I did not keep the vendor’s CRITICAL because this is not a wormable, universal edge-service bug across every host that has Ollama installed. The remote condition depends on operator exposure decisions, and many enterprise deployments either stay localhost-bound or never expose model creation to untrusted users. There is also no authoritative in-the-wild exploitation signal or KEV listing during this review.

Why not lower?

I did not drop this to MEDIUM because exposed instances are one unauthenticated HTTP workflow away from leaking high-value process memory. The combination of public internet exposure, no auth on the relevant local API, and public PoC availability makes this too actionable and too damaging for a lower bucket.

1. Bind Ollama to localhost — Force OLLAMA_HOST=127.0.0.1:11434 or equivalent and remove direct external listeners. This is the strongest exposure reduction and should be deployed within 30 days for a HIGH verdict, with same-day priority for anything currently internet-facing.
2. Put auth in front of model-management routes — Require authentication and authorization at the reverse proxy for /api/create, /api/push, and related import/publish paths. If business needs force network access, do this within 30 days so the vulnerable workflow is no longer anonymously reachable.
3. Restrict egress from Ollama hosts — Allow only approved registries and package destinations from inference nodes. This breaks the clean /api/push exfil chain and should be enforced within 30 days on systems that handle sensitive prompts or credentials.
4. Hunt for model creation and push anomalies — Review Ollama logs, reverse-proxy logs, and outbound connections for unexpected create/import/push sequences, especially from unfamiliar IPs. Do this immediately on exposed nodes, then operationalize alerting within 30 days.

Run this on the target Ollama host or inside the Ollama container/VM. Invoke it as bash check-cve-2026-7482.sh http://127.0.0.1:11434 or just bash check-cve-2026-7482.sh; no root is required for version/API checks, though root may help if you separately inspect service config.

#!/usr/bin/env bash
# check-cve-2026-7482.sh
# Determine whether Ollama is vulnerable to CVE-2026-7482 based on installed/runtime version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_URL="${1:-http://127.0.0.1:11434}"
API_URL="${TARGET_URL%/}/api/version"
REQUIRED="0.17.1"

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

normalize_ver() {
  # Strip leading v and any non-semver suffix.
  echo "$1" | sed -E 's/^v//; s/[^0-9.].*$//'
}

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$1" = "$2" ] && return 0
  local first
  first=$(printf '%s
%s
' "$1" "$2" | sort -V | head -n1)
  [ "$first" = "$2" ]
}

extract_version_text() {
  # Accepts strings like:
  # "ollama version is 0.17.0"
  # "ollama version 0.17.0"
  # '{"version":"0.17.0"}'
  echo "$1" | grep -Eo '([0-9]+\.[0-9]+\.[0-9]+)' | head -n1
}

VERSION=""
SOURCE=""

if have_cmd ollama; then
  CLI_OUT=$(ollama --version 2>/dev/null || true)
  CLI_VER=$(extract_version_text "$CLI_OUT")
  if [ -n "$CLI_VER" ]; then
    VERSION="$CLI_VER"
    SOURCE="cli"
  fi
fi

if [ -z "$VERSION" ] && have_cmd curl; then
  API_OUT=$(curl -fsS --max-time 3 "$API_URL" 2>/dev/null || true)
  API_VER=$(extract_version_text "$API_OUT")
  if [ -n "$API_VER" ]; then
    VERSION="$API_VER"
    SOURCE="api"
  fi
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - could not determine Ollama version from CLI or $API_URL"
  exit 2
fi

VERSION=$(normalize_ver "$VERSION")
REQUIRED=$(normalize_ver "$REQUIRED")

if ver_ge "$VERSION" "$REQUIRED"; then
  echo "PATCHED - Ollama version $VERSION detected via $SOURCE (fixed in $REQUIRED+)"
  exit 0
else
  echo "VULNERABLE - Ollama version $VERSION detected via $SOURCE (requires $REQUIRED+)"
  exit 1
fi

Sources

1. NVD CVE-2026-7482
2. GitHub Advisory GHSA-x8qc-fggm-mpqg
3. Ollama PR #14406
4. Ollama fix commit 88d57d0
5. Ollama release v0.17.1
6. Ollama FAQ
7. Ollama Importing a Model docs
8. Censys research on exposed Ollama instances