ghsa

An issue in the isSVG() function of Known v1.3.1 allows attackers to execute arbitrary code via a crafted SVG file. The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the `dev` branch of the idno/known repository.

Known v1.3.1 was discovered to allow attackers to perform an account takeover via a host header injection attack. The researcher report indicates that versions 1.3.1 and prior are vulnerable. Version 1.2.2 is the last version tagged on GitHub and in Packagist, and development related to the 1.3.x branch is currently on the `dev` branch of the idno/known repository.

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 [email protected].

### 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...