yoagent, a Rust agent library, shipped two releases in a day that change how its MCP client treats credentials. v0.26.0 landed on 29 October and v0.26.1 followed on 30 October. Both are on crates.io.
Redirects stay on the server’s origin
Before 0.26.0, yoagent’s HttpTransport followed any redirect, up to 10 hops. The underlying HTTP client drops Authorization and Cookie headers when a redirect goes to another host, but a custom header set with with_header, such as x-api-key, went wherever the server pointed. Nothing stopped a hop from https to http either.
Now redirects are followed only within the URL’s own origin (same scheme, host and port), so a 307 or 308 from /mcp to /mcp/ still works. A redirect anywhere else is an error that names where it pointed. You choose with HttpTransport::with_redirects(Redirects::None | SameOrigin | Any); Any is the old behaviour. The release notes call this a security fix, made at the request of the project’s own bot, yobuild, in PR #386. On wasm32 the browser’s fetch handles redirects itself, so the change applies to native targets.
Keys stay out of error text
v0.26.1 closes a second leak. When an MCP server was unreachable, the error carried the full URL. Some services put a key in the path or query, so that key reached the error and, from a tool call inside a run, the model and the logs as a failed tool result. Errors now name the server by scheme, host and port only. Key-like parts of a URL quoted back in a server’s error body or a JSON-RPC message (any path segment, query value, user name or password of 8 or more characters) are replaced with [redacted], and session ids are no longer logged.
Breaking changes and other fixes
McpErroris now#[non_exhaustive]and gainsMcpError::Http { status, message }, so exhaustivematcharms need a wildcard.- With
own_process_group, an MCP stdio command that exits on its own, such as annpxlauncher, now has its whole process group killed when the exit is seen. Before, whatever it started could keep running. - A 404 on an MCP notification now clears an expired session, as one on a call already did.
When we checked on 30 October, the project had not filed a GitHub security advisory or CVE for either change, and exploiting the redirect issue would need a malicious or compromised MCP server, or one that redirects to a host you do not control.
Why this matters
Custom headers are the usual way to pass API keys to hosted MCP servers, and most HTTP clients only protect the standard Authorization header across redirects. If your Rust agent talks to MCP servers through yoagent, update to 0.26.1 and check any match on McpError. If you use another client, test what it does with a cross-host redirect. As the rmcp 3.6.0 changes and Codewhale’s fail-open fixes showed, agent plumbing is where these gaps hide.

The Campfire
CommentsThanks. Your comment is waiting for the desk. Once it is approved it appears here within about a minute.
Add a comment