CrewAI Quietly Fixed an SSRF Gap Agent Fetch Tools Can Share

CrewAI 1.15.17 shipped on August 20, 2026 with a Bug Fixes line most readers will scroll past: “Pin SSRF checks to each redirect hop and peer IP.” There is no advisory behind it, no CVE identifier and no severity rating. But the change it describes, pinning an agent's outbound fetch to the IP address that was actually validated, on every redirect hop, is the pattern every agent tool that fetches a model-supplied URL needs, and the one reference implementation we read for this post does not have.

The stakes are structural rather than dramatic. An agent's fetch tool takes a URL the model chose, often from content the model read elsewhere, and makes a real network request from inside your infrastructure. That is the textbook shape of server-side request forgery, CWE-918. What makes the CrewAI change worth a close read is that it is not the first SSRF hardening pass on this code path; it is the fifth since May, and the earlier June pass already earned a CVE. The August fix closes a narrower, more subtle gap than “only the first URL was checked,” and getting that distinction right is the point of this post.

This guide covers what 1.15.17 actually changed, the precise mechanism of the gap it closes, the three validation designs CrewAI has moved through on one fetch path, why one-time URL validation fails by construction according to OWASP and MITRE, what the MCP reference fetch server does by comparison, and a six-row audit checklist you can run against any fetch tool in your own harness.

The CrewAI 1.15.17 release was published on August 20, 2026 at 00:27 UTC. Its Bug Fixes section contains the line that prompted this post, verbatim: “Pin SSRF checks to each redirect hop and peer IP.” The commit behind it is titled “fix(tools): pin SSRF checks to each redirect hop and peer IP (#6981)”, which ties the release line to one specific pull request: PR #6981, opened and merged on August 17 by the GitHub user theCyberTech. Just under three days separate the merge from the release.

The diff is not small: 767 additions and 70 deletions across 19 files. It touches the shared safe-request helper in crewai_tools/security/safe_requests.py, adds a new security/ssrf_adapter.py, updates security/safe_path.py, the docs-site RAG loader and the URL read tool, plus five documentation files and a set of tests. One attribution note: the PR body is wrapped in markers showing it was drafted by a Cursor background agent on the contributor's behalf. The quotes in this post are therefore attributed to the PR description, not to a named engineer, and this is a routine contributor PR merged by a maintainer, not a CrewAI security bulletin.

The release carries four other items, each one line in the notes: declarative conversational-flows documentation; handling of oversized single messages during chunking; a fix to how the URL hostname is used as the server_name for MCP HTTP and SSE servers; and a fix for native tool calls that were broken over the OpenAI Responses API. None of them relate to the SSRF change.

It would be easy to read the changelog line as “CrewAI was only validating the first URL and ignoring redirects.” That was true of CrewAI's original design, and Section 03 covers it, but it was not true of the code immediately before 1.15.17. The PR description is explicit that safe_get already checked the request URL and each redirect's Location header. The problem was what happened after the check passed.

In the PR's own words, each hop still used requests.get. urllib3 resolves DNS again when it opens the socket. The IP that validate_url checks can differ from the IP that the socket uses. Validation looked at one answer; the connection used another. That is a time-of-check to time-of-use mismatch, and the attack class it admits is DNS rebinding: a hostname that resolves to a harmless public address when it is checked and to an internal one when it is dialled. The second vector is simpler. If an HTTP proxy is in the path, the proxy becomes the connected peer, and the real destination IP is never checked at all.

The fix, as the PR describes it, is a six-step sequence and a session-level change. Resolve the host once with socket.getaddrinfo. Raise an error if any returned address is private or reserved. Do not connect if that check fails. Connect with socket.connect using the address from the first step, not the hostname. After connecting, call getpeername() and re-check the peer against the same private/reserved blocklist. Close the socket if that second check fails. Alongside it, the safe-fetch session now sets trust_env=False and proxies={}, and rejects a non-empty proxies argument unless an explicit escape hatch is enabled. That session change is what closes the proxy vector; the post-connect getpeername() check is what closes the rebinding one.

Notice what is being validated now. Not a URL string, and not even a DNS answer, but the address the operating system reports as the other end of an open socket. That is the only point at which “where is this request going” has a definite answer, which is why OWASP's guidance, covered in Section 04, insists on validation at request time rather than at parse time.

CrewAI's fetch guard has been through three distinct designs in 2026, and the public record is unusually complete because each step left a pull request, an issue, or a CVE behind. The first design is documented in issue #6520, filed July 12 by a security researcher and closed July 14 because it was already fixed. The issue describes the original validate_url as resolving and blocklisting the supplied hostname once, then returning the original URL string unchanged, after which the scrape tools fetched it with requests.get and default redirect-following, with no re-validation of the redirect target. A public host that responded with a 30x to an internal address walked straight past the guard. That is the design the phrase “only the initial request was checked” accurately describes.

That original bug has a CVE. According to the researcher's own timeline inside the issue, it was reported through Bugcrowd on June 12, fixed by PR #6331 (merged June 26, shipped as 1.15.1), and the Bugcrowd ticket was closed as a false positive on July 10, after the fix had already shipped. The record was published as CVE-2026-62240 on July 13, affecting CrewAI versions before 1.15.1, scored 8.3 (High) under CVSS 4.0 and 7.4 (High) under CVSS 3.1, with a weakness class of CWE-918. VulnCheck's advisory independently reports the same 8.3. Those scores belong to the June bug and to nothing else.

The second design is the one PR #6981 found in place in August: validate the request URL, and also validate each redirect's Location header. That closes the redirect bypass at the URL level and is what CVE-2026-62240 was about. It does not close the gap between the address that was validated and the address the socket dials, which is the third design's job.

Zoom out and the pattern is incremental hardening rather than a single clean fix. Five merged pull requests with SSRF in the title touched this path between May 5 and August 17: #5711 on May 5 (“validate IPs on every redirect hop to prevent SSRF bypass”), #6038 on June 4 (“re-validate redirects and pin peer IP to close SSRF bypass”), #6331 on June 26 (the CVE fix), #6795 on August 3 (which closed an SSRF in the arXiv paper tool's PDF download and a DNS-rebinding gap in safe_get), and #6981 on August 17. Read the titles of #6038 and #6981 side by side and you can see that “pin the peer IP” was attempted in June and had to be revisited in August. That is what real hardening looks like on a shared fetch helper that several tools depend on.

The broader context matters too. CERT/CC's VU#221883, first released March 30 and last revised May 20, bundled four CrewAI CVEs, one of them a separate SSRF via improper URL validation in the RAG search tools (CVE-2026-2286), alongside two remote code execution findings and an arbitrary local file read. CrewAI's fetch and tool surface has drawn multiple independent SSRF findings across 2026. None of that makes the framework unusual; it makes it visible, which is the more useful property for anyone auditing their own tools against the same classes.

None of this is specific to CrewAI, which is why the changelog line is worth generalising. The vulnerability class has a definition, a prevention cheat sheet, and a well-understood reason why checking the URL string once is not enough. The reason is that a URL is an instruction to the transport, not a destination. Between the moment your code approves it and the moment a packet leaves the host, two things can change it: the server on the other end can answer with a redirect, and the resolver can answer a second lookup with a different address.

The OWASP SSRF Prevention Cheat Sheet makes three points that map directly onto the CrewAI history. First, its blunt instruction on redirects: “Disable the support for the following of the redirection in your web client in order to prevent the bypass of the input validation.” That single sentence is the whole of Design A's problem. Second, it warns that validating a domain name through DNS resolution “opens up the application to attacks” because an attacker can bind a legitimate domain name to an internal IP address, which is the rebinding class behind Design B's remaining gap. Third, its remediation for that gap is to resolve both A and AAAA records and apply the same validation at request time, not only at initial validation. PR #6981's getaddrinfo plus post-connect getpeername() sequence is one concrete implementation of the request-time half of that recommendation.

Library defaults decide how much of this you inherit without noticing. The two Python HTTP clients in play here, requests and httpx, disagree on the most important default of all.

Here is the interpretation we would offer. Every one of CrewAI's five hardening passes was an attempt to move validation from “a property of the URL string” to “a property of the connection.” The first passes re-validated more strings (each Location header). The last one stopped trusting strings at all and checked the socket. That is the right direction, and it is the direction OWASP's request-time guidance has pointed for years. What makes agent tools different from the classic web-app SSRF case is only the source of the URL: in a web app it is a user form field; in an agent it is whatever the model decided after reading untrusted content. The defence does not change. The likelihood that the input is adversarial goes up.

To see how one reference implementation compares, we read the source of the official MCP fetch server in the modelcontextprotocol/servers repository, src/fetch/src/mcp_server_fetch/server.py, at its most recent edit, dated March 15, 2026. It fetches through httpx with follow_redirects=True at two call sites and contains no SSRF-specific validation logic anywhere in the file: no private-IP check, no per-hop re-validation of redirect targets, no peer-IP pinning. Searching the file for the obvious terms (redirect, SSRF, validate, resolve, peer, metadata) turns up only the two redirect-following flags.

That is a precise, checkable claim, and it should be read precisely. The reference server is a reference, not a hardened product, and its maintainers may reasonably expect it to run behind network controls. But it is the fetch server the official reference repository ships, and it sits below Design A on the table above: one URL in, redirects followed, and no check at any point. Anyone running it against untrusted URLs from inside a private network or a cloud instance with a metadata endpoint is relying entirely on controls outside the tool.

Two days before this release, CVE-2026-75130 was published against the Context7 MCP server, and it is tempting to file both under “agent tooling had a bad week.” They are different classes and deserve different fixes. Context7's issue is prompt injection: the server delivers untrusted instructions into the agent's context on a routine documentation request, and the agent acts on them. CrewAI's issue is SSRF: the agent's own outbound fetch reaches a destination it was never meant to reach. One is an inbound content-trust problem solved by treating served content as data, not instructions; the other is an outbound network-egress problem solved by validating where a socket actually connects. They chain together naturally, since an injected instruction is one way a model ends up choosing a hostile URL, but they are not the same bug. We cover the Context7 advisory, its two divergent CVSS scores and its open patch status in our CVE-2026-75130 write-up, and the broader chain from injected content to tool misuse in our prompt-injection taxonomy for production agents.

This is the durable asset. Each row is a question you can answer about your own harness's fetch tool, grounded in OWASP's cheat sheet or CWE-918, with a mechanism-level way to test it in a lab you control. No working payloads, no target addresses beyond the classes OWASP itself names. The last two columns record what the primary sources say about CrewAI 1.15.17 and about the MCP reference fetch server.

What to do with the answers depends on which side of the table you are on.

The quiet way this fix shipped is itself the lesson. A team that relies on advisories and scanner alerts to know when to upgrade would never hear about 1.15.17's SSRF change, because there is no advisory to alert on. Meanwhile the same team's own fetch tool, the one a contractor wrote in an afternoon on top of requests.get, has never been audited against any of the six rows above. The useful response is not to worry about CrewAI specifically. It is to recognise that any tool which takes a URL from a model and opens a socket is a piece of network egress infrastructure, and to review it the way you would review a proxy or a firewall rule, not the way you would review a string parser.

Looking forward, we expect two things. First, more framework changelogs like this one: hardening passes that land as single lines because they close a design weakness rather than a reported exploit, with no CVE to anchor coverage. Reading release notes for your agent dependencies, not just your web framework, becomes a real operational habit. Second, we expect the validate-and-pin pattern to migrate from framework internals into a shared layer, an egress sidecar or a hardened fetch library, because five incremental passes on one helper is the kind of history that eventually convinces maintainers to stop re-implementing the same guard per tool. The still-open PR #7001, which proposes moving the pinning into a single outbound-fetch module, points in that direction, though nothing about it has shipped.

For teams choosing a framework, this record is a point in CrewAI's favour, not against it: the fixes are public, dated and attributable, which is more than most tools offer. Our comparison of LangGraph and CrewAI for agentic orchestration covers the architectural trade-offs. For the wider picture of how often agentic systems now feature in real breach data, see our analysis of agentic systems in 2026 breach reporting, and for the server-side controls that should sit around any fetch tool, our MCP server security engineering guide. When we build agent systems for clients through our AI transformation engagements and custom web development work, the fetch-tool audit above is part of the standard review, precisely because the tools that look simplest are the ones nobody checks.