CVE-2026-105636 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the webhook delivery task in apps/api/plane/bgtasks/webhook_task.py calls requests.post() without allow_redirects=False and does not validate redirect targets. validate_url() blocks private, loopback, link-local, and reserved addresses in the original webhook URL, but the final URL reached after one or more redirects is not checked. A user who can create a workspace can register a webhook pointing to an attacker-controlled public endpoint that returns a 302 redirect to an internal address. The Plane worker then fetches internal resources, including cloud metadata, and stores the response body in webhook_logs, where the attacker can retrieve it through the workspace webhook-logs API. This issue is fixed in 1.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Plane versions prior to 1.4.0 represents a critical server-side request forgery flaw rooted in improper validation of redirect targets within its background task processing logic. Specifically, the webhook delivery mechanism located at apps/api/plane/bgtasks/webhook_task.py utilizes the Python requests library to send HTTP POST requests to configured webhook endpoints. While the initial URL provided by the user is subjected to a validate_url function that correctly blocks private IP ranges, loopback addresses, link-local networks, and reserved address spaces, this security control fails at subsequent stages of the request lifecycle. The implementation does not set allow_redirects=False nor does it implement any post-redirect validation logic. Consequently, if an external server responds with a 302 Found status code pointing to an internal resource, the requests library automatically follows the redirect without checking whether the final destination falls within prohibited network ranges. This oversight allows attackers to bypass initial input sanitization by leveraging intermediate servers under their control as proxies to reach internal infrastructure.
From an operational perspective, this flaw enables a severe information disclosure attack vector accessible to any authenticated user with workspace creation privileges. An attacker can register a webhook URL pointing to a public endpoint they own, which is configured to return a redirect response targeting sensitive internal services such as cloud metadata endpoints or internal API servers. When the Plane worker processes this webhook configuration, it initiates an outbound request that follows the redirect chain into the private network space. The server then fetches data from these internal resources and stores the entire response body in the webhook_logs table for debugging purposes. Because the webhook logs are accessible via a workspace-specific API endpoint, the attacker can subsequently retrieve the fetched internal data directly through legitimate application interfaces. This effectively transforms an outbound request vulnerability into a powerful tool for exfiltrating sensitive configuration details, authentication tokens, or other proprietary information stored on internal servers that should not be reachable from the public internet-facing Plane instance.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how inadequate validation of redirect targets allows attackers to circumvent input filtering mechanisms. It also maps closely to MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where an attacker intercepts and redirects traffic to compromise internal services. The impact is particularly severe in cloud-native deployments where metadata endpoints often contain credentials for other services or detailed infrastructure configurations that can facilitate further lateral movement within the victim's environment. The failure lies not just in the initial URL validation but in the lack of a comprehensive security policy governing all URLs involved in the request chain, including those discovered dynamically through HTTP redirects.
To mitigate this vulnerability, organizations running Plane versions prior to 1.4.0 should upgrade immediately to version 1.4.0 or later where the issue has been resolved by implementing strict validation on final redirect destinations. For environments that cannot yet upgrade, immediate remediation involves configuring network-level controls such as firewall rules or reverse proxy configurations to block outbound requests from Plane worker processes to private IP ranges and cloud metadata endpoints. Additionally, application-layer mitigations could include disabling automatic redirects in the HTTP client configuration by setting allow_redirects=False and manually handling redirect responses with explicit validation of each new target URL against a deny list of internal address spaces. Regular auditing of webhook configurations and restricting workspace creation privileges to trusted administrators can further reduce the attack surface available for exploitation.