ghsa

rpc.py through 0.6.0 allows Remote Code Execution because an unpickle occurs when the "serializer: pickle" HTTP header is sent. In other words, although JSON (not Pickle) is the default data format, an unauthenticated client can cause the data to be processed with unpickle. [Per the maintainer](https://github.com/abersheeran/rpc.py/issues/22), rpc.py is not designed for an API that is open to the outside world, and external requests cannot reach rpc.py in real world use. A [fix](https://github.com/abersheeran/rpc.py/commit/491e7a841ed9a754796d6ab047a9fb16e23bf8bd) exists on the `master` branch. As a workaround, use the following code to turn off pickle in older versions: ``` del SERIALIZER_NAMES[PickleSerializer.name] del SERIALIZER_TYPES[PickleSerializer.content_type]

### Impact If a consensus client sends a malformed consensus request to an orderer it may crash the orderer node. This fix checks for the malformed consensus request and returns an error to the consensus client. ### Patches Fixed in v2.2.7 and v2.4.5. ### Workarounds None, users must upgrade to v2.2.7 or v2.4.5. ### References https://github.com/hyperledger/fabric/releases/tag/v2.2.7 https://github.com/hyperledger/fabric/releases/tag/v2.4.5 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Hyperledger Fabric repository](https://github.com/hyperledger/fabric/issues) ### Credits Thank you to Haosheng Wang of OPPO ZIWU Security Lab for this disclosure.

In Openshift Origin the cookies being set in console have no 'secure', 'HttpOnly' attributes.

In Apache Druid 0.22.1 and earlier, certain specially-crafted links result in unescaped URL parameters being sent back in HTML responses. This makes it possible to execute reflected XSS attacks.

In Apache Druid 0.22.1 and earlier, the server did not set appropriate headers to prevent clickjacking. Druid 0.23.0 and later prevent clickjacking using the Content-Security-Policy header.

In Eclipse Lyo versions 1.0.0 to 4.1.0, a TransformerFactory is initialized with the defaults that do not restrict DTD loading when working with RDF/XML. This allows an attacker to cause an external DTD to be retrieved.

### Description Invalid HTTP/2 requests (for example, invalid URIs) are incorrectly handled by writing a blocking error response directly from the selector thread. If the client manages to exhaust the HTTP/2 flow control window, or TCP congest the connection, the selector thread will be blocked trying to write the error response. If this is repeated for all the selector threads, the server becomes unresponsive, causing the denial of service. ### Impact A malicious client may render the server unresponsive. ### Patches The fix is available in Jetty versions 9.4.47. 10.0.10, 11.0.10. ### Workarounds No workaround available within Jetty itself. One possible workaround is to filter the requests before sending them to Jetty (for example in a proxy) ### For more information If you have any questions or comments about this advisory: * Email us at security@webtide.com.

### Impact `SslConnection` does not release `ByteBuffer`s in case of error code paths. For example, TLS handshakes that require client-auth with clients that send expired certificates will trigger a TLS handshake errors and the `ByteBuffer`s used to process the TLS handshake will be leaked. ### Workarounds Configure explicitly a `RetainableByteBufferPool` with `max[Heap|Direct]Memory` to limit the amount of memory that is leaked. Eventually the pool will be full of "active" entries (the leaked ones) and will provide `ByteBuffer`s that will be GCed normally. _With embedded-jetty_ ``` java int maxBucketSize = 1000; long maxHeapMemory = 128 * 1024L * 1024L; // 128 MB long maxDirectMemory = 128 * 1024L * 1024L; // 128 MB RetainableByteBufferPool rbbp = new ArrayRetainableByteBufferPool(0, -1, -1, maxBucketSize, maxHeapMemory, maxDirectMemory); server.addBean(rbbp); // make sure the ArrayRetainableByteBufferPool is added before the server is started server.start(); ``` _With jetty-home...

### Description URI use within Jetty's `HttpURI` class can parse invalid URIs such as `http://localhost;/path` as having an authority with a host of `localhost;`. A URIs of the type `http://localhost;/path` should be interpreted to be either invalid or as `localhost;` to be the userinfo and no host. However, `HttpURI.host` returns `localhost;` which is definitely wrong. ### Impact This can lead to errors with Jetty's `HttpClient`, and Jetty's `ProxyServlet` / `AsyncProxyServlet` / `AsyncMiddleManServlet` wrongly interpreting an authority with no host as one with a host. ### Patches Patched in PR [#8146](https://github.com/eclipse/jetty.project/pull/8146) for Jetty version 9.4.47. Patched in PR [#8014](https://github.com/eclipse/jetty.project/pull/8015) for Jetty versions 10.0.10, and 11.0.10 ### Workarounds None. ### For more information If you have any questions or comments about this advisory: * Email us at security@webtide.com.

** UNSUPPORTED WHEN ASSIGNED ** Apache Jetspeed-2 does not sufficiently filter untrusted user input by default leading to a number of issues including XSS, CSRF, XXE, and SSRF. Setting the configuration option "xss.filter.post = true" may mitigate these issues. NOTE: Apache Jetspeed is a dormant project of Apache Portals and no updates will be provided for this issue.