PraisonAI EUVD-2026-65516

Two exploitation paths with different prerequisites exist. Path 1 (gaierror fail-open): No special conditions - unauthenticated network access to the Jobs API endpoint is sufficient. Submitting any unresolvable domain as webhook_url bypasses all validation. This works against default configurations of PraisonAI with the Jobs API enabled. Exploitation is limited to deployments running praisonai 4.6.48 or below and requires that the server can make outbound HTTP to the target internal address (not blocked by egress controls). Path 2 (DNS rebinding): Requires attacker control of a domain with configurable DNS TTL (1 second or less) and a DNS hosting provider that allows rapid record updates. No authentication to PraisonAI is required. Exploitation requires the TOCTOU window between validation and HTTP dispatch to be large enough for the DNS flip - job execution latency aids the attacker. Both paths are unauthenticated per the CVSS PR:N vector confirmed by the GHSA advisory.

The published CVSS 6.8 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N) represents the DNS rebinding path, where AC:H is justified by the requirement for attacker-controlled DNS infrastructure with sub-second TTL. However, the gaierror fail-open bypass - confirmed by a single curl command in the GHSA proof-of-concept - requires no special infrastructure whatsoever, arguably meriting AC:L treatment on its own and a materially higher score. The combination of unauthenticated access (PR:N confirmed by GHSA), scope change (S:C reaching internal services), and high confidentiality impact (C:H via metadata credential exposure) makes this a genuine priority for cloud-hosted deployments. EPSS data was not provided. No CISA KEV listing is present, so active exploitation is not confirmed. The published detailed PoC lowers the exploitation bar significantly. The primary real-world risk is deployments on cloud infrastructure where the IMDS endpoint (169.254.169.254) is reachable and can expose IAM credentials or instance metadata to the attacker.

An unauthenticated attacker submits a job via the Jobs API with webhook_url set to an unresolvable internal-sounding domain (e.g., http://internal-service.corp/cb); the validator catches the gaierror and silently accepts the URL. If split-horizon DNS resolves the domain internally, the PraisonAI server POSTs job completion data to that internal service. Alternatively, the attacker registers attacker.com with a 1-second TTL pointing to a public IP, submits the job (validation passes), then flips the DNS record to 169.254.169.254 before job completion, causing PraisonAI to POST to the cloud metadata endpoint and potentially exposing AWS IAM credentials or GCP service account tokens. A detailed proof-of-concept for both paths is published in the GHSA advisory.