ghsa

### Impact Administrator users on Harbor could exploit an ORM Leak (https://www.elttam.com/blog/plormbing-your-django-orm/) vulnerability that was present in the `/api/v2.0/users` endpoint to leak users' password hash and salt values. This vulnerability was introduced into the application because the `q` URL parameter allowed the administrator to filter users by any column, and the filter `password=~` could be abused to leak out a user's password hash character by character. An attacker with administrator access could exploit this vulnerability to leak highly sensitive information stored on the Harbor database, as demonstrated in the attached writeup by the leaking of users' password hashes and salts. All endpoints that support the `q` URL parameter are vulnerable to this ORM leak attack, and could potentially be exploitable by lower privileged users to gain unauthorised access to other sensitive information. ### Patches No available ### Workarounds NA ### References ### Credit...

### Summary The regular expression patched to mitigate the ReDoS vulnerability by limiting the length of string fails to catch inputs that exceed this limit. ### Details In version 3.0.1, you can find a commit like the one in the link below, which was made to prevent ReDoS. https://github.com/rennf93/fastapi-guard/commit/d9d50e8130b7b434cdc1b001b8cfd03a06729f7f This commit mitigates the vulnerability by limiting the length of the input string, as shown in the example below. `r"<script[^>]*>[^<]*<\\/script\\s*>"` -> `<script[^>]{0,100}>[^<]{0,1000}<\\/script\\s{0,10}>` This type of patch fails to catch cases where the string representing the attributes of a <script> tag exceeds 100 characters. Therefore, most of the regex patterns present in version 3.0.1 can be bypassed. ### PoC 1. clone the fastapi-guard repository 2. Navigate to the examples directory and modify the main.py source code. Change the HTTP method for the root route from GET to POST. <img width="1013" height="554" ...

### Impact In the Harbor repository information, it is possible to inject code resulting in a stored XSS issue. ### Patches Harbor v2.12.3 Harbor 2.11.3 ### Workarounds No ### References ### Credit gleb.razvitie@gmail.com

All versions of the package files-bucket-server are vulnerable to Directory Traversal where an attacker can traverse the file system and access files outside of the intended directory.

All versions of the package bun are vulnerable to Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in the $ shell API due to improper neutralization of user input. An attacker can exploit this by providing specially crafted input that includes command-line arguments or shell metacharacters, leading to unintended command execution.

All versions of the package private-ip are vulnerable to Server-Side Request Forgery (SSRF) where an attacker can provide an IP or hostname that resolves to a multicast IP address (224.0.0.0/4) which is not included as part of the private IP ranges in the package's source code.

Cross-Domain Token Exposure in server.auth.getAuthorizationToken in Ollama 0.6.7 allows remote attackers to steal authentication tokens and bypass access controls via a malicious realm value in a WWW-Authenticate header returned by the /api/pull endpoint.

Cross-site Scripting (XSS) in aimhubio Aim 3.28.0 allows remote attackers to execute arbitrary JavaScript in victims browsers via malicious Python code submitted to the /api/reports endpoint, which is interpreted and executed by Pyodide when the report is viewed. No sanitisation or sandbox restrictions prevent JavaScript execution via pyodide.code.run_js().

Local File Inclusion in dagster._grpc.impl.get_notebook_data in Dagster 1.10.14 allows attackers with access to the gRPC server to read arbitrary files by supplying path traversal sequences in the notebook_path field of ExternalNotebookData requests, bypassing the intended extension-based check.

### Summary Deactivated users that had either enrolled via OAuth/SAML or had their account connected to an OAuth/SAML account can still partially access authentik even if their account is deactivated. They end up in a half-authenticated state where they cannot access the API but crucially they can authorize applications if they know the URL of the application. ### Patches authentik 2025.4.4 and 2025.6.4 fix this issue. ### Workarounds Adding an expression policy to the user login stage on the respective authentication flow with the expression of ```py return request.context["pending_user"].is_active ``` This expression will only activate the user login stage when the user is active. ### For more information If you have any questions or comments about this advisory: - Email us at [security@goauthentik.io](mailto:security@goauthentik.io).