CVE-2025-27221

What it actually does

The Ruby URI gem before 1.0.3 can incorrectly retain the userinfo portion of a URI, such as username, password, or token-like credentials embedded before the host, when URI.join, URI#merge, or URI#+ changes the destination host. As a result, code that combines a credential-bearing base URI with an attacker-controlled or cross-origin URI may unintentionally produce a URL where the original credentials are attached to a different host. If that URL is logged, redirected, fetched by an HTTP client, or exposed to downstream services, authentication material may be disclosed to an unintended party.

Why it matters to the business

Applications that construct outbound URLs using Ruby URI may leak embedded credentials to external or untrusted destinations, potentially exposing service passwords, API tokens, or internal integration credentials. The risk is highly application-dependent and the public exploitation signal is currently low, with no CISA KEV listing, no ransomware association, and low EPSS, but the issue has been public for over a year and should be remediated as part of dependency hygiene, especially in systems that handle URLs containing credentials.

How an attack unfolds

An attacker needs a code path where an application uses the affected Ruby URI methods to combine URLs and where at least one input can influence the target URI or host. The vulnerable application starts with a base URI that includes credentials in the userinfo component, for example a service URL containing a username and password. The attacker supplies, or causes the application to process, a URI that changes the host. In vulnerable versions, the merge operation may keep the original userinfo while replacing the host with the attacker-controlled host. If the application then performs an outbound request, follows a redirect, stores the generated URL, or emits it to logs or telemetry, the credentials can be sent to or observed by the attacker-controlled destination. This does not generally provide direct code execution; the primary outcome is credential disclosure that may enable follow-on access depending on what the leaked credentials protect.

How to fix it

Upgrade the Ruby URI gem to version 1.0.3 or later. For source-based consumers, apply the upstream fix at commit c13dfc2164bc4af31085e709ab348fdbd527013f or use a Ruby distribution that includes the patched URI gem. Update lockfiles and redeploy all applications that bundle the vulnerable gem. As defense in depth, avoid embedding credentials in URLs; store credentials separately and pass them through scoped authentication mechanisms such as headers or client configuration. Before merging or joining URLs, explicitly clear userinfo when the host changes, validate the final host against an allowlist, and prevent credentials from being forwarded across origins or redirects.

How to confirm the fix worked

Confirm runtime and packaged dependency versions show uri >= 1.0.3 in all Ruby applications, containers, build artifacts, and lockfiles. Validate with a regression test that merging a credential-bearing URI with a URI on a different host does not retain the original userinfo. Review dependency manifests such as Gemfile.lock, gemspec files, vendored gems, container SBOMs, and Ruby default/bundled gem versions. Exercise application flows that construct outbound URLs and verify that generated URLs do not contain username:password@ when the destination host differs from the original credential scope.

Typical attack path

1. Identify a Ruby application or library path that uses URI.join, URI#merge, or URI#+ to construct URLs.
2. Find or influence a flow where the base URL contains userinfo credentials such as username:password@host.
3. Provide a URL or redirect target that changes the host to an attacker-controlled or observable domain.
4. Trigger the vulnerable URI merge operation so the credentials are retained on the new host.
5. Observe the leaked credentials through an inbound request, proxy log, application log, redirect target, or other telemetry.
6. Use the exposed credentials for follow-on authentication attempts against the service they were intended to protect.

How to detect it

Investigate whether applications using vulnerable URI versions generated or requested URLs containing userinfo before an unexpected host. Useful sources include application logs, HTTP client debug logs, reverse proxy logs, egress proxy logs, DNS logs, outbound firewall logs, APM traces, error reporting systems, and centralized log stores. Look for URLs with the pattern scheme://username:password@host, especially where the host is external, newly observed, user-controlled, or inconsistent with the service that owns the credentials. Correlate suspicious entries with code paths using URI.join, URI#merge, or URI#+ and with inbound requests that supplied absolute URLs, redirect targets, callback URLs, webhook URLs, import URLs, or next/return parameters. If leakage is suspected, treat the embedded userinfo as compromised, rotate the credentials, and review authentication logs for follow-on use.

• URI.join
• URI#merge
• URI#+
• ://[^/[:space:]]+:[^/@[:space:]]+@
• http://[^/[:space:]]+:[^/@[:space:]]+@
• https://[^/[:space:]]+:[^/@[:space:]]+@
• userinfo
• Gemfile.lock
• uri (1.0.0)
• uri (1.0.1)
• uri (1.0.2)

What your security team should do

• Prioritize upgrade of the uri gem to 1.0.3 or later across Ruby applications, especially services that construct outbound URLs, handle redirects, or integrate with credential-bearing service URLs.
• Search code for URI.join, URI#merge, and URI#+ usage and review whether user-controlled input can change the host of a URL containing userinfo.
• Eliminate credentials embedded in URLs wherever possible and rotate any credentials that may have been exposed through logs, proxies, telemetry, or outbound requests.
• Add automated tests or static checks to prevent userinfo from being retained when URL construction changes hosts.
• Review egress and application logs for historical requests containing userinfo directed to unexpected domains.
• Ensure secret-scanning coverage includes URLs with embedded credentials in logs, traces, error reports, and message queues.