Summary
PraisonAI's Async Jobs API can be bypassed by an attacker-controlled hostname that appears public during webhook validation but resolves to a private or loopback address when the webhook is delivered. This may allow server-side request forgery against internal services, cloud metadata endpoints, or other restricted infrastructure.
PraisonAI's Async Jobs API can be bypassed by an attacker-controlled hostname that appears public during webhook validation but resolves to a private or loopback address when the webhook is delivered. This may allow server-side request forgery against internal services, cloud metadata endpoints, or other restricted infrastructure.
Affected context
The issue affects PraisonAI deployments that expose the Async Jobs API and allow users to provide webhook URLs. It becomes risky when hostname validation occurs separately from the later HTTP request, allowing DNS resolution to change between the validation step and webhook delivery.
The issue affects PraisonAI deployments that expose the Async Jobs API and allow users to provide webhook URLs. It becomes risky when hostname validation occurs separately from the later HTTP request, allowing DNS resolution to change between the validation step and webhook delivery.
Exploit preconditions
- Attack surface: Async Jobs API webhook configuration
- Required access: Ability to submit or influence a job request containing a webhook URL
- Trigger point: Webhook delivery after the job completes
- Why exploitation is possible: The hostname is validated before delivery, but the later request does not repeat validation, pin the approved destination IP, or use a transport-level private-network guard
- Attack surface: Async Jobs API webhook configuration
- Required access: Ability to submit or influence a job request containing a webhook URL
- Trigger point: Webhook delivery after the job completes
- Why exploitation is possible: The hostname is validated before delivery, but the later request does not repeat validation, pin the approved destination IP, or use a transport-level private-network guard
Why this happens
The vulnerability results from a time-of-check/time-of-use gap in SSRF protection. PraisonAI validates the hostname when the request and internal Job object are created, but later passes the original hostname to the HTTP client without ensuring that it still resolves to the same permitted public address. This maps primarily to CWE-918: Server-Side Request Forgery, with CWE-367: Time-of-check Time-of-use Race Condition describing the separation between validation and network use.
The vulnerability results from a time-of-check/time-of-use gap in SSRF protection. PraisonAI validates the hostname when the request and internal Job object are created, but later passes the original hostname to the HTTP client without ensuring that it still resolves to the same permitted public address. This maps primarily to CWE-918: Server-Side Request Forgery, with CWE-367: Time-of-check Time-of-use Race Condition describing the separation between validation and network use.
Potential impact
- Requests to loopback, private-network, or cloud-metadata services could be made from the PraisonAI host
- Internal service responses could be exposed to an attacker through webhook behavior
- Credentials or instance metadata could be targeted
- Internal network reconnaissance or limited service interaction may be possible
- Compromised internal endpoints could enable further compromise
- Requests to loopback, private-network, or cloud-metadata services could be made from the PraisonAI host
- Internal service responses could be exposed to an attacker through webhook behavior
- Credentials or instance metadata could be targeted
- Internal network reconnaissance or limited service interaction may be possible
- Compromised internal endpoints could enable further compromise
General mitigation guidance
Mitigation generally requires binding SSRF validation to the actual network destination used for delivery.
Common defensive patterns include:
- Resolve hostnames at send time and reject loopback, link-local, private, reserved, and unroutable addresses
- Pin the validated destination address or use a guarded transport so DNS changes cannot redirect the request
- Revalidate every redirect and disable redirects unless they are explicitly required
- Prefer an allowlist of approved webhook domains or egress destinations
- Restrict outbound network access from worker processes using network policy and least-privilege egress controls
- Avoid returning fetched response content to untrusted callers unless it is necessary and safely filtered
Mitigation generally requires binding SSRF validation to the actual network destination used for delivery.
Common defensive patterns include:
- Resolve hostnames at send time and reject loopback, link-local, private, reserved, and unroutable addresses
- Pin the validated destination address or use a guarded transport so DNS changes cannot redirect the request
- Revalidate every redirect and disable redirects unless they are explicitly required
- Prefer an allowlist of approved webhook domains or egress destinations
- Restrict outbound network access from worker processes using network policy and least-privilege egress controls
- Avoid returning fetched response content to untrusted callers unless it is necessary and safely filtered
How teams detect issues like this
Organizations can look for:
- Static analysis findings where URL validation is separated from the eventual HTTP request
- Code paths that validate hostnames only during parsing or object construction
- HTTP clients that resolve DNS again without destination pinning or guarded transports
- Missing checks for private, loopback, link-local, multicast, and cloud-metadata address ranges
- Egress policies and proxy logs showing job workers connecting to internal or metadata endpoints
- Security tests that simulate DNS changes between validation and request delivery
Automated code review and dependency-analysis tools may help identify incomplete SSRF fixes and unsafe URL-handling patterns.
Organizations can look for:
- Static analysis findings where URL validation is separated from the eventual HTTP request
- Code paths that validate hostnames only during parsing or object construction
- HTTP clients that resolve DNS again without destination pinning or guarded transports
- Missing checks for private, loopback, link-local, multicast, and cloud-metadata address ranges
- Egress policies and proxy logs showing job workers connecting to internal or metadata endpoints
- Security tests that simulate DNS changes between validation and request delivery
Automated code review and dependency-analysis tools may help identify incomplete SSRF fixes and unsafe URL-handling patterns.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
