ghsa

### 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) %>"> + ...

Apache NiFi 1.10.0 through 1.26.0 and 2.0.0-M1 through 2.0.0-M3 support a description field in the Parameter Context configuration that is vulnerable to cross-site scripting. An authenticated user, authorized to configure a Parameter Context, can enter arbitrary JavaScript code, which the client browser will execute within the session context of the authenticated user. Upgrading to Apache NiFi 1.27.0 or 2.0.0-M4 is the recommended mitigation.

EGroupware before 23.1.20240624 mishandles an ORDER BY clause.

A buffer-management vulnerability in OPC Foundation OPCFoundation.NetStandard.Opc.Ua.Core before 1.5.374.54 could allow remote attackers to exhaust memory resources. It is triggered when the system receives an excessive number of messages from a remote source. This could potentially lead to a denial of service (DoS) condition, disrupting the normal operation of the system.