#git

### Summary A denial of service (DoS) attack by field duplication in GraphQL is a type of attack where an attacker exploits the flexibility of GraphQL to overwhelm a server by requesting the same field multiple times in a single query. This can cause the server to perform redundant computations and consume excessive resources, leading to a denial of service for legitimate users. ### Details Request to the endpoint /graphql are sent when visualizing graphs generated at a dashboard:   By modifying the data sent and duplicating many times the fields a DoS attack is possible. ### PoC The goal is to create a payload that generates a body like this, where the 'max' field is duplicated many times, each with the 'id' field duplicated many times inside it. `{'query': 'query { query_4f4722ea: t...

The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses. The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order.

### Summary Directus >=9.23.0, <=v10.5.3 improperly handles _in, _nin operators. It evaluates empty arrays as valid so expressions like {"role": {"_in": $CURRENT_USER.some_field}} would evaluate to true allowing the request to pass. ### Details This results in Broken Access Control because the rule fails to do what it was intended to do: Pass rule if **field** matches any of the **values**. ref: https://docs.directus.io/reference/filter-rules.html#filter-operators In my example this would translate to "Pass rule if **<collection>.role** matches any of **[]**". Which should fail. This instead passes in Directus <= v10.5.3, >=v9.23.0 ### PoC {"role": {"_in": $CURRENT_USER.some_field}} field validation would pass if $CURRENT_USER.some_field is null. Real scenario: Using https://github.com/u12206050/directus-extension-role-chooser with the specified versions of Directus (I tested on 10.0.0) allows users with access to this feature set their role to whatever role if they don't have any r...

The affected versions make unsafe memory accesses under the assumption that `#[repr(packed)]` has a guaranteed field order. The Rust specification does not guarantee this, and https://github.com/rust-lang/rust/pull/125360 (1.80.0-beta) starts reordering fields of `#[repr(packed)]` structs, leading to illegal memory accesses. The patched versions `0.9.7` and `0.10.4` use `#[repr(C, packed)]`, which guarantees field order.

A previously undocumented advanced persistent threat (APT) group dubbed CloudSorcerer has been observed targeting Russian government entities by leveraging cloud services for command-and-control (C2) and data exfiltration. Cybersecurity firm Kaspersky, which discovered the activity in May 2024, the tradecraft adopted by the threat actor bears similarities with that of CloudWizard, but pointed

### Summary There was already a reported SSRF vulnerability via file import. [https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h](https://github.com/directus/directus/security/advisories/GHSA-j3rg-3rgm-537h) It was fixed by resolving all DNS names and checking if the requested IP is an internal IP address. However it is possible to bypass this security measure and execute a SSRF using redirects. Directus allows redirects when importing file from the URL and does not check the result URL. Thus, it is possible to execute a request to an internal IP, for example to 127.0.0.1. However, it is blind SSRF, because Directus also uses response interception technique to get the information about the connect from the socket directly and it does not show a response if the IP address is internal (nice fix, by the way :) ). But the blindness does not fully mitigate the impact of the vulnerability. The blind SSRF is still exploitable in the real life scenarios, because t...

### Summary An attacker can use the `next` parameter on the login page to redirect a victim to a malicious page, while masking this using a legit-looking `app.khoj.dev` url. For example, `https://app.khoj.dev/login?next=//example.com` will redirect to the https://example.com page. ### Details The problem seems to be in this method: https://github.com/khoj-ai/khoj/blob/2667ef45449eb408ce1d7c393be04845be31e15f/src/khoj/routers/auth.py#L95 ### PoC Open the `https://app.khoj.dev/login?next=//example.com` url in a Gecko-based browser (Firefox). ### Impact The impact is low, and this could only be used in phishing attempts, but it's still a problem nonetheless.

ResidenceCMS versions 2.10.1 and below suffer from a persistent cross site scripting vulnerability.

PMS 2024 version 1.0 suffers from a remote SQL injection vulnerability.

### Impact yt-dlp's DouyuTV and DouyuShow extractors used a `cdn.bootcdn.net` URL as a fallback for fetching a component of the crypto-js JavaScript library. When the Douyu extractor is used, yt-dlp extracts this JavaScript code and attempts to execute it externally using [PhantomJS](https://github.com/ariya/phantomjs). `bootcdn.net` is owned by the bad actor responsible for the [Polyfill JS supply chain attack](https://sansec.io/research/polyfill-supply-chain-attack) that has been ongoing since at least June 2023. While there is no evidence that PhantomJS has been targeted by or is vulnerable to any attacks carried out by the Polyfill JS actor, there is the possibility that malicious JavaScript code may have been downloaded/cached by yt-dlp or executed by PhantomJS. In order for this potential vulnerability to be exploited by any hypothetical attack, all 3 of the following conditions must be met: 1. The user has PhantomJS installed on their system. 2. The user passes a `douyu.com` or...