GHSA-2v5c-755p-p4gv is a high-severity (CVSS 8) CWE-295 vulnerability in faye-websocket. 2 public exploit references exist, so weaponization risk is real. O3 Security confirms whether GHSA-2v5c-755p-p4gv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Missing TLS certificate verification in faye-websocket
Real-World Exposure
faye-websocketReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
The Faye::WebSocket::Client class uses the EM::Connection#start_tls method in EventMachine 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 wss: connection made using this library is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.
This has been a requested feature in EventMachine for many years now; see for example #275, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. Based on this implementation, we have incorporated similar functionality into faye-websocket for Ruby, such that we use the OpenSSL module to perform two checks:
- The chain of certificates presented by the server is valid and ultimately trusted by your root certificate set -- either your system default root certificates, or a set provided at runtime
- The final certificate presented by the server is valid for the hostname used in the request URI; if the connection is made via a proxy we use the hostname from the request, not the proxy's hostname
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-websocket, 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. To that end, we have added two new options to the Faye::WebSocket::Client constructor: tls.root_cert_file, and tls.verify_peer.
The :root_cert_file option lets you provide a different set of root certificates in situations where you don't want to use your system's default root certificates to verify the remote host. It should be a path or an array of paths identifying the certificates to use instead of the defaults.
client = Faye::WebSocket::Client.new('wss://example.com/', [], tls: {
root_cert_file: 'path/to/certificate.pem'
})
The :verify_peer option lets you turn verification off entirely. This should be a last resort and we recommend using the :root_cert_file option if possible.
client = Faye::WebSocket::Client.new('wss://example.com/', [], tls: {
verify_peer: false
})
To get the new behaviour, please upgrade to v0.11.0 of the Rubygems package. There are, unfortunately, no workarounds for this issue, as you cannot enable :verify_peer in EventMachine unless the calling library contains an implementation of ssl_verify_peer that actually checks the server's certificates.
For further background information on this issue, please see faye#524 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | faye-websocket | all versions | 0.11.0 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for faye-websocket. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update faye-websocket to 0.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2v5c-755p-p4gv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2v5c-755p-p4gv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2v5c-755p-p4gv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2v5c-755p-p4gv in your dependencies?
O3 detects GHSA-2v5c-755p-p4gv across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.