Plane EUVD-2026-92701

The attacker must hold an account that can create a workspace and register a webhook (authenticated, PR:L), and the target Plane instance must be running a version prior to 1.4.0 where webhook_send_task calls requests.post() without allow_redirects=False. Exploitation requires that validate_url() is applied only to the originally submitted URL (which the attacker sets to a benign public host) while the redirect target is unvalidated, so the attacker-controlled public endpoint must return a 3xx redirect to an internal/reserved address. Impact is maximized when Plane runs on cloud infrastructure exposing an instance-metadata endpoint (e.g. 169.254.169.254) or reachable internal services. Limiting factors: requires authentication and workspace-creation privileges (not anonymous), requires the worker to actually dispatch a webhook event, and the payload for internal POSTs is the fixed webhook body (limited attacker control over request contents).

This is a genuine high-priority issue rather than an inflated-CVSS artifact, though slightly less severe than the 9.9 suggests. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C) is internally consistent with the description: a network-reachable, low-complexity attack requiring only low privileges (the ability to create a workspace - PR:L, i.e. authenticated) and no user interaction, crossing a scope boundary into the internal network/cloud-metadata plane. The CWE-918 SSRF classification matches the described redirect-based bypass of validate_url(). No EPSS score, KEV listing, or standalone exploit POC was provided in the input; the referenced GitHub artifacts are the vendor advisory (GHSA-mq87-52pf-hm3h), the fix PR #9163, the patch commit, and the v1.4.0 release - these confirm the root cause and remediation but are NOT exploitation evidence. Therefore exploitation status is 'no public exploit identified at time of analysis.' The real risk driver is impact: a successful SSRF to cloud instance-metadata (e.g. 169.254.169.254) can disclose IAM credentials and lead to broader cloud-account compromise, which is why confidentiality impact is high. The main mitigating factor is the PR:L authentication requirement - the attacker must be able to register and create a workspace, so this is not fully anonymous internet-wide exploitation. Self-hosted Plane deployments running on cloud infrastructure prior to 1.4.0 should treat this as an urgent patch.

An authenticated user who can create a workspace registers a webhook whose URL points to an attacker-controlled public endpoint that passes validate_url(). When an event fires, the Plane worker POSTs to that endpoint, which returns a 302 redirect to an internal address such as the cloud metadata service; because allow_redirects is not disabled, the worker follows the hop, fetches the internal response, and stores the body in webhook_logs, which the attacker then reads back through the workspace webhook-logs API. No public exploit code was identified, but the fix PR diff fully documents the vulnerable code path.