CVE-2026-80350 in OneUptime
Summary
by MITRE • 08/26/2026
OneUptime's webhook target check rejects private and loopback addresses given in IPv4 form and a small set of IPv6 forms, but has no case for the IPv4-mapped IPv6 range. The webhook delivery path calls SSRFProtection.validateWebhookTargetIsSafe, and the host-literal screening inside Common/Server/Utils/SSRFProtection.ts, performed by isBlockedHostnameLiteral, rejects private and loopback IPv4 ranges and tests an IPv6 value against the unspecified address, the loopback, the link-local prefix and the unique-local prefixes. A value such as [::ffff:127.0.0.1] matches none of them. The value is also recognised as an address literal rather than a name, so the path that re-checks addresses obtained from resolution is not taken. The HTTP client treats the mapped form as the embedded IPv4 address and connects to it, so an authenticated project member who can configure a webhook can direct the server at loopback services, private network ranges and link-local metadata endpoints, and the response is recorded where the webhook result can be read. Version 12.0.7 adds handling for the mapped range.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
OneUptime versions prior to 12.0.7 contain a Server-Side Request Forgery vulnerability within its webhook target validation logic, specifically affecting how IPv4-mapped IPv6 addresses are processed during security checks. The application utilizes an SSRF protection mechanism located in the Common/Server/Utils/SSRFProtection.ts module, which invokes the validateWebhookTargetIsSafe function to evaluate incoming webhook URLs before delivery attempts. This validation process relies on a helper function named isBlockedHostnameLiteral to screen host literals against known dangerous address ranges. The implementation correctly identifies and blocks private IPv4 addresses such as 192.168.x.x, loopback addresses like 127.0.0.1, and specific IPv6 categories including unspecified addresses (::), link-local prefixes (fe80::/10), and unique-local prefixes (fc00::/7). However, the validation logic fails to account for the IPv4-mapped IPv6 address range defined in RFC 4291, specifically the ::ffff:0:0/96 prefix.
The technical flaw arises because an attacker can construct a malicious webhook target using the IPv4-mapped IPv6 format, such as [::ffff:127.0.0.1]. When this value is passed to the validation routine, it does not match any of the explicitly blocked IPv4 ranges nor does it fall within the checked IPv6 categories because the string representation differs from standard loopback or private address formats. Consequently, the security check incorrectly classifies the target as safe. Furthermore, the application distinguishes between hostnames and address literals; since this input is recognized as an address literal rather than a domain name, the secondary validation path that performs DNS resolution and re-checks the resulting IP addresses is bypassed entirely. This architectural oversight allows the HTTP client to interpret the mapped IPv6 address directly as its embedded IPv4 counterpart, establishing a connection to internal services without triggering further security controls.
The operational impact of this vulnerability is significant for authenticated users within OneUptime instances. An attacker with valid credentials and permission to configure webhook targets can exploit this flaw to direct the server toward loopback interfaces, private network ranges, or cloud provider link-local metadata endpoints such as 169.254.169.254. By sending requests to these internal resources, an authenticated user can potentially retrieve sensitive configuration data, authentication tokens, or other confidential information stored on local services that are not exposed to the public internet. The results of these forged requests are recorded in the webhook delivery logs and result history, allowing the attacker to read the responses directly through the application interface. This effectively transforms a standard webhook feature into a powerful tool for internal network reconnaissance and data exfiltration within the organization's infrastructure.
This vulnerability is classified under CWE-918 Server-Side Request Forgery (SSRF) due to the ability of an authenticated user to induce the server-side software to make requests to arbitrary destinations that are not intended by the application developer. In terms of offensive security frameworks, this aligns with MITRE ATT&CK technique T1046 Network Service Discovery, as it enables enumeration and interaction with internal network services from within a trusted context. The root cause is identified as CWE-20 Improper Input Validation, where the input sanitization logic fails to cover all valid representations of restricted IP addresses. To mitigate this issue, users must upgrade OneUptime to version 12.0.7 or later, which implements comprehensive handling for IPv4-mapped IPv6 ranges in its SSRF protection module. Until an update is applied, administrators should restrict webhook configuration permissions to only those personnel who absolutely require it and monitor logs for unusual outbound connection patterns originating from the application server.