CVE-2026-80350: OneUptime before 12.0.7 Server-Side Request Forgery via IPv4-Mapped IPv6 Webhook URL
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OneUptimeto a version that resolves this vulnerability.Fixed in 12.0.7
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated OneUptime project member who can configure a webhook can exploit it. The attacker can cause the OneUptime server to send requests to loopback services, private-network addresses, and link-local metadata endpoints.
Are default webhook URL protections sufficient?
No. The affected target validation blocks private and loopback addresses in IPv4 form and certain IPv6 forms, but does not block IPv4-mapped IPv6 literals such as [::ffff:127.0.0.1].
What access does the attacker gain through a successful request?
Webhook responses are recorded in a location where the webhook result can be read. This can expose response data from services reachable by the OneUptime server.
How can I mitigate this if I cannot upgrade immediately?
Restrict webhook configuration permissions so untrusted project members cannot set webhook targets. This reduces access to the vulnerable delivery path until the mapped IPv6 range is handled.
How can I identify exploit attempts or affected webhook configurations?
Review configured webhook target URLs for IPv4-mapped IPv6 address literals, especially values using the ::ffff: prefix such as [::ffff:127.0.0.1]. Such targets can represent loopback, private-network, or link-local IPv4 destinations.