Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of its client. Those libraries both use the [EM::Connection#starttls][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…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On 20 April 2020 it was reported to me that the potential for authentication bypass exists in [Faye][1]'s extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today. The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye [extension docs][2] suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example: A bug in the server's code for recognising the special /meta/ channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe: This message will not be checked by the above extension, as it checks the…
Recommended action: Upgrade to 1.2.5, 1.1.3 or 1.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.