CVE-2026-104973 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the fix for CVE-2026-30242 validates webhook IP addresses only when the webhook is created in apps/api/plane/app/serializers/webhook.py. The delivery task in apps/api/plane/bgtasks/webhook_task.py performs a separate DNS resolution when sending the request and does not validate the resolved IP address, allowing DNS rebinding to bypass the SSRF protection. This issue is fixed in 1.4.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified as CVE-2026-30242 represents a significant security flaw within Plane, an open-source project management platform, specifically affecting versions prior to 1.4.0. The core issue stems from an incomplete implementation of Server-Side Request Forgery SSRF protections in the webhook subsystem. Webhooks are commonly used by applications like Plane to send real-time notifications or data updates to external services when specific events occur within the application. To prevent malicious actors from forcing the server to make requests to internal network resources, developers typically implement IP address validation checks on the target URL provided during webhook configuration. However, in this case, the security controls were applied inconsistently across different stages of the request lifecycle, creating a bypass vector that undermines the intended protection mechanisms.
The technical root cause lies in the discrepancy between how the webhook endpoint validates input and how it subsequently executes HTTP requests. When a user creates or configures a webhook through the API at apps/api/plane/app/serializers/webhook.py, the system performs an IP address validation check on the provided URL to ensure it does not point to internal or reserved network ranges. This initial check is designed to block obvious SSRF attempts by rejecting URLs that resolve directly to private IP addresses such as those in RFC 1918 space. However, this validation occurs only at the time of creation and relies on a single DNS resolution event. The actual delivery mechanism, located in apps/api/plane/bgtasks/webhook_task.py, handles the asynchronous sending of webhook payloads separately from the initial configuration step. Crucially, when the background task executes to send the request, it performs its own fresh DNS resolution for the target domain rather than reusing or validating the IP address that was checked during creation.
This architectural separation between validation and execution enables a classic DNS rebinding attack. An attacker can register a domain name that initially resolves to an external public IP address, thereby passing the initial webhook configuration check. Once the webhook is saved, the attacker modifies their authoritative DNS records for that domain so that subsequent lookups resolve to an internal private IP address or another sensitive target within the network. When Plane attempts to deliver the webhook payload at a later time, it resolves the domain again and receives the new internal IP address. Since no secondary validation occurs before sending the request, the server proceeds to make the HTTP call directly to this internal resource. This effectively bypasses the SSRF protection because the security check was decoupled from the actual network operation by the asynchronous nature of the task queue and the lack of persistent IP verification during execution.
The operational impact of this vulnerability is severe for organizations deploying Plane in environments where SSRF mitigation is critical, such as those with internal APIs, metadata services, or database ports exposed to the application server layer. An attacker who can control webhook URLs could potentially access sensitive internal services that are not intended to be reachable from the web-facing tier. This includes cloud provider instance metadata endpoints like AWS EC2 169.254.169.254 which often contain authentication credentials, or internal administrative interfaces for databases and monitoring tools. Successful exploitation allows an unauthenticated or low-privileged user to pivot into the internal network infrastructure, potentially leading to data exfiltration, unauthorized access to backend systems, or further lateral movement within the environment. The vulnerability is classified under CWE-918 Server-Side Request Forgery with specific relevance to DNS rebinding techniques which exploit the time gap between validation and execution.
In terms of threat modeling, this flaw aligns with MITRE ATT&CK technique T1557 Adversary-in-the-Middle specifically regarding Lateral Tool Transfer or Accessing Internal Resources via SSRF patterns where attackers leverage trusted applications to probe internal networks. The attack vector is primarily remote through the web interface requiring only valid webhook creation privileges, which may be accessible depending on the organization's access control policies for project members. Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary mitigation is upgrading Plane to version 1.4.0 or later where this logic has been corrected to ensure consistent IP validation during request execution rather than just at configuration time. For environments unable to upgrade immediately, network-level controls such as egress filtering can be implemented to restrict outbound connections from the application server to only known external domains and block access to private IP ranges entirely regardless of DNS resolution outcomes. Additionally implementing strict allow-listing for webhook destinations or using a proxy layer that validates IPs at request time rather than configuration time provides defense in depth against this class of vulnerabilities.