Summary
Plane versions before 1.4.0 can be vulnerable to server-side request forgery in webhook delivery because the destination is resolved again when a request is sent without validating the resulting IP address. An attacker who can control or influence a webhook destination may use DNS rebinding to redirect requests to internal services that should be inaccessible.
Plane versions before 1.4.0 can be vulnerable to server-side request forgery in webhook delivery because the destination is resolved again when a request is sent without validating the resulting IP address. An attacker who can control or influence a webhook destination may use DNS rebinding to redirect requests to internal services that should be inaccessible.
Affected context
The issue occurs in Plane's webhook delivery workflow when a webhook URL is validated at creation time but resolved independently during delivery. Deployments are at greater risk when users or integrations can register webhook destinations, DNS responses can change between validation and delivery, and the delivery worker can reach sensitive internal services.
The issue occurs in Plane's webhook delivery workflow when a webhook URL is validated at creation time but resolved independently during delivery. Deployments are at greater risk when users or integrations can register webhook destinations, DNS responses can change between validation and delivery, and the delivery worker can reach sensitive internal services.
Exploit preconditions
- Attack surface: Outbound HTTP requests made by the webhook delivery task
- Required access: Ability to create or influence a webhook destination, subject to application authorization
- Trigger point: Webhook delivery after the destination is resolved by the background task
- Why exploitation is possible: The IP validated during webhook creation is not necessarily the IP used during delivery, allowing DNS rebinding to bypass the earlier SSRF check
- Attack surface: Outbound HTTP requests made by the webhook delivery task
- Required access: Ability to create or influence a webhook destination, subject to application authorization
- Trigger point: Webhook delivery after the destination is resolved by the background task
- Why exploitation is possible: The IP validated during webhook creation is not necessarily the IP used during delivery, allowing DNS rebinding to bypass the earlier SSRF check
Why this happens
The vulnerability results from applying an SSRF validation decision at one point in time while performing a separate DNS resolution at request time. Because the later resolved address is not checked against the same internal-network restrictions, an attacker-controlled hostname may change from an apparently permitted address to a private, loopback, link-local, or otherwise restricted destination. This is a CWE-918 condition caused by an incomplete validation boundary and a time-of-check/time-of-use gap.
The vulnerability results from applying an SSRF validation decision at one point in time while performing a separate DNS resolution at request time. Because the later resolved address is not checked against the same internal-network restrictions, an attacker-controlled hostname may change from an apparently permitted address to a private, loopback, link-local, or otherwise restricted destination. This is a CWE-918 condition caused by an incomplete validation boundary and a time-of-check/time-of-use gap.
Potential impact
- Requests may reach internal administrative or cloud metadata services
- Sensitive response data could be exposed if webhook responses are processed or returned
- Internal service availability or configuration could be affected
- Network segmentation controls may be weakened from the webhook worker's position
- Credentials or tokens accessible to reachable services could be targeted
- Requests may reach internal administrative or cloud metadata services
- Sensitive response data could be exposed if webhook responses are processed or returned
- Internal service availability or configuration could be affected
- Network segmentation controls may be weakened from the webhook worker's position
- Credentials or tokens accessible to reachable services could be targeted
General mitigation guidance
Mitigation generally focuses on enforcing destination safety at the moment of connection rather than relying only on webhook creation-time checks.
Common defensive patterns include:
- Resolve and validate destination addresses immediately before connecting
- Re-check every resolved address and reject private, loopback, link-local, multicast, and other restricted ranges
- Prevent DNS rebinding across redirects, retries, and connection attempts
- Use an outbound proxy or egress policy with an explicit allowlist of permitted destinations
- Restrict webhook worker network access and runtime privileges
- Avoid exposing sensitive response bodies or credentials to webhook integrations
- Apply consistent validation to all webhook delivery paths
Mitigation generally focuses on enforcing destination safety at the moment of connection rather than relying only on webhook creation-time checks.
Common defensive patterns include:
- Resolve and validate destination addresses immediately before connecting
- Re-check every resolved address and reject private, loopback, link-local, multicast, and other restricted ranges
- Prevent DNS rebinding across redirects, retries, and connection attempts
- Use an outbound proxy or egress policy with an explicit allowlist of permitted destinations
- Restrict webhook worker network access and runtime privileges
- Avoid exposing sensitive response bodies or credentials to webhook integrations
- Apply consistent validation to all webhook delivery paths
How teams detect issues like this
Detection approaches commonly include:
- Static analysis and code review checks for URL validation performed separately from connection-time DNS resolution
- Review signals such as direct DNS lookups followed by HTTP requests without address revalidation
- Tests covering rebinding, redirects, IPv4 and IPv6 representations, and private address ranges
- Network monitoring for webhook workers making connections to internal, loopback, link-local, or metadata-service addresses
- Egress firewall and service-mesh policies that alert on or block unauthorized destinations
- Automated security review tools that identify SSRF-prone URL-fetching patterns
Detection approaches commonly include:
- Static analysis and code review checks for URL validation performed separately from connection-time DNS resolution
- Review signals such as direct DNS lookups followed by HTTP requests without address revalidation
- Tests covering rebinding, redirects, IPv4 and IPv6 representations, and private address ranges
- Network monitoring for webhook workers making connections to internal, loopback, link-local, or metadata-service addresses
- Egress firewall and service-mesh policies that alert on or block unauthorized destinations
- Automated security review tools that identify SSRF-prone URL-fetching patterns
