Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-26T10:16:43.237Z",
  "pubdate": "2026-08-26T10:16:43.237Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in the OneUptime webhook delivery mechanism, specifically within the Common/Server/Utils/SSRFProtection.ts file. The vulnerability arises from an incomplete blacklist implementation that fails to validate IPv4-mapped IPv6 addresses.\nBy utilizing the IPv4-mapped IPv6 address format (e.g., [::ffff:127.0.0.1]), an authenticated project member can bypass existing security controls designed to prevent requests to internal loopback, private, or link-local network segments.\nThis flaw allows attackers to perform unauthorized requests against internal services, sensitive metadata endpoints, and infrastructure components hidden behind the perimeter. The impact includes the potential exfiltration of sensitive configuration data, internal service interaction, and network reconnaissance, as the application records and presents the response of the malicious webhook request to the attacker.\nThe vulnerability affects OneUptime versions prior to 12.0.7. Successful exploitation requires an authenticated session with permissions to configure project webhooks.",
  "technicalDetails": "The root cause of this SSRF vulnerability is an insufficient input validation logic within the `SSRFProtection.validateWebhookTargetIsSafe` function and the associated `isBlockedHostnameLiteral` helper method. While OneUptime implements defensive filtering for standard IPv4 loopback and private address spaces, it fails to account for IPv4-mapped IPv6 address representations.\nIn standard networking stacks, IPv4-mapped IPv6 addresses (the `::ffff:0:0/96` prefix) allow for the encapsulation of an IPv4 address within an IPv6 literal. The `isBlockedHostnameLiteral` function performs checks against specific IPv6 prefixes, such as the unspecified address, loopback (::1), link-local (fe80::/10), and unique-local (fc00::/7) ranges. Because the mapped IPv4 address [::ffff:127.0.0.1] does not match these explicit IPv6 patterns, it bypasses the validation gate entirely.\nFurthermore, the application logic incorrectly identifies this input as an address literal rather than a resolvable hostname. Consequently, the mitigation path that would normally trigger a secondary DNS resolution check for embedded addresses is bypassed, preventing the system from normalizing and re-evaluating the target destination.\nThe attack flow proceeds as follows: An authenticated project member with webhook configuration privileges inputs a malicious URL containing an IPv4-mapped IPv6 address. The `SSRFProtection.validateWebhookTargetIsSafe` function processes this string, fails to identify it as a restricted internal range due to the missing case for the mapped prefix, and returns a 'safe' status. The webhook delivery path then passes this target to the underlying HTTP client library. The client, interpreting the mapped IPv6 literal, translates it into an IPv4 socket connection to the loopback interface or private network. The target service responds to the request, and the OneUptime server captures this response, making it accessible to the attacker through the webhook result interface.\nThis vulnerability is particularly severe because the application provides the results of the triggered request directly back to the authenticated user, allowing for a full request-response cycle against internal targets that are otherwise shielded from the public internet."
}