praisonaiagents vulnerable to SSRF in web_crawl tool via redirect-following and DNS rebinding (validate-then-fetch gap)
- Product
- praisonaiagents
- CVE
- CVE-2026-55524
- Affected
- praisonaiagents < 1.6.58
- Fixed in
- 1.6.58
Last verified against sources: October 26, 2026
Am I affected?
praisonaiagents: affected praisonaiagents < 1.6.58. Fixed in 1.6.58.
- Check your version: run
pip show praisonaiagents. Versions < 1.6.58 of praisonaiagents are affected. [1]
What to do now
- Upgrade to the fixed version: run
pip install --upgrade "praisonaiagents>=1.6.58"(first patched version 1.6.58). [1] - Disable redirect following (follow_redirects=False; for urllib use a redirect handler that re-validates), or re-validate every redirect hop's resolved IP. [1]
- Apply the deny check to both the validator and the actual socket target. [1]
- Resolve the hostname once, validate that IP, and connect to that exact validated IP (pin it) rather than re-resolving. [1]
General practice, not from the source: if the affected software could read tokens or credentials, rotate them after upgrading; pin versions and review changes before updating tools your agents run.
What happened
- The web_crawl tool performs its SSRF check only on the initial URL. [1]
- It resolves the hostname once with socket.gethostbyname and rejects private/loopback/link-local results. [1]
- It then passes the URL to a fetcher that uses httpx.Client(follow_redirects=True) - or urllib.request.urlopen when httpx is absent, which also follows redirects - and re-resolves the hostname at connect time, with no further validation. [1]
- This validate-here/fetch-there gap is bypassable two independent ways: HTTP redirects and DNS rebinding. [1]
Impact
- An agent with web_crawl can be made to read internal-only HTTP services and cloud instance-metadata endpoints (e.g. IAM credentials), with the response body returned in the tool output. [1]
- Scope is Changed because the request pivots into the internal network. [1]
- In the redirect bypass, validation approves an attacker domain resolving to a public IP, the attacker server replies 302 Location: http://169.254.169.254/... (or any internal host), and the fetcher follows it unchecked. [1]
- In the DNS rebinding bypass, a low-TTL attacker domain answers public to the validator and private/loopback to fetch. [1]
What was done
- praisonaiagents is affected below 1.6.58 and patched in 1.6.58. [1]
- The advisory recommends resolving the hostname once, validating that IP, and connecting to that exact validated IP (pin it) rather than re-resolving. [1]
- The advisory recommends disabling redirect following (follow_redirects=False; for urllib use a redirect handler that re-validates), or re-validating every redirect hop's resolved IP. [1]
Sources
- GHSA-vg6p-v9vm-6fgj — GitHub Advisory Database
Every statement above was checked against these sources before publishing. Spotted an error? Tell us and we will correct it with a dated note.
Share advisory brief with your team
Copy a plain-text summary for Slack, GitHub issues, or team security channels.
[CVE-2026-55524] praisonaiagents vulnerable to SSRF in web_crawl tool via redirect-following and DNS rebinding (validate-then-fetch gap)
Product: praisonaiagents | Affected: praisonaiagents < 1.6.58 | Fixed in: 1.6.58
Summary: The web_crawl tool performs its SSRF check only on the initial URL.
Source & remediation on AgentArmorHQ: https://agentarmorhq.com/incidents/2026/08/cve-2026-55524-praisonaiagentsCorrections
Report an error or request a correction. We review requests within 5 business days and add a dated correction note.
Discussions for CVE-2026-55524
Ask questions or share configuration tips. Governed by our Community Rules & Terms.
No posts match this filter yet.
Be the first to ask a question or share a working tip.