Loading...
Skip to main content

CVE-2020-15134 — Vulnerability in faye — CVE Details

HIGH

Missing TLS certificate verification

Published July 31, 2020Updated July 8, 2026Source: osv

Summary

Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of its client. Those libraries both use the [`EM::Connection#start_tls`][1] method in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This has been a requested feature in EventMachine for many years now; see for example [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request published an [advisory][7] related to this problem and fixed it by [implementing TLS verification][8] in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for the caller to implement it, called [`ssl_verify_peer`][9]. Based on this implementation, we have incorporated similar functionality into faye-websocket. After implementing verification in v1.1.6, em-http-request has elected to leave the `:verify_peer` option switched off by default. We have decided to _enable_ this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either: - talking to the expected server, and will not break under this change - being attacked, and would benefit from being alerted to this fact - deliberately talking to a server that would be rejected by verification The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead. We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it: ```rb client = Faye::Client.new('https://example.com/', tls: { verify_peer: false }) ``` Unfortunately we can't offer an equivalent of the `:root_cert_file` option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set. The same functionality is now supported in the Node.js version, with a `tls` option whose values will be passed to the `https` and `tls` modules as appropriate when making connections. For example, you can provide your own CA certificate: ```js var client = new faye.Client('https://example.com/', { tls: { ca: fs.readFileSync('path/to/certificate.pem') } }); ``` For further background information on this issue, please see [faye#524][12] and [faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel Morsing][15] for providing invaluable assistance and feedback on this issue. [1]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls [2]: https://rubygems.org/gems/eventmachine [3]: https://github.com/eventmachine/eventmachine/issues/275 [4]: https://github.com/eventmachine/eventmachine/pull/378 [5]: https://github.com/eventmachine/eventmachine/issues/814 [6]: https://rubygems.org/gems/em-http-request [7]: https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request [8]: https://github.com/igrigorik/em-http-request/pull/340 [9]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer [10]: https://rubygems.org/gems/faye-websocket [11]: https://faye.jcoglan.com/ [12]: https://github.com/faye/faye/issues/524 [13]: https://github.com/faye/faye-websocket-ruby/pull/129 [14]: https://github.com/SpComb [15]: https://github.com/DanielMorsing

Advisory Timeline

  • First published July 31, 2020 (2264 days ago).
  • Last revised July 8, 2026 — 2168 days after initial publication.

Remediation

Upgrade to the fixed version using your package manager.

Bundler
Update faye to 1.4.0 or later
gem install faye -v 1.4.0

After upgrading, run your dependency scanner again to confirm the vulnerability is resolved.

Affected Packages (1)

Affects 1 ecosystem: rubygems (1).

PackageEcosystemAffectedFixed In
faye
rubygems
0.1.0, 0.1.1, 0.2.2, 0.3.0 (+47 more)1.4.0

Vulnerability Classification

Common Weakness Enumeration (CWE) identifiers for this vulnerability type.

  • CWE-295
    Improper Certificate ValidationMITRE

CVSS Score Breakdown

What the CVSS (Common Vulnerability Scoring System) 8.0 score means for each attack dimension.

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
Required
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

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

Frequently Asked Questions

What is CVE-2020-15134?
Missing TLS certificate verification This vulnerability has been assigned a severity rating of HIGH (CVSS score: 8.0/10).
How do I check if my project is affected by CVE-2020-15134?
CVE-2020-15134 affects faye. Use GeekWala's free vulnerability scanner to check your dependencies against CVE-2020-15134 and 200,000+ other known vulnerabilities.

Severity & Exploitability

CVSS Score
8.0

High exploitability or significant impact. Prioritize remediation within days.

Also Known As

GHSA-3q49-h8f9-9fr9

Related CVEs

Check if you're affected

Scan your dependencies to see if this vulnerability affects your projects.

Scan Your Dependencies