Source
ghsa
### Impact When relying on SSO providers in combination with local authentication it can be possible to enumerate existing SSO users in the instance. This is possible because if an email address exists in Directus and belongs to a known SSO provider then it will throw a "helpful" error that the user belongs to another provider. ### Reproduction 1. Create a user using a SSO provider `test@directus.io`. 2. Try to log-in using the regular login form (or the API) 3. When using a valid email address | **APP** | **API** | | --- | --- | |  |  | 4. When using an invalid email address | **APP** | **API** | | --- | --- | |  |  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.
### 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.
### 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...
### Impact A SQL injection vulnerability exists in some types implementing `ILiteralType.ObjectToSQLString`. Callers of these methods are exposed to the vulnerability, which includes: - Mappings using inheritance with discriminator values: - The discriminator value could be written in the mapping in a way exploiting the vulnerability of the associated discriminator type, if that type is among the vulnerable ones. - The current culture settings for formatting the discriminator value type could be altered in a way resulting into SQL injections with the discriminator values. - HQL queries referencing a static field of the application. - Users of the `SqlInsertBuilder` and `SqlUpdateBuilder` utilities, calling their `AddColumn` overload taking a literal value. These overloads are unused by NHibernate but could be used by users referencing directly these utilities. - Any direct use of the `ObjectToSQLString` methods for building SQL queries on the user side. ### Patches Releases ...
### Impact RailsAdmin list view has the XSS vulnerability, caused by improperly-escaped HTML title attribute. The issue was originally reported in https://github.com/railsadminteam/rails_admin/issues/3686. ### Patches Upgrade to [3.1.3](https://rubygems.org/gems/rails_admin/versions/3.1.3) or [2.3.0](https://rubygems.org/gems/rails_admin/versions/2.3.0). ### Workarounds 1. Copy the index view (located under the path `app/views/rails_admin/main/index.html.erb`) from the RailsAdmin version you use, and place it into your application by using the same path. 2. Open the view file by an editor, and remove `strip_tags` from the title attribute: ```diff <% properties.map{ |property| property.bind(:object, object) }.each do |property| %> <% value = property.pretty_value %> - <td class="<%= [property.sticky? && 'sticky', property.css_class, property.type_css_class].select(&:present?).join(' ') %>" title="<%= strip_tags(value.to_s) %>"> + ...