Description

The setWebhookResolver in packages/api/src/resolvers/webhooks/index.ts stores the caller-supplied url without any address validation, and the file imports no validation helper. When a subscribed event fires, callWebhook in packages/api/src/jobs/call_webhook.ts issues axios.request with that url, the method and Content-Type recorded on the webhook, and a JSON body carrying the event data, so an authenticated user can make the server send repeated attacker-shaped requests to internal endpoints, including link-local metadata addresses. The request is blind: callWebhook discards the result and writes only a success line or the axios error to the server log, so the response is not returned through the API.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.0",
  "pubDate": "2026-08-20T11:16:22.240Z",
  "pubdate": "2026-08-20T11:16:22.240Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists within the webhook registration and execution pipeline of the application. Specifically, the vulnerability stems from the lack of input validation and address filtering on caller-supplied URLs during the webhook creation process. An authenticated user can register arbitrary endpoints, including local, link-local, and cloud metadata service addresses, which the server subsequently queries via an automated background job.\nWhen a subscribed event fires, the application utilizes the stored URL to dispatch an outbound HTTP request using axios.request, transmitting customized HTTP methods, headers, and payloads containing event data to the designated destination. Although the request execution is blind—meaning response bodies are discarded and only success or error states are logged—this mechanism enables malicious actors to leverage the host server as a proxy.\nThis capability permits attackers to probe internal network perimeters, interact with internal microservices, and query sensitive metadata endpoints that are typically protected from direct external access. The primary risk implication is internal network enumeration, unauthorized interaction with internal APIs, and potential exposure of sensitive infrastructure configuration data. Successful exploitation requires authentication to access the webhook creation API and the ability to subscribe to or trigger events.",
  "technicalDetails": "The vulnerability resides in the interaction between packages/api/src/resolvers/webhooks/index.ts and packages/api/src/jobs/call_webhook.ts. The root cause is the absence of input sanitization and domain or IP address validation in the setWebhookResolver function located in packages/api/src/resolvers/webhooks/index.ts. When a webhook is registered, the caller-supplied url parameter is persisted directly into the data store without verifying whether it points to a public domain, private IP space, or loopback and link-local addresses.\nThe vulnerable component responsible for triggering the outbound connection is the callWebhook function located in packages/api/src/jobs/call_webhook.ts. Upon the firing of a subscribed event, callWebhook invokes axios.request using the unvalidated URL. The request incorporates the method and Content-Type explicitly recorded on the webhook alongside a JSON-formatted body carrying the event data. Because no validation helper is imported or utilized within packages/api/src/resolvers/webhooks/index.ts, the system blindly trusts and processes any HTTP or HTTPS URL provided by the user.\nThe attack flow proceeds as follows. First, an authenticated attacker with permissions to configure webhooks interacts with setWebhookResolver to register a malicious webhook configuration. The attacker supplies a target URL pointing to an internal resource, such as a cloud provider metadata service (e.g., 169.254.169.254) or an internal microservice running on a restricted port. Second, the attacker triggers or waits for the associated event to fire within the application. Third, the background job processor executes callWebhook, which issues an outbound HTTP request via axios.request targeting the internal resource.\nAlthough the request is blind—discarding the response payload and writing only a success status line or the resulting axios error to the server log—an attacker can infer successful interactions or state changes via timing analysis, error messages written to logs if accessible, or side effects induced on the internal target services. Privilege requirements are limited to authenticated users capable of invoking the webhook resolver, and the network exposure is localized to the server environment's capability to reach internal or external endpoints."
}