CVE-2026-86735: Snipeitapp Snipe-it SSRF Vulnerability

CVE-2026-86735 Overview

CVE-2026-86735 is a Server-Side Request Forgery (SSRF) vulnerability in Snipe-IT asset management software versions before 8.7.0. The flaw resides in the ExternalUrl validation rule, which fails to detect IPv6 transition addresses that encode private IPv4 targets. Attackers with super-admin privileges can configure webhook URLs using NAT64, 6to4, or Teredo transition addresses to bypass SSRF guards. This allows the application server to reach internal services or cloud metadata endpoints that should remain isolated from external network requests.

Critical Impact
Authenticated super-admin attackers can pivot through the Snipe-IT server to access internal-only endpoints, including cloud instance metadata services that may expose IAM credentials.

Affected Products

Snipe-IT versions prior to 8.7.0
Snipe-IT deployments configured with webhook integrations
Self-hosted and cloud-hosted Snipe-IT instances relying on ExternalUrl validation

Discovery Timeline

2026-09-08 - CVE-2026-86735 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86735

Vulnerability Analysis

The vulnerability is classified as Server-Side Request Forgery [CWE-918]. Snipe-IT enforces SSRF protection through an ExternalUrl validation rule that inspects URL hostnames and blocks requests targeting private IPv4 ranges. The rule does not account for IPv6 transition mechanisms that encode IPv4 addresses within IPv6 notation.

When an administrator configures a webhook, the validator resolves the hostname and compares it against blocked address ranges. IPv6 transition addresses such as NAT64 (64:ff9b::/96), 6to4 (2002::/16), and Teredo (2001::/32) can carry an embedded IPv4 address that maps back to private space. The validator processes these as public IPv6 addresses and permits the request.

Once accepted, the underlying HTTP client resolves and connects to the encoded IPv4 destination. This grants the attacker request access to internal HTTP endpoints from the perspective of the Snipe-IT server.

Root Cause

The root cause is incomplete address normalization inside the ExternalUrl validation logic. The rule enumerates IPv4 private ranges and standard IPv6 loopback addresses but does not decode IPv6 transition formats before matching. Any address that syntactically appears public but semantically routes to a private IPv4 target evades the deny list.

Attack Vector

Exploitation requires authenticated super-admin access to the Snipe-IT administrative console. The attacker constructs a webhook URL using an IPv6 transition address that encodes a private target such as 169.254.169.254 for cloud metadata or 127.0.0.1 for loopback services. Snipe-IT then issues outbound HTTP requests to the internal target when the webhook fires, forwarding responses or side effects that the attacker can observe.

The vulnerability is described in the GitHub Security Advisory GHSA-5j6m-rr83-rpj7 and the VulnCheck Advisory for SSRF.

Detection Methods for CVE-2026-86735

Indicators of Compromise

Webhook configurations containing IPv6 addresses in the 64:ff9b::/96, 2002::/16, or 2001::/32 ranges
Outbound HTTP requests from the Snipe-IT application server targeting IPv6 transition prefixes
Application logs showing webhook fires resolving to loopback or link-local IPv4 destinations after IPv6 translation
Unexpected access attempts to cloud metadata endpoints such as 169.254.169.254 originating from the Snipe-IT host

Detection Strategies

Audit the Snipe-IT webhooks table for URLs containing IPv6 literals and transition-address prefixes
Inspect reverse proxy and egress firewall logs for connections to NAT64, 6to4, or Teredo prefixes originating from the application server
Correlate super-admin webhook create or update events with subsequent outbound request patterns

Monitoring Recommendations

Enable egress logging on the Snipe-IT host and alert on any connections to IPv6 transition ranges
Alert on outbound requests from application servers to link-local IPv4 addresses, including cloud metadata endpoints
Track administrative changes to webhook and integration configurations with change management review

How to Mitigate CVE-2026-86735

Immediate Actions Required

Upgrade Snipe-IT to version 8.7.0 or later, which corrects the ExternalUrl validation rule
Review all existing webhook configurations and remove any URLs referencing IPv6 transition prefixes
Rotate any cloud credentials accessible from the instance metadata service if exploitation is suspected
Restrict super-admin accounts and enforce multi-factor authentication on administrative access

Patch Information

The maintainers released a fix in Snipe-IT 8.7.0. Upgrade details and the corrected validation logic are documented in the GitHub Security Advisory GHSA-5j6m-rr83-rpj7. Administrators running self-hosted installations should follow the standard Snipe-IT upgrade procedure and verify the running version after deployment.

Workarounds

Deploy an egress firewall policy that blocks outbound traffic from the Snipe-IT host to IPv6 transition prefixes and link-local IPv4 ranges
Enforce Instance Metadata Service Version 2 (IMDSv2) on AWS deployments to require session tokens for metadata access
Route webhook traffic through an outbound proxy that enforces allow-listed destinations
Limit super-admin role assignments and audit privileged account usage until the patch is applied

bash

# Example egress restriction using ip6tables to block IPv6 transition ranges
ip6tables -A OUTPUT -d 64:ff9b::/96 -j REJECT
ip6tables -A OUTPUT -d 2002::/16 -j REJECT
ip6tables -A OUTPUT -d 2001::/32 -j REJECT

# Block access to AWS instance metadata from the application host
iptables -A OUTPUT -d 169.254.169.254 -j REJECT