CVE-2019-25211

Executive Summary

CVE-2019-25211 is a security advisory affecting the Gin-Gonic CORS middleware prior to version 1.6.0. The vulnerability lies in the parseWildcardRules function, which mishandles wildcard characters at the end of origin strings. This flaw allows attackers to bypass intended CORS restrictions, potentially enabling unauthorized cross-origin requests. For example, a rule intended to allow https://example.com/* could incorrectly permit https://example.community/*, and a rule for http://localhost/* could allow http://localhost.example.com/*. The vulnerability has a CVSS score of 0.0 in the NVD but is assessed here with a vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, reflecting low confidentiality and integrity impact with no availability impact. No public exploit code or nuclei template is available, but the issue is well-documented and easily exploitable.

Supply Chain & Package Security

This vulnerability affects the Gin-Gonic CORS middleware, a Go package commonly used in web applications built with the Gin web framework. As a supply chain risk, any application using an affected version of this middleware is vulnerable. Organizations should audit their Go module dependencies for github.com/gin-gonic/contrib/cors or similar packages and ensure they are updated to version 1.6.0 or later. The lack of a patch status in the NVD underscores the importance of proactive dependency management.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required; the attacker simply sends a crafted origin header.
• Privileges Required (PR): None (N) – No authentication is needed.
• User Interaction (UI): None (N) – The victim does not need to perform any action.
• Scope (S): Unchanged (U) – The vulnerable component and the affected resource are the same.
• Confidentiality (C): Low (L) – Limited information disclosure may occur.
• Integrity (I): Low (L) – Limited data modification is possible.
• Availability (A): None (N) – No impact on system availability.

Overall CVSS Score: 5.4 (Medium) – This reflects the potential for unauthorized cross-origin access, which could lead to data leakage or limited manipulation.

Deep Dive & Mechanics

The vulnerability resides in the parseWildcardRules function of the Gin-Gonic CORS middleware. This function is responsible for parsing CORS origin rules that include wildcards. The intended behavior is that a rule like https://example.com/* should only allow origins that match the pattern https://example.com/ followed by any path. However, due to improper validation, the wildcard is treated as a suffix match rather than a strict subdomain or path match.

For instance:

• Intended rule: https://example.com/* should allow https://example.com/anything but not https://example.community/.
• Actual behavior: The rule allows https://example.community/* because the wildcard matches any string ending with example.com/, but the dot in example.community is not properly handled.

Similarly, for http://localhost/*, the rule incorrectly allows http://localhost.example.com/* because the wildcard matches any string ending with localhost/, ignoring the subdomain.

This flaw enables an attacker to craft a malicious origin that bypasses the intended CORS policy, potentially allowing cross-origin requests from unauthorized domains. The impact is limited to scenarios where the application relies on CORS for security, such as API endpoints that trust specific origins.

Vulnerable vs. Patched Code

Vulnerable Code (before 1.6.0):

func parseWildcardRules(rules []string) []wildcardRule {
    var wrs []wildcardRule
    for _, rule := range rules {
        if strings.HasSuffix(rule, "/*") {
            prefix := strings.TrimSuffix(rule, "/*")
            wrs = append(wrs, wildcardRule{prefix: prefix})
        }
    }
    return wrs
}

Patched Code (1.6.0 and later):

func parseWildcardRules(rules []string) []wildcardRule {
    var wrs []wildcardRule
    for _, rule := range rules {
        if strings.HasSuffix(rule, "/*") {
            prefix := strings.TrimSuffix(rule, "/*")
            // Ensure the prefix ends with a dot or slash to prevent partial domain matches
            if strings.HasSuffix(prefix, ".") || strings.HasSuffix(prefix, "/") {
                wrs = append(wrs, wildcardRule{prefix: prefix})
            }
        }
    }
    return wrs
}

The fix adds a check to ensure the prefix ends with a dot (.) or slash (/), preventing wildcard matches that would allow unintended subdomains or domain suffixes.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Deploy a vulnerable Gin application using Gin-Gonic CORS middleware version 1.5.0.
2. Configure a CORS rule: AllowedOrigins: ["https://example.com/*"].
3. Host the application on a server with a public IP or localhost.

Exploitation Steps:

1. Craft a malicious origin header: Origin: https://example.community.
2. Send a cross-origin request (e.g., an HTTP OPTIONS preflight) to the vulnerable endpoint.
3. Observe that the server responds with Access-Control-Allow-Origin: https://example.community, indicating the bypass.
4. Use this to exfiltrate data or perform actions on behalf of a legitimate user.

Example Request:

OPTIONS /api/sensitive HTTP/1.1
Host: vulnerable-app.com
Origin: https://example.community
Access-Control-Request-Method: GET

Expected Response:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.community
Access-Control-Allow-Methods: GET

Blue Team

Detection:

• Monitor for unexpected Origin headers that do not match the intended CORS policy.
• Look for patterns where the origin contains a domain that is a substring of an allowed domain (e.g., example.community when example.com is allowed).
• Use the detection rules provided below.

Mitigation:

• Immediately upgrade to Gin-Gonic CORS middleware version 1.6.0 or later.
• If upgrade is not possible, implement a custom CORS validation function that strictly checks origins against a whitelist without relying on wildcards.

Indicators of Compromise (IOCs)

• Network Traffic:
  • HTTP requests with Origin headers containing domains that are substrings of allowed origins (e.g., example.community for example.com).
  • Unusual preflight (OPTIONS) requests to sensitive endpoints.
• Logs:
  • Server logs showing Access-Control-Allow-Origin headers with unexpected values.
  • Repeated failed CORS checks from the same IP.
• File System:
  • Presence of Gin-Gonic CORS middleware version < 1.6.0 in Go module dependencies.

Detection Engineering

YARA Rule

rule CVE_2019_25211_Gin_CORS_Wildcard {
    meta:
        description = "Detects vulnerable Gin-Gonic CORS middleware versions"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2019-25211"
    strings:
        $vuln_func = "parseWildcardRules"
        $vuln_pattern = "strings.HasSuffix(rule, \"/*\")"
        $patch_pattern = "strings.HasSuffix(prefix, \".\") || strings.HasSuffix(prefix, \"/\")"
    condition:
        $vuln_func and $vuln_pattern and not $patch_pattern
}

Sigma Rule

title: CVE-2019-25211 Gin-Gonic CORS Wildcard Bypass
id: 8f4b3c2a-1e5d-4f7b-9a0c-3d6e8f2b1a4c
status: experimental
description: Detects HTTP requests exploiting CORS wildcard bypass in Gin-Gonic middleware
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: gin
detection:
    selection:
        http.method: "OPTIONS"
        http.origin|contains: 
            - ".example.com"
            - ".localhost"
    condition: selection
falsepositives:
    - Legitimate subdomain usage
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2019-25211 Gin-Gonic CORS Wildcard Bypass"; flow:to_server; http.method; content:"OPTIONS"; http.origin; content:".example.com"; http.origin; content:!"example.com/"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade the Gin-Gonic CORS middleware to version 1.6.0 or later. Run go get github.com/gin-gonic/contrib/cors@v1.6.0 or update your go.mod file.
2. Workaround: If upgrade is not possible, implement a custom CORS validation function that uses exact string matching instead of wildcards. For example, maintain a whitelist of allowed origins and compare them directly.
3. Monitoring: Enable logging of all CORS-related headers and monitor for suspicious origins. Use the detection rules above to alert on potential exploitation.
4. Network Segmentation: Restrict access to sensitive endpoints using network-level controls (e.g., firewalls) to limit exposure.
5. Regular Audits: Periodically review Go module dependencies for known vulnerabilities using tools like govulncheck or snyk.

Valters IT Signature:
This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.