CVE-2025-58067

Executive Summary

CVE-2025-58067 is a moderate-severity open redirect vulnerability in the google_sign_in gem by Basecamp, used to integrate Google Sign-In into Ruby on Rails applications. The flaw allows an attacker to redirect a user to an arbitrary external origin if the proceed_to session value is set to a protocol-relative URL (e.g., //evil.com). While the session value is normally controlled by the library or application, it may be possible for a malicious site to set this value via a form submission, potentially chaining with other attacks to modify OAuth2 request parameters. The vulnerability is patched in version 1.3.1, and no workarounds are available.

Supply Chain & Package Security

This vulnerability affects the Ruby gem google_sign_in, which is distributed via RubyGems. Organizations using this gem in their Rails applications should immediately update to version 1.3.1 or later. The supply chain risk is moderate, as the gem is widely used for Google authentication in Rails apps. No known malicious packages or typosquatting variants have been reported, but teams should verify gem integrity via checksums.

CVSS Breakdown & Threat Level

• CVSS Score: 4.2 (Medium)
• Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N
• Attack Vector: Network
• Attack Complexity: High (requires chaining with another attack to modify OAuth2 parameters)
• Privileges Required: None
• User Interaction: Required (victim must click a crafted link or submit a form)
• Scope: Unchanged
• Confidentiality Impact: Low (potential leakage of OAuth tokens if redirected to attacker-controlled site)
• Integrity Impact: Low (redirect could lead to phishing or token theft)
• Availability Impact: None

Threat Level: Medium. Exploitation requires chaining with another vulnerability to modify OAuth2 request parameters, making it less likely to be exploited in isolation. However, if chained, it could lead to account takeover.

Deep Dive & Mechanics

The google_sign_in gem handles the OAuth2 flow for Google Sign-In. After successful authentication, the gem redirects the user to a URL stored in the proceed_to session variable. This variable is intended to be set by the application to return the user to the page they were on before authentication.

The vulnerability arises because the gem does not validate whether the proceed_to URL is a protocol-relative URL (e.g., //evil.com). When a protocol-relative URL is used, the browser interprets it as a URL with the same protocol as the current page (e.g., https://evil.com), allowing an attacker to redirect the user to an arbitrary external domain.

The attack vector involves:

1. An attacker crafts a malicious site that submits a form to the vulnerable Rails application, setting the proceed_to session value to //attacker.com.
2. The victim, already authenticated or in the process of authenticating via Google Sign-In, is redirected to //attacker.com after the OAuth flow completes.
3. If the attacker can also modify OAuth2 request parameters (e.g., via a separate vulnerability), they could steal the OAuth token or authorization code.

The session value is typically only written and read by the library or application, but form submissions can modify session values if the application uses cookie-based sessions and does not protect against cross-site request forgery (CSRF) on the session-setting endpoint.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 1.3.1):

# In the gem's controller or helper
def redirect_to_proceed_to
  proceed_to = session[:proceed_to]
  if proceed_to.present?
    redirect_to proceed_to
  else
    redirect_to root_path
  end
end

The code directly uses the proceed_to value without validating it, allowing protocol-relative URLs.

Patched Code (version 1.3.1):

# In the gem's controller or helper
def redirect_to_proceed_to
  proceed_to = session[:proceed_to]
  if proceed_to.present? && valid_url?(proceed_to)
    redirect_to proceed_to
  else
    redirect_to root_path
  end
end

def valid_url?(url)
  uri = URI.parse(url)
  uri.host.present? && uri.scheme.present? && !url.start_with?('//')
rescue URI::InvalidURIError
  false
end

The patched code validates that the URL has a scheme and host, and explicitly rejects protocol-relative URLs (those starting with //).

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Rails application using google_sign_in gem version < 1.3.1.
• Ability to craft a form submission to set the proceed_to session value (requires CSRF bypass or the application does not protect the session-setting endpoint).

Exploitation Steps:

1. Identify the endpoint that sets the proceed_to session value (e.g., a login page or a redirect parameter).
2. Craft a malicious HTML page that submits a form to that endpoint with proceed_to set to //attacker.com.
3. Lure the victim to the malicious page (e.g., via phishing email).
4. The victim submits the form, setting the session value.
5. The victim then authenticates via Google Sign-In (or is already authenticated).
6. After authentication, the gem redirects the victim to //attacker.com, where the attacker can capture the OAuth token or perform phishing.

Example Form:

<form action="https://victim-app.com/auth/google_sign_in" method="POST">
  <input type="hidden" name="proceed_to" value="//attacker.com">
  <input type="submit" value="Click here">
</form>

Blue Team

Detection:

• Monitor for unusual proceed_to values in session data or logs.
• Look for form submissions to authentication endpoints from unexpected origins.
• Use web application firewalls (WAF) to block protocol-relative URLs in redirect parameters.

Prevention:

• Update to google_sign_in version 1.3.1 or later.
• Implement CSRF protection on all endpoints that modify session values.
• Validate all redirect URLs server-side, rejecting protocol-relative URLs.

Indicators of Compromise (IOCs)

• Network: HTTP requests to authentication endpoints with proceed_to parameter containing // (e.g., proceed_to=//evil.com).
• Logs: Session data containing protocol-relative URLs in the proceed_to field.
• User Agent: Unusual referrer headers from external sites submitting forms to authentication endpoints.
• File: Modified google_sign_in gem files (check version in Gemfile.lock).

Detection Engineering

YARA Rule

rule CVE_2025_58067_GoogleSignIn_OpenRedirect {
    meta:
        description = "Detects vulnerable google_sign_in gem code with protocol-relative URL redirect"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-58067"
        severity = "medium"
    strings:
        $vuln_code = /redirect_to\s+session\[:proceed_to\]/ nocase
        $protocol_relative = /redirect_to\s+\/\/[a-zA-Z0-9]/ nocase
    condition:
        $vuln_code or $protocol_relative
}

Sigma Rule

title: CVE-2025-58067 - Google Sign-In Open Redirect via Protocol-Relative URL
id: 8a7b3c2d-1e5f-4a6b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests with protocol-relative URLs in the proceed_to parameter
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'proceed_to=//'
    condition: selection
falsepositives:
    - Legitimate use of protocol-relative URLs (rare)
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-58067 - Google Sign-In Open Redirect via Protocol-Relative URL"; flow:to_server,established; content:"POST"; http_method; content:"proceed_to=//"; http_client_body; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Update the google_sign_in gem to version 1.3.1 or later: bundle update google_sign_in.
• Verify the update in Gemfile.lock.

Long-term:

• Implement input validation for all redirect parameters in your application.
• Use a whitelist of allowed redirect URLs.
• Enable CSRF protection on all endpoints that modify session state.
• Conduct a security review of all OAuth2 flows.

Workarounds: None available. The only fix is to update the gem.

Valters IT
Securing Digital Frontiers