ghsa

In scan.rs in spytrap-adb before 0.3.5, matches for known stalkerware are not rendered in the interactive user interface.

### Impact `rfc3161-client` 1.0.2 and earlier contain a flaw in their timestamp response signature verification logic. In particular, it performs chain verification against the TSR's embedded certificates up to the trusted root(s), but fails to verify the TSR's own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce _any_ TSR signature so long as the embedded leaf chains up to some root TSA. ### Patches Users should immediately upgrade to `rfc3161-client` 1.0.3 or later. ### Workarounds There is no workaround possible. Users should immediately upgrade to a fixed version.

Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in risc0-zkvm 2.0.0, 2.0.1, and 2.0.2 are vulnerable to an attack by a malicious prover. The main idea for the attack is to confuse the RISC-V virtual machine into treating the value of the rs1 register as the same as the rs2 register due to a lack of constraints in the rv32im circuit. This vulnerability was reported by Christoph Hochrainer via our Hackenproof bug bounty. The fix for the circuit was implemented in [zirgen/pull/238](https://github.com/risc0/zirgen/pull/238), and the update to risc0 was implemented in [risc0/pull/3181](https://github.com/risc0/risc0/pull/3181). Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). ## Mitigation It is recommend all impacted users u...

A request smuggling vulnerability identified within Pingora’s proxying framework, pingora-proxy, allows malicious HTTP requests to be injected via manipulated request bodies on cache HITs, leading to unauthorized request execution and potential cache poisoning. ### Fixed in https://github.com/cloudflare/pingora/commit/fda3317ec822678564d641e7cf1c9b77ee3759ff ### Impact The issue could lead to request smuggling in cases where Pingora’s proxying framework, pingora-proxy, is used for caching allowing an attacker to manipulate headers and URLs in subsequent requests made on the same HTTP/1.1 connection.

### Summary The RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect. ### Details The RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/v5.2.1/middleware/strip.go#L55 The Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware ### PoC Create a simple server which uses the RedirectSlashes middleware ``` package main import ( "fmt" "net/http" "github.com/go-chi/chi/v5" "github.com/go-chi/chi/v5/middleware" // Import the middleware package ) func main() { // Create a new Chi router r := chi.NewRouter() // Use the built-in RedirectSlashes middleware r.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes // Define a route handler r.Get("/", func(w http.ResponseWriter, r *http.Request) { // A simple response w.Write([]byte("Hello, World!")) }) ...

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly enforce channel member management permissions in playbook runs, allowing authenticated users without the 'Manage Channel Members' permission to add or remove users from public and private channels by manipulating playbook run participants when the run is linked to a channel.

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly retrieve requestorInfo from playbooks handler for guest users which allows an attacker access to the playbook run.

DNN.PLATFORM allows a specially crafted series of malicious interaction can expose NTLM hashes to a third party SMB server. This vulnerability is fixed in 10.0.1.

DNN.PLATFORM allows a specially crafted request or proxy could be created that would bypass the design of DNN Login IP Filters allowing login attempts from IP Adresses not in the allow list. This vulnerability is fixed in 10.0.1.

DNN.PLATFORM allows a specially crafted request can inject scripts in the Activity Feed Attachments endpoint which will then render in the feed, resulting in a cross-site scripting attack. This vulnerability is fixed in 10.0.1.