ghsa

The PersistedUsernamePasswordProvider was prone to a information disclosure of account existance based on timing attacks as the hashing of passwords was only done in case an account was found. We changed the core so that the provider always does a password comparison in case credentials were submitted at all.

Due to reports it has been validated that internal workspaces in Neos are accessible without authentication. Some users assumed this is a planned feature but it is not. A workspace preview should be an additional feature with respective security measures in place. Note that this only allows reading of internal workspaces not writing. And for clarification, an internal workspace is a workspace that is non public and doesn't have an owner. Given that an internal workspace exists in your installation, it is possible to view a page in context of that workspace by opening a link in this format: https://domain/path/to/page.html@workspace-name The issue is quite problematic when exploited but at the same time slightly less impactful than it sounds. First of all there is no default internal workspace, so the issue affects only workspaces created by users. That also means the workspace-name, which will also always include a hash is individual to a project and an exploiter must get hold of t...

If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them. ### Am I affected? - Do you use Entity Security? if no, you are not affected. - You disabled the Doctrine Cache (Flow_Persistence_Doctrine)? If this is the case, you are not affected. - You use Entity Security in custom Flow or Neos applications. Read on. - If you only used Entity Security based on roles (i.e. role A was allowed to see entities, but role B was denied): In this case, you are not affected. - If you did more advanced stuff using Entity Security (like checking that a customer only sees his own orders; or a hotel only sees its own bookings), you very likely needed ...

It has been discovered that Flow 3.0.0 allows arbitrary file uploads, inlcuding server-side scripts, posing the risk of attacks. If those scripts are executed by the server when accessed through their public URL, anything not blocked through other means is possible (information disclosure, placement of backdoors, data removal, …). Note: The upload of files is only possible if the application built on Flow provides means to do so, and whether or not the upload of files poses a risk is dependent on the system setup. If uploaded script files are not executed by the server, there is no risk. In versions prior to 3.0.0 the upload of files with the extension php was blocked. In Flow 2.3.0 to 2.3.6 a potential XML External Entity processing vulnerability has been discovered in the MediaTypeConverter.

Due to a missing signature (HMAC) for a request argument, an attacker could unserialize arbitrary objects within FLOW3. To our knowledge it is neither possible to inject code through this vulnerability, nor are there exploitable objects within the FLOW3 Base Distribution. However, there might be exploitable objects within user applications.

Several widely-used JSON Web Token (JWT) libraries, including node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, and jsjwt, are affected by critical vulnerabilities that could allow attackers to bypass the verification step when using asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512).

namshi/jose allows the acceptance of unsecure JSON Web Signatures (JWS) by default. The vulnerability arises from the $allowUnsecure flag, which, when set to true during the loading of JWSes, permits tokens signed with 'none' algorithms to be processed. This behavior poses a significant security risk as it could allow an attacker to impersonate users by crafting a valid jwt token.

A flaw was found in the Submariner project. Due to unnecessary role-based access control permissions, a privileged attacker can run a malicious container on a node that may allow them to steal service account tokens and further compromise other nodes and potentially the entire cluster.

## ID: NFLX-2024-002 ### Impact Authenticated users can achieve limited RCE in ConsoleMe, restricted to flag inputs on a single CLI command. Due to this constraint, it is not currently known whether full RCE is possible but it is unlikely. However, a specific flag allows authenticated users to read any server files accessible by the ConsoleMe process. Given ConsoleMe's role as an AWS identity broker, accessing files containing secrets on the server could potentially be exploited for privilege escalation. Deployments of ConsoleMe that allow templated resources are impacted and urged to patch immediately. Deployments that do not permit templated resources are not affected. To determine if your ConsoleMe deployment uses templated resources, check the configuration value for `cache_resource_templates.repositories`. If this value does not exist or is an empty array, your deployment is not impacted. ### Description The self-service flow for templated resources in ConsoleMe accepts a user...

The Minder REST ingester is vulnerable to a denial of service attack via an attacker-controlled REST endpoint that can crash the Minder server. The REST ingester allows users to interact with REST endpoints to fetch data for rule evaluation. When fetching data with the REST ingester, Minder sends a request to an endpoint and will use the data from the body of the response as the data to evaluate against a certain rule. Minder sends the request on these lines: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L131-L139 … and parses the response body on these lines: https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L147-L150 https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/engine/ingester/rest/rest.go#L196-L220 Minder creates the URL of the endpoint via templating on these lines: https://github.com/stacklo...