CVE-2026-80350: OneUptime SSRF Vulnerability

CVE-2026-80350 Overview

CVE-2026-80350 is a Server-Side Request Forgery (SSRF) vulnerability in OneUptime's webhook delivery path. The host-literal screening in Common/Server/Utils/SSRFProtection.ts rejects private and loopback IPv4 addresses and a small set of IPv6 forms, but does not cover the IPv4-mapped IPv6 range. An authenticated project member can configure a webhook with a URL such as [::ffff:127.0.0.1] and reach loopback services, private network ranges, and link-local metadata endpoints. The HTTP response is recorded where the webhook result can be read, exposing internal data. OneUptime version 12.0.7 adds handling for the mapped range.

Critical Impact
Authenticated attackers can pivot the OneUptime server to internal services and cloud metadata endpoints, exfiltrating sensitive data through the webhook response body.

Affected Products

OneUptime versions prior to 12.0.7
OneUptime 12.0.6 (confirmed vulnerable via SSRFProtection.ts source review)
OneUptime webhook delivery component (SSRFProtection.validateWebhookTargetIsSafe)

Discovery Timeline

2026-08-26 - CVE-2026-80350 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-80350

Vulnerability Analysis

The vulnerability sits in the webhook target validation layer. OneUptime's webhook delivery path calls SSRFProtection.validateWebhookTargetIsSafe before issuing an outbound request. Inside that path, isBlockedHostnameLiteral inspects the host component and rejects private and loopback IPv4 ranges. For IPv6, it tests the value against the unspecified address, loopback, link-local prefix, and unique-local prefixes.

The check omits the IPv4-mapped IPv6 range (::ffff:0:0/96). A value such as [::ffff:127.0.0.1] matches none of the blocked prefixes and passes validation. Because the value parses as an address literal, the branch that re-checks addresses obtained from DNS resolution is not exercised. The HTTP client then interprets the mapped form as the embedded IPv4 address and connects to it. This maps to CWE-918: Server-Side Request Forgery.

Root Cause

The root cause is incomplete allow/deny logic in isBlockedHostnameLiteral. The function enumerates specific IPv6 ranges but does not normalize IPv4-mapped IPv6 addresses back to their embedded IPv4 form before comparison. The mismatch between the validator's view of the address and the HTTP client's view enables the bypass.

Attack Vector

An authenticated project member with permission to configure webhooks supplies a target URL containing an IPv4-mapped IPv6 literal. Examples include http://[::ffff:127.0.0.1]/, http://[::ffff:169.254.169.254]/latest/meta-data/, or literals pointing at RFC1918 ranges. The server issues the request and stores the response where the operator can read it. Attackers can enumerate internal HTTP services, query cloud metadata endpoints for temporary credentials, and reach loopback administrative interfaces. See the GitHub Security Advisory GHSA-9g3w-r349-3vvw for technical details.

Detection Methods for CVE-2026-80350

Indicators of Compromise

Webhook configurations containing IPv6 literals with the ::ffff: prefix, particularly wrapping RFC1918 ranges, 127.0.0.0/8, or 169.254.169.254.
Outbound HTTP connections from the OneUptime application host to loopback or link-local destinations shortly after webhook creation or edit events.
Webhook execution records whose response bodies contain cloud metadata service payloads or internal service banners.

Detection Strategies

Audit the Webhook and workflow tables for target URLs containing ::ffff: or bracketed IPv6 literals resolving to private space.
Correlate webhook create/update audit events with subsequent egress connections from the OneUptime pod or host.
Inspect stored webhook response payloads for markers such as iam/security-credentials/, computeMetadata, or internal hostnames.

Monitoring Recommendations

Enable egress network policies on the OneUptime workload and alert on any denied connection to link-local or loopback addresses.
Log all webhook target values at configuration time and forward them to a SIEM for pattern matching on IPv6-mapped forms.
Monitor authentication logs for project members creating webhooks immediately after gaining access, an early indicator of credential abuse.

How to Mitigate CVE-2026-80350

Immediate Actions Required

Upgrade OneUptime to version 12.0.7 or later, which adds handling for the IPv4-mapped IPv6 range.
Review existing webhook configurations and remove any target using bracketed IPv6 literals or the ::ffff: prefix.
Rotate any cloud instance credentials that may have been exposed via the instance metadata service if webhook logs show requests to 169.254.169.254.

Patch Information

OneUptime 12.0.7 updates Common/Server/Utils/SSRFProtection.ts to reject IPv4-mapped IPv6 addresses in isBlockedHostnameLiteral. Review the fix in the OneUptime GitHub repository and consult the VulnCheck advisory for advisory metadata. Related discussion is tracked in OneUptime Issue #2578.

Workarounds

Restrict webhook creation to trusted operators by tightening project role permissions until the patch is applied.
Deploy egress firewall rules that block the OneUptime application from reaching 127.0.0.0/8, 169.254.0.0/16, and RFC1918 ranges.
On cloud providers, enforce IMDSv2 or equivalent hop-limit protections to reduce the impact of metadata service reachability.

bash

# Example egress restriction using iptables on the OneUptime host
iptables -A OUTPUT -m owner --uid-owner oneuptime -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner oneuptime -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner oneuptime -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner oneuptime -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner oneuptime -d 192.168.0.0/16 -j REJECT