Summary
Plane's webhook delivery worker may follow redirects without validating the final destination, enabling server-side request forgery (SSRF). A workspace user who can register a webhook could cause the worker to request internal services, including cloud metadata endpoints, and retrieve response content through webhook logs.
Plane's webhook delivery worker may follow redirects without validating the final destination, enabling server-side request forgery (SSRF). A workspace user who can register a webhook could cause the worker to request internal services, including cloud metadata endpoints, and retrieve response content through webhook logs.
Affected context
The vulnerability occurs in Plane deployments where the webhook delivery task uses an HTTP client that follows redirects by default. Although the initial webhook URL is checked against private, loopback, link-local, and reserved address ranges, redirected destinations are not subjected to equivalent validation. The issue is relevant when a user with workspace creation or webhook-management capabilities can register a webhook and later access its delivery logs.
The vulnerability occurs in Plane deployments where the webhook delivery task uses an HTTP client that follows redirects by default. Although the initial webhook URL is checked against private, loopback, link-local, and reserved address ranges, redirected destinations are not subjected to equivalent validation. The issue is relevant when a user with workspace creation or webhook-management capabilities can register a webhook and later access its delivery logs.
Exploit preconditions
- Attack surface: Plane's workspace webhook registration and asynchronous webhook delivery workflow
- Required access: A user account with permission to create a workspace or register a webhook, plus access to the resulting webhook logs
- Trigger point: Webhook delivery to a public endpoint that redirects the worker to an internal destination
- Why exploitation is possible: The original URL is validated, but redirect targets are followed without revalidating their destination or restricting the request path
- Attack surface: Plane's workspace webhook registration and asynchronous webhook delivery workflow
- Required access: A user account with permission to create a workspace or register a webhook, plus access to the resulting webhook logs
- Trigger point: Webhook delivery to a public endpoint that redirects the worker to an internal destination
- Why exploitation is possible: The original URL is validated, but redirect targets are followed without revalidating their destination or restricting the request path
Why this happens
The underlying bug is incomplete SSRF protection in an HTTP request workflow. URL validation is applied only to the user-supplied starting address, while the HTTP client can follow redirects to destinations that were not included in the original security decision. This maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input controls requests made from a trusted server-side environment.
The underlying bug is incomplete SSRF protection in an HTTP request workflow. URL validation is applied only to the user-supplied starting address, while the HTTP client can follow redirects to destinations that were not included in the original security decision. This maps to CWE-918: Server-Side Request Forgery, because attacker-influenced input controls requests made from a trusted server-side environment.
Potential impact
- Internal services may receive unauthorized requests
- Cloud instance metadata or temporary credentials could be exposed
- Sensitive response bodies may be disclosed through webhook logs
- Internal network topology and service information could be revealed
- Compromised credentials could enable further cloud or application abuse
- Internal services may receive unauthorized requests
- Cloud instance metadata or temporary credentials could be exposed
- Sensitive response bodies may be disclosed through webhook logs
- Internal network topology and service information could be revealed
- Compromised credentials could enable further cloud or application abuse
General mitigation guidance
Mitigation generally focuses on enforcing destination safety for every outbound request, not only for the initial webhook URL.
Common defensive patterns include:
- Disable redirects for webhook requests by default, or handle each redirect through an explicit security decision
- Revalidate every redirect target against private, loopback, link-local, reserved, and otherwise disallowed address ranges
- Resolve hostnames carefully and account for DNS rebinding and address changes
- Restrict outbound worker traffic with network egress policies and deny access to cloud metadata services where appropriate
- Avoid storing unnecessary response bodies in user-accessible webhook logs
- Apply least-privilege permissions to worker identities and cloud roles
Mitigation generally focuses on enforcing destination safety for every outbound request, not only for the initial webhook URL.
Common defensive patterns include:
- Disable redirects for webhook requests by default, or handle each redirect through an explicit security decision
- Revalidate every redirect target against private, loopback, link-local, reserved, and otherwise disallowed address ranges
- Resolve hostnames carefully and account for DNS rebinding and address changes
- Restrict outbound worker traffic with network egress policies and deny access to cloud metadata services where appropriate
- Avoid storing unnecessary response bodies in user-accessible webhook logs
- Apply least-privilege permissions to worker identities and cloud roles
How teams detect issues like this
Organizations can identify similar SSRF risks through:
- Static analysis searches for outbound HTTP calls that follow redirects with attacker-controlled URLs
- Code review checks confirming that redirect destinations are independently validated
- Tests covering redirects to private, loopback, link-local, reserved, and metadata address ranges
- Monitoring for worker requests to internal address space or cloud metadata endpoints
- Egress firewall and service-mesh policies that alert on unexpected internal destinations
- Review of webhook logs and request telemetry for unusual redirect chains
Automated security review tools may help flag unsafe redirect handling, but runtime network controls provide an important secondary defense.
Organizations can identify similar SSRF risks through:
- Static analysis searches for outbound HTTP calls that follow redirects with attacker-controlled URLs
- Code review checks confirming that redirect destinations are independently validated
- Tests covering redirects to private, loopback, link-local, reserved, and metadata address ranges
- Monitoring for worker requests to internal address space or cloud metadata endpoints
- Egress firewall and service-mesh policies that alert on unexpected internal destinations
- Review of webhook logs and request telemetry for unusual redirect chains
Automated security review tools may help flag unsafe redirect handling, but runtime network controls provide an important secondary defense.
