Vulnerability-Lookup

GHSA-QFGR-CRR9-7R49

Vulnerability from github – Published: 2026-04-02 20:31 – Updated: 2026-05-13 16:17

Summary

Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing

Details

Summary

Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value.

In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value.

Details

Rack::Utils.forwarded_values processes the header using logic equivalent to:

forwarded_header.split(';').each_with_object({}) do |field, values|
  field.split(',').each do |pair|
    pair = pair.split('=').map(&:strip).join('=')
    return nil unless pair =~ /\A(by|for|host|proto)="?([^"]+)"?\Z/i
    (values[$1.downcase.to_sym] ||= []) << $2
  end
end

The method splits on ; before it parses individual name=value pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.

As a result, a header value such as:

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

is not treated as a single for value. Instead, Rack may interpret it as if the client had supplied separate for, host, and proto directives.

This creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.

Impact

Applications that rely on Forwarded to derive request metadata may observe attacker-controlled values for host, proto, for, or related URL components.

In affected deployments, this can lead to host or scheme spoofing in derived values such as req.host, req.scheme, req.base_url, or req.url. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.

The practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted Forwarded parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same Forwarded header differently.

Mitigation

Update to a patched version of Rack that parses Forwarded quoted-string values before splitting on parameter delimiters.
Avoid trusting client-supplied Forwarded headers unless they are normalized or regenerated by a trusted reverse proxy.
Prefer stripping inbound Forwarded headers at the edge and reconstructing them from trusted proxy metadata.
Avoid using req.host, req.scheme, req.base_url, or req.url for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.

Severity

4.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0.beta1"
            },
            {
              "fixed": "3.1.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rack"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.2.0"
            },
            {
              "fixed": "3.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32762"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T20:31:52Z",
    "nvd_published_at": "2026-04-02T18:16:27Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`Rack::Utils.forwarded_values` parses the RFC 7239 `Forwarded` header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\ncan be interpreted by Rack as multiple `Forwarded` directives rather than as a single quoted `for` value.\n\nIn deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted `Forwarded` values differently, this discrepancy can allow an attacker to smuggle `host`, `proto`, `for`, or `by` parameters through a single header value.\n\n## Details\n\n`Rack::Utils.forwarded_values` processes the header using logic equivalent to:\n\n```ruby\nforwarded_header.split(\u0027;\u0027).each_with_object({}) do |field, values|\n  field.split(\u0027,\u0027).each do |pair|\n    pair = pair.split(\u0027=\u0027).map(\u0026:strip).join(\u0027=\u0027)\n    return nil unless pair =~ /\\A(by|for|host|proto)=\"?([^\"]+)\"?\\Z/i\n    (values[$1.downcase.to_sym] ||= []) \u003c\u003c $2\n  end\nend\n```\n\nThe method splits on `;` before it parses individual `name=value` pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.\n\nAs a result, a header value such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\nis not treated as a single `for` value. Instead, Rack may interpret it as if the client had supplied separate `for`, `host`, and `proto` directives.\n\nThis creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.\n\n## Impact\n\nApplications that rely on `Forwarded` to derive request metadata may observe attacker-controlled values for `host`, `proto`, `for`, or related URL components.\n\nIn affected deployments, this can lead to host or scheme spoofing in derived values such as `req.host`, `req.scheme`, `req.base_url`, or `req.url`. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.\n\nThe practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted `Forwarded` parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same `Forwarded` header differently.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses `Forwarded` quoted-string values before splitting on parameter delimiters.\n* Avoid trusting client-supplied `Forwarded` headers unless they are normalized or regenerated by a trusted reverse proxy.\n* Prefer stripping inbound `Forwarded` headers at the edge and reconstructing them from trusted proxy metadata.\n* Avoid using `req.host`, `req.scheme`, `req.base_url`, or `req.url` for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.",
  "id": "GHSA-qfgr-crr9-7r49",
  "modified": "2026-05-13T16:17:51Z",
  "published": "2026-04-02T20:31:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32762"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-32762.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing"
}

BREW-TRAVIS-CVE-2026-32762 (GHSA-QFGR-CRR9-7R49)

Vulnerability from osv_homebrew – Published: 2026-08-13 17:44 – Updated: 2026-10-07 23:46 – Source website

Summary

Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing

Details

Summary

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value.

Details

Rack::Utils.forwarded_values processes the header using logic equivalent to:

forwarded_header.split(';').each_with_object({}) do |field, values|
  field.split(',').each do |pair|
    pair = pair.split('=').map(&:strip).join('=')
    return nil unless pair =~ /\A(by|for|host|proto)="?([^"]+)"?\Z/i
    (values[$1.downcase.to_sym] ||= []) << $2
  end
end

As a result, a header value such as:

Forwarded: for="127.0.0.1;host=evil.com;proto=https"

is not treated as a single for value. Instead, Rack may interpret it as if the client had supplied separate for, host, and proto directives.

This creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.

Impact

Applications that rely on Forwarded to derive request metadata may observe attacker-controlled values for host, proto, for, or related URL components.

Mitigation

Update to a patched version of Rack that parses Forwarded quoted-string values before splitting on parameter delimiters.
Avoid trusting client-supplied Forwarded headers unless they are normalized or regenerated by a trusted reverse proxy.
Prefer stripping inbound Forwarded headers at the edge and reconstructing them from trusted proxy metadata.
Avoid using req.host, req.scheme, req.base_url, or req.url for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/rack/rack/security/advisories/…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-32762	ADVISORY
	https://github.com/rack/rack	PACKAGE
	https://github.com/rubysec/ruby-advisory-db/blob/…	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "rack",
        "resource_purl": "pkg:gem/rack@3.0.11",
        "upstream_fixed_in": "3.1.21"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "travis",
        "purl": "pkg:brew/travis"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "RubyGems",
        "key": "pkg:gem/rack@3.0.11",
        "name": "rack",
        "resource": "rack",
        "strategy": "registry",
        "subject_version": "3.0.11"
      }
    ]
  },
  "details": "## Summary\n\n`Rack::Utils.forwarded_values` parses the RFC 7239 `Forwarded` header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\ncan be interpreted by Rack as multiple `Forwarded` directives rather than as a single quoted `for` value.\n\nIn deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted `Forwarded` values differently, this discrepancy can allow an attacker to smuggle `host`, `proto`, `for`, or `by` parameters through a single header value.\n\n## Details\n\n`Rack::Utils.forwarded_values` processes the header using logic equivalent to:\n\n```ruby\nforwarded_header.split(\u0027;\u0027).each_with_object({}) do |field, values|\n  field.split(\u0027,\u0027).each do |pair|\n    pair = pair.split(\u0027=\u0027).map(\u0026:strip).join(\u0027=\u0027)\n    return nil unless pair =~ /\\A(by|for|host|proto)=\"?([^\"]+)\"?\\Z/i\n    (values[$1.downcase.to_sym] ||= []) \u003c\u003c $2\n  end\nend\n```\n\nThe method splits on `;` before it parses individual `name=value` pairs. This is inconsistent with RFC 7239, which permits quoted-string values, and quoted strings may contain semicolons as literal content.\n\nAs a result, a header value such as:\n\n```http\nForwarded: for=\"127.0.0.1;host=evil.com;proto=https\"\n```\n\nis not treated as a single `for` value. Instead, Rack may interpret it as if the client had supplied separate `for`, `host`, and `proto` directives.\n\nThis creates an interpretation conflict when another component in front of Rack treats the quoted value as valid literal content, while Rack reparses it as multiple forwarding parameters.\n\n## Impact\n\nApplications that rely on `Forwarded` to derive request metadata may observe attacker-controlled values for `host`, `proto`, `for`, or related URL components.\n\nIn affected deployments, this can lead to host or scheme spoofing in derived values such as `req.host`, `req.scheme`, `req.base_url`, or `req.url`. Applications that use those values for password reset links, redirects, absolute URL generation, logging, IP-based decisions, or backend requests may be vulnerable to downstream security impact.\n\nThe practical security impact depends on deployment architecture. If clients can already supply arbitrary trusted `Forwarded` parameters directly, this bug may not add meaningful attacker capability. The issue is most relevant where an upstream component and Rack interpret the same `Forwarded` header differently.\n\n## Mitigation\n\n* Update to a patched version of Rack that parses `Forwarded` quoted-string values before splitting on parameter delimiters.\n* Avoid trusting client-supplied `Forwarded` headers unless they are normalized or regenerated by a trusted reverse proxy.\n* Prefer stripping inbound `Forwarded` headers at the edge and reconstructing them from trusted proxy metadata.\n* Avoid using `req.host`, `req.scheme`, `req.base_url`, or `req.url` for security-sensitive operations unless the forwarding chain is explicitly trusted and validated.",
  "id": "BREW-travis-CVE-2026-32762",
  "modified": "2026-10-07T23:46:17Z",
  "published": "2026-08-13T17:44:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32762"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rack/rack"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-32762.yml"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing",
  "upstream": [
    "GHSA-qfgr-crr9-7r49",
    "CVE-2026-32762"
  ]
}

CVE-2026-32762 (GCVE-0-2026-32762)

Vulnerability from cvelistv5 – Published: 2026-04-02 17:06 – Updated: 2026-04-02 17:42

Title

Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing

Summary

Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21 and 3.2.0 to before 3.2.6, Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value. In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value. This issue has been patched in versions 3.1.21 and 3.2.6.

Severity

4.8 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-04-02 17:42 UTC

CWE

CWE-436 - Interpretation Conflict

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7763 records in the last 180 days details

References

1 reference

URL	Tags
https://github.com/rack/rack/security/advisories/…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
rack	rack	Affected: >= 3.0.0.beta1, < 3.1.21 Affected: >= 3.2.0, < 3.2.6

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-32762",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-02T17:42:32.117443Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-04-02T17:42:42.305Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "rack",
          "vendor": "rack",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.0.0.beta1, \u003c 3.1.21"
            },
            {
              "status": "affected",
              "version": "\u003e= 3.2.0, \u003c 3.2.6"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21 and 3.2.0 to before 3.2.6, Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value. In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value. This issue has been patched in versions 3.1.21 and 3.2.6."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-436",
              "description": "CWE-436: Interpretation Conflict",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-02T17:06:50.819Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/rack/rack/security/advisories/GHSA-qfgr-crr9-7r49"
        }
      ],
      "source": {
        "advisory": "GHSA-qfgr-crr9-7r49",
        "discovery": "UNKNOWN"
      },
      "title": "Rack: Forwarded Header semicolon injection enables Host and Scheme spoofing"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-32762",
    "datePublished": "2026-04-02T17:06:50.819Z",
    "dateReserved": "2026-03-13T18:53:03.533Z",
    "dateUpdated": "2026-04-02T17:42:42.305Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-QFGR-CRR9-7R49

Summary

Details

Impact

Mitigation

BREW-TRAVIS-CVE-2026-32762 (GHSA-QFGR-CRR9-7R49)

Summary

Details

Impact

Mitigation

CVE-2026-32762 (GCVE-0-2026-32762)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour