HIGH 8.6

CVE-2026-59707: LocalAI Unauthenticated SSRF Vulnerability in /models/apply Endpoint

LocalAI, an open-source AI framework, contains a vulnerability that allows unauthenticated attackers to make the server fetch data from internal or private network addresses. By sending a specially crafted request to a specific endpoint, an attacker can force the LocalAI server to reach out to addresses it normally shouldn't access—such as internal services or loopback addresses—and extract sensitive information from error messages. This type of attack, known as server-side request forgery (SSRF), is particularly dangerous in cloud or containerized environments where internal services may be exposed on predictable addresses.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.6 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Weaknesses (CWE)
CWE-918
Affected products
0 configuration(s)
Published / Modified
2026-07-07 / 2026-07-10

NVD description (verbatim)

LocalAI contains an unauthenticated server-side request forgery vulnerability in the POST /models/apply endpoint that allows attackers to fetch arbitrary internal URLs. The endpoint passes unsanitized gallery URL fields directly to gallery.GetGalleryConfigFromURLWithContext without proper validation, enabling attackers to force the server to issue HTTP GET requests to private and loopback ranges with partial response content leaked through error messages.

5 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-59707 is an unauthenticated SSRF vulnerability in LocalAI's POST /models/apply endpoint. The vulnerability exists because the endpoint accepts a gallery URL parameter and passes it directly to gallery.GetGalleryConfigFromURLWithContext without sanitizing or validating the input. An attacker can supply a URL pointing to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback addresses (127.0.0.1), or link-local addresses (169.254.0.0/16). The server will issue an HTTP GET request to the attacker-supplied URL, and portions of the response—particularly error messages and partial content—are leaked back to the client. This allows reconnaissance of internal network topology, discovery of internal services, and potential credential or configuration theft depending on what those internal services expose.

Business impact

Organizations running LocalAI instances, particularly those deployed in cloud environments, containerized setups, or on shared infrastructure, face immediate risk of data exposure and lateral movement within their network. An attacker can discover and interact with internal services (databases, cache layers, metadata services, CI/CD systems) without authentication. In cloud deployments, this includes potential access to instance metadata services that contain temporary credentials, role information, and configuration data. Exploiting this vulnerability requires no authentication and can be triggered by any network-accessible LocalAI instance, making it a particularly attractive target for attackers performing reconnaissance during the initial access phase of an attack.

Affected systems

Any deployment of LocalAI is potentially affected by this vulnerability. The risk is highest for instances exposed to untrusted networks or the public internet. Internal-only deployments remain at risk if an attacker gains any form of network access. Cloud-native deployments—those running on AWS, Azure, GCP, or Kubernetes clusters—face amplified risk due to the presence of well-known metadata endpoints and internal service discovery mechanisms that become targets for SSRF exploitation.

Exploitability

This vulnerability is highly exploitable. It requires no authentication, no user interaction, and no special conditions beyond network accessibility to the vulnerable endpoint. An attacker can craft a simple HTTP POST request with a malicious URL in the gallery field. The attack is deterministic and repeatable. No special tools are required; basic HTTP client functionality suffices. The barrier to exploitation is extremely low, making this vulnerability likely to be exploited opportunistically as soon as details become public or are shared within attacker communities.

Remediation

Upgrade LocalAI to a patched version that validates and sanitizes gallery URL inputs. Verify against the official LocalAI project advisory for specific version numbers and timelines. As an interim measure, implement network-level controls: restrict outbound access from LocalAI instances to only required external services using firewall rules or security group policies; block access to private IP ranges and loopback addresses at the application or network layer; disable or restrict access to cloud metadata endpoints if running in a cloud environment. Additionally, restrict network access to the /models/apply endpoint to trusted sources only, and monitor outbound HTTP requests from LocalAI servers for suspicious destinations.

Patch guidance

Consult the official LocalAI project repository and security advisories for patched version availability and upgrade procedures. The fix will involve input validation and URL sanitization before the gallery URL is passed to internal functions. When patching is available, prioritize rapid deployment given the low barrier to exploitation and high severity rating. Test patches in a non-production environment first to ensure compatibility with your deployment model and configuration.

Detection guidance

Monitor LocalAI server logs for POST requests to /models/apply with unusual or suspicious gallery URL values, particularly those containing private IP addresses (10.*, 172.16.*, 192.168.*), loopback addresses (127.*), or link-local addresses (169.254.*). Look for error messages or unusual response patterns indicating failed HTTP requests to internal addresses. Network-level detection should flag outbound HTTP/HTTPS requests from LocalAI instances to private IP ranges, loopback addresses, or cloud metadata endpoints (169.254.169.254 on AWS, 169.254.169.254 on Azure, metadata.google.internal on GCP). Anomalous request patterns to the endpoint—high volume, rapid-fire requests to multiple different URLs, or requests from unexpected source IPs—may indicate automated scanning or exploitation attempts.

Why prioritize this

This vulnerability scores 8.6 CVSS (HIGH) and warrants immediate attention. The combination of zero authentication requirements, low attack complexity, and high confidentiality impact places it in the top tier of exploitability. The ability to access internal services and cloud metadata makes this a critical stepping stone for attackers. Organizations with internet-facing LocalAI instances should treat this as an urgent priority; even internal-only instances should be patched promptly.

Risk score, explained

The CVSS 3.1 score of 8.6 reflects: (1) Network accessibility with no authentication required (AV:N, PR:N), making the attack surface extremely broad; (2) Low attack complexity (AC:L), indicating the exploit requires no special conditions; (3) High confidentiality impact (C:H), as internal data and service responses are leaked; (4) Changed scope (S:C), as the attacker can potentially access resources beyond the LocalAI application boundary (internal services, cloud infrastructure). The absence of integrity and availability impact (I:N, A:N) reflects that this particular vulnerability is read-only; however, the information disclosed may enable further attacks that do compromise those properties.

Frequently asked questions

Can this vulnerability be exploited without network access to the LocalAI instance?

No. The attacker must be able to reach the vulnerable POST /models/apply endpoint over the network. However, if your LocalAI instance is exposed to the internet or accessible from an untrusted network, exploitation is trivial. Even instances on internal networks are at risk if an attacker has gained any form of network foothold.

What information can an attacker actually steal through this vulnerability?

An attacker can retrieve partial content and error messages from internal HTTP services, including cloud metadata endpoints, internal APIs, configuration services, and web interfaces. In cloud environments, this often includes temporary credentials, role information, instance IDs, and region details. The extent of information depends on what internal services respond with and how verbose their error handling is.

If we're running LocalAI in a container with network policies that block internal access, are we safe?

Network policies provide good defense-in-depth, but you should not rely on them as your sole mitigation. Patch the vulnerability directly. Network policies can be misconfigured, and they may not cover all attack vectors or future changes to your infrastructure. Additionally, attackers may be able to probe your network policies themselves through the SSRF, learning about your internal topology.

Does this vulnerability allow attackers to modify or delete data on internal services?

No. CVE-2026-59707 is a read-only vulnerability—it allows attackers to fetch data via HTTP GET requests, not to send POST, PUT, DELETE, or other state-changing requests. However, the information disclosed could enable further attacks or credential theft that do allow modification or deletion.

This analysis is provided for informational purposes to help security teams understand and respond to CVE-2026-59707. It does not constitute legal advice, and organizations should verify all technical details, patch availability, and version numbers against official vendor advisories and their own environments. This vulnerability analysis does not include or endorse any exploit code, proof-of-concept, or weaponized tooling. Organizations are responsible for assessing their own risk posture, applying patches according to their change management procedures, and consulting with vendor support for deployment-specific guidance. Source: NVD (public-domain), retrieved 2026-08-16. Analysis generated by SEC.co (claude-haiku-4-5).