CVE-2026-77404

## Summary A query parameter injection vulnerability exists in the AMQP client's connection URI formatting logic. When generating or parsing connection URIs, TLS-related filesystem paths (such as certificates or keys) are appended directly to the URI's query string using string concatenation rather than secure URL encoding via functions like `url.QueryEscape`. If an application handles a TLS file path containing special character delimiters (such as `&` or `=`), these characters are interpreted as parameter separators by the URI parser. If the resulting `URI.String()` output is subsequently re-parsed via `ParseURI`, the injected fields can silently overwrite or hijack critical configuration parameters, forcing the client to use arbitrary connection settings or alternate TLS files. --- ## Vulnerability Details ### Mechanism The vulnerability lies within the lack of proper escaping when compiling connection string components into a raw URL format: ```go // Example of insecure string concatenation during URI building uri := fmt.Sprintf("amqps://user:pass@host/%s?certfile=%s&keyfile=%s", vhost, certPath, keyPath) ``` Because `certPath` and `keyPath` are not passed through `url.QueryEscape`, special URL characters preserve their control meanings. For instance, if a user supply a certificate path named: `/tmp/cert=foo&keyfile=/evil/path` The generated string translates into: `...?certfile=/tmp/cert=foo&keyfile=/evil/path&keyfile=/original/path` When this string passes back through `ParseURI` (common in connection re-dial routines or configuration replication steps), standard URL parsing mechanics treat the string as multiple distinct parameters. Depending on map assignment order inside the parser, the injected keys take precedence over the original parameters. ### Impact By manipulating the file paths used for TLS assets, an attacker or compromised local sub-system can: * Inject arbitrary alternative options or override protocol settings. * Substitute or switch k