CVE-2026-75511 in Novu
Summary
by MITRE • 09/22/2026
Novu provides an API for sending notifications through multiple channels. Prior to 3.18.0, Novu accepts chat webhook URLs from subscriber credentials.webhookUrl, channel endpoint endpoint.url, event payload.webhookUrl, and event overrides.webhookUrl, then passes the selected endpoint.url through send-message-chat.usecase.ts to raw HTTP requests in the Slack, Discord, Mattermost, Microsoft Teams, Grafana On-Call, Ryver, Rocket.Chat, GetStream, and Zulip providers. An authenticated user can supply an internal or otherwise restricted destination because these paths do not apply normalizeOutboundHttpUrl, assertSafeOutboundUrl, or the DNS-pinned safeOutboundJsonRequest protection used by the generic webhook providers. The Novu worker can consequently issue attacker-directed POST requests to internal network services and cause interactions or actions supported by those services. This issue is fixed in version 3.18.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Novu prior to version 3.18.0 represents a critical server-side request forgery flaw rooted in insufficient input validation of webhook endpoint URLs. Novu functions as an API-driven notification platform that routes messages through various communication channels such as Slack, Discord, Mattermost, Microsoft Teams, Grafana On-Call, Ryver, Rocket.Chat, GetStream, and Zulip. The core technical failure lies in the handling of chat-specific webhook configurations where user-supplied URLs are accepted from multiple sources including subscriber credentials.webhookUrl, channel endpoint.url, event payload.webhookUrl, and event overrides.webhookUrl. These values are passed directly to the send-message-chat.usecase.ts module which constructs raw HTTP requests without applying the same rigorous security checks utilized by other generic webhook providers in the system.
The specific technical deficiency is the absence of URL normalization and validation functions that are present elsewhere in the codebase, specifically normalizeOutboundHttpUrl, assertSafeOutboundUrl, and DNS-pinned safeOutboundJsonRequest protections. Because these safeguards were not applied to chat channel endpoints, an authenticated user could supply a maliciously crafted internal IP address or domain name as part of their webhook configuration. This allows the attacker to bypass standard perimeter defenses that typically restrict outbound connections from application servers to private network ranges. The Novu worker subsequently issues POST requests directed at these internally restricted destinations based on the attacker-controlled input, effectively turning the notification service into a proxy for internal network reconnaissance or exploitation.
The operational impact of this vulnerability is significant as it enables an authenticated adversary to interact with services residing within the organization's internal network that are not exposed to the public internet. By directing HTTP requests to these internal endpoints, attackers can potentially trigger actions supported by those services, such as executing commands on backend systems, exfiltrating sensitive data through error responses, or causing denial of service conditions against critical infrastructure components like Grafana On-Call or Microsoft Teams internal APIs. This scenario aligns with the Common Weakness Enumeration category CWE-918 for Server-Side Request Forgery and maps to MITRE ATT&CK technique T1572 which describes Protocol Tunneling, as the attacker leverages a legitimate application protocol to reach restricted network resources.
Mitigation of this vulnerability requires immediate upgrading to Novu version 3.18.0 or later where the code path has been corrected to enforce consistent URL validation across all channel types. For organizations unable to upgrade immediately, defensive measures should include implementing strict egress filtering at the network perimeter to block outbound connections from application servers to private IP ranges such as RFC 1918 addresses unless explicitly required for business logic. Additionally, deploying a web application firewall with rules capable of detecting and blocking HTTP requests containing internal hostnames or IP addresses in URL parameters can provide an additional layer of defense against exploitation attempts targeting this specific implementation flaw.