https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 02:28:35 +0000 https://cve.radiocsirt.org/vuln/cnvd-2020-44629 cnvd-2020-44629 https://cve.radiocsirt.org/vuln/cnvd-2020-44629 https://cve.radiocsirt.org/vuln/euvd-2026-42670 EUVD-2026-42670 https://cve.radiocsirt.org/vuln/euvd-2026-42670 https://cve.radiocsirt.org/vuln/fkie_cve-2020-15133 <p>In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. 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. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.</p> <p>In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. 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. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2020-15133 https://cve.radiocsirt.org/vuln/ghsa-2v5c-755p-p4gv <p><strong>Affected:</strong> RubyGems: faye-websocket</p> <p>The `Faye::WebSocket::Client` class uses 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 `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.</p> <p>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][6] 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 for Ruby][10], such that we use the `OpenSSL` module to perform two checks:</p> <p>- 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 p…</p> <p><strong>Affected:</strong> RubyGems: faye-websocket</p> <p>The `Faye::WebSocket::Client` class uses 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 `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.</p> <p>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][6] 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 for Ruby][10], such that we use the `OpenSSL` module to perform two checks:</p> <p>- 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 p…</p> https://cve.radiocsirt.org/vuln/ghsa-2v5c-755p-p4gv https://cve.radiocsirt.org/vuln/gsd-2020-15133 gsd-2020-15133 https://cve.radiocsirt.org/vuln/gsd-2020-15133 https://cve.radiocsirt.org/vuln/ubuntu-cve-2020-15133 <p><strong>Affected:</strong> Ubuntu:20.04:LTS: ruby-faye-websocket, Ubuntu:22.04:LTS: ruby-faye-websocket, Ubuntu:24.04:LTS: ruby-faye-websocket, Ubuntu:25.10: ruby-faye-websocket, Ubuntu:26.04:LTS: ruby-faye-websocket</p> <p>In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. 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. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.</p> <p><strong>Affected:</strong> Ubuntu:20.04:LTS: ruby-faye-websocket, Ubuntu:22.04:LTS: ruby-faye-websocket, Ubuntu:24.04:LTS: ruby-faye-websocket, Ubuntu:25.10: ruby-faye-websocket, Ubuntu:26.04:LTS: ruby-faye-websocket</p> <p>In faye-websocket before version 0.11.0, there is a lack of certification validation in TLS handshakes. 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. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2020-15133