CVE-2026-60091 Overview
CVE-2026-60091 is an unauthenticated Server-Side Request Forgery (SSRF) vulnerability in PraisonAI versions before 4.6.78. The flaw resides in the Jobs API /api/v1/runs endpoint, where the webhook_url parameter is validated at request time but re-resolved at connection time. This time-of-check to time-of-use (TOCTOU) gap enables DNS rebinding attacks against internal services. Attackers can reach protected internal endpoints via a blind SSRF technique without authentication. The vulnerability is categorized under CWE-918 (SSRF).
Critical Impact
Unauthenticated remote attackers can bypass URL allowlists using DNS rebinding to interact with internal-only services from the PraisonAI host.
Affected Products
- PraisonAI versions prior to 4.6.78
- Deployments exposing the Jobs API /api/v1/runs endpoint
- Environments accepting user-supplied webhook_url values
Discovery Timeline
- 2026-07-10 - CVE-2026-60091 published to NVD
- 2026-07-10 - Last updated in NVD database
Technical Details for CVE-2026-60091
Vulnerability Analysis
The Jobs API /api/v1/runs endpoint accepts a webhook_url parameter used to deliver job execution results. PraisonAI performs URL validation when the request arrives, likely checking that the hostname does not resolve to a private or loopback address. However, the application resolves the hostname a second time when it establishes the outbound HTTP connection. This second resolution is not validated against the initial check.
An attacker controlling an authoritative DNS server can return a public IP address on the first lookup and a private IP address such as 127.0.0.1, 169.254.169.254, or an internal RFC 1918 address on the second lookup. This DNS rebinding technique defeats hostname-based allowlists. The result is a blind SSRF where the attacker cannot directly read responses but can trigger requests to arbitrary internal endpoints.
Root Cause
The root cause is a TOCTOU flaw between DNS resolution used for validation and DNS resolution used for connection. Validating the hostname string rather than pinning the resolved IP address allows the DNS record to change between the two lookups. The webhook_url handler trusts a name that was previously safe without enforcing the same target address at connection time.
Attack Vector
Exploitation requires no authentication and only network access to the PraisonAI Jobs API. An attacker submits a POST request to /api/v1/runs with a webhook_url pointing to a hostname under their control with a very short DNS Time-To-Live (TTL). The first DNS lookup returns a benign public IP that passes validation. The second lookup, performed when PraisonAI dispatches the webhook, returns an internal IP such as a cloud metadata service or an internal admin API. PraisonAI then sends the outbound request to the internal target. See the GitHub Security Advisory and the VulnCheck Security Advisory for further technical detail.
Detection Methods for CVE-2026-60091
Indicators of Compromise
- Outbound HTTP requests from the PraisonAI host to private IP ranges, loopback addresses, or cloud metadata endpoints such as 169.254.169.254
- Inbound POST requests to /api/v1/runs with webhook_url values whose DNS records have unusually short TTLs
- DNS queries from the PraisonAI host resolving the same hostname to different addresses within seconds
Detection Strategies
- Correlate application logs of accepted webhook_url submissions with subsequent outbound connections to non-public IP space
- Inspect DNS resolver logs for hostnames returning both public and private A records within a single job lifecycle
- Alert on any request the PraisonAI service makes to cloud instance metadata services
Monitoring Recommendations
- Enable egress traffic logging on hosts running PraisonAI and forward flow logs to a centralized analytics platform
- Monitor /api/v1/runs request rates and payload diversity to identify enumeration activity
- Track DNS TTL distributions for hostnames submitted through the Jobs API and flag values below 30 seconds
How to Mitigate CVE-2026-60091
Immediate Actions Required
- Upgrade PraisonAI to version 4.6.78 or later
- Restrict network egress from PraisonAI hosts to only required destinations, blocking RFC 1918, loopback, and link-local ranges
- Require authentication in front of the Jobs API using a reverse proxy or API gateway until patching is complete
Patch Information
The issue is fixed in PraisonAI 4.6.78. Refer to the GitHub Security Advisory GHSA-4w49-gwv8-fpjg for release details and remediation guidance.
Workarounds
- Deploy an egress proxy that resolves and pins destination IP addresses before allowing the connection
- Enforce IMDSv2 on AWS instances to mitigate metadata service abuse via blind SSRF
- Block outbound traffic from the PraisonAI service account to private address ranges at the network layer
# Example iptables egress restriction for the PraisonAI host
iptables -A OUTPUT -m owner --uid-owner praisonai -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner praisonai -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner praisonai -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner praisonai -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner praisonai -d 169.254.0.0/16 -j REJECT
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
