Source
ghsa
## Security Advisory: Open Redirect in Directus SAML Authentication ### Summary An open redirect vulnerability exists in the Directus SAML authentication callback endpoint. The `RelayState` parameter is used in redirects without proper validation against an allowlist of permitted domains. ### Vulnerability Description During SAML authentication, the `RelayState` parameter is intended to preserve the user's original destination. However, while the login initiation flow validates redirect targets against allowed domains, this validation is not applied to the callback endpoint. This allows an attacker to craft a malicious authentication request that redirects users to an arbitrary external URL upon completion. The vulnerability is present in both the success and error handling paths of the callback. ### Impact - **Phishing**: Users can be redirected to attacker-controlled sites that mimic legitimate login pages - **Credential theft**: Chained attacks may leverage the redirect to ca...
When creating a RSA private key from its components, the construction panics, instead of returning an error, when one of the primes is `1`. Discovered by Christian Reitter from [Radically Open Security](https://www.radicallyopensecurity.com/) during a security review for [Proton AG](https://proton.me/).
**Affected Product:** Parsl (Python Parallel Scripting Library) **Component:** parsl.monitoring.visualization **Vulnerability Type:** SQL Injection (CWE-89) **Severity:** High (CVSS Rating Recommended: 7.5 - 8.6) **URL:** [https://github.com/Parsl/parsl/blob/master/parsl/monitoring/visualization/views.py]( https://github.com/Parsl/parsl/blob/master/parsl/monitoring/visualization/views.py) **Summary** A SQL Injection vulnerability exists in the parsl-visualize component of the Parsl library. The application constructs SQL queries using unsafe string formatting (Python % operator) with user-supplied input (workflow_id) directly from URL routes. This allows an unauthenticated attacker with access to the visualization dashboard to inject arbitrary SQL commands, potentially leading to data exfiltration or denial of service against the monitoring database. **Root Cause Analysis** The vulnerability is located in parsl/monitoring/visualization/views.py. Multiple route handlers take the...
### Summary If a cluster has a `Kyverno` policy in enforce mode and there are two exceptions, this allows the policy to be bypassed, even if the first exception is more restrictive than the second. ### Details The following policy was applied: ```yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: disallow-host-path annotations: policies.kyverno.io/title: Disallow hostPath policies.kyverno.io/category: Pod Security Standards (Baseline) policies.kyverno.io/severity: medium policies.kyverno.io/subject: Pod,Volume kyverno.io/kyverno-version: 1.6.0 kyverno.io/kubernetes-version: "1.22-1.23" policies.kyverno.io/description: >- HostPath volumes let Pods use host directories and volumes in containers. Using host resources can be used to access shared data or escalate privileges and should not be allowed. This policy ensures no hostPath volumes are in use. spec: validationFailureAction: Enforce background: true rules: ...
This vulnerability allows for **Cross-Site WebSocket Hijacking (CSWSH)** of a deployed Bokeh server instance. ### Scope This vulnerability is only relevant to deployed Bokeh server instances. There is no impact on static HTML output, standalone embedded plots, or Jupyter notebook usage. This vulnerability does not prevent any requirements for up-front authentication on Bokeh servers that have authentication hooks in place, and cannot be used to make Bokeh servers deployed on private, internal networks accessible outside those networks. ### Impact If a Bokeh server is configured with an allowlist (e.g., `dashboard.corp`), an attacker can register a domain like `dashboard.corp.attacker.com` (or use a subdomain if applicable) and lure a victim to visit it. The malicious site can then initiate a WebSocket connection to the vulnerable Bokeh server. Since the Origin header (e.g., `http://dashboard.corp.attacker.com/`) matches the allowlist according to the flawed logic, the connectio...
### Impact n8n is affected by an authenticated Remote Code Execution (RCE) vulnerability. Under certain conditions, an authenticated user may be able to cause untrusted code to be executed by the n8n service. This could result in full compromise of the affected instance. Both self-hosted and n8n Cloud instances are impacted. ### Patches The issue has been resolved in n8n version 1.121.3. Users are advised to upgrade to this version or later to fully address the vulnerability. ### Workarounds If upgrading is not immediately possible, administrators can reduce exposure by disabling the Git node and limiting access for untrusted users. ### References - n8n documentation: [Blocking access to nodes](https://docs.n8n.io/hosting/securing/blocking-nodes/)
## Summary A Server-Side Request Forgery (SSRF) vulnerability exists in Mailpit's `/proxy` endpoint that allows attackers to make requests to internal network resources. ## Description The `/proxy` endpoint allows requests to internal network resources. While it validates `http://` and `https://` schemes, it does not block internal IP addresses, allowing attackers to access internal services and APIs. ## Proof of Concept ### Basic SSRF Request ``` GET /proxy?url=http://127.0.0.1:8025/api/v1/info ``` This returns internal API data including database path and runtime statistics. ## Impact Assessment ### 1. Internal Network Scanning Attacker can probe and discover internal services on the network. ### 2. Information Disclosure Access to internal API data, database paths, and runtime statistics. ### 3. Email Content Access Ability to read all captured emails via internal API endpoints. ### 4. Cloud Metadata Access If deployed in cloud environments (AWS/GCP/Azure), potential ac...
## Summary A **Path Traversal (Zip Slip)** vulnerability exists in MONAI's `_download_from_ngc_private()` function. The function uses `zipfile.ZipFile.extractall()` without path validation, while other similar download functions in the same codebase properly use the existing `safe_extract_member()` function. This appears to be an implementation oversight, as safe extraction is already implemented and used elsewhere in MONAI. **CWE:** CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) --- ## Details ### Vulnerable Code Location **File:** `monai/bundle/scripts.py` **Lines:** 291-292 **Function:** `_download_from_ngc_private()` ```python # monai/bundle/scripts.py - Lines 284-293 zip_path = download_path / f"{filename}_v{version}.zip" with open(zip_path, "wb") as f: f.write(response.content) logger.info(f"Downloading: {zip_path}.") if remove_prefix: filename = _remove_ngc_prefix(filename, prefix=remove_prefix) extract_path = download_path / f"{filename...
### Summary When a user signs into an account with 2FA enabled they are prompted to enter a token. When that token is used, it is not sufficiently marked as used in the system allowing an attacker that intercepts that token to then use it in addition to a known username/password during the token validity window. This vulnerability requires that an attacker already be in possession of a valid username and password combination, and intercept a valid 2FA token (for example, during a screen share). The token must then be provided in addition to the username and password during the limited token validity window. The validity window is ~60 seconds as the Panel allows at most one additional window to the current one, each window being 30 seconds.
### Summary Pterodactyl does not revoke _active_ SFTP connections when a user is removed from a server instance or has their permissions changes with respect to file access over SFTP. This allows a user that was already connected to SFTP to remain connected and access files even after their permissions are revoked. ### Details When a user opens a connection to a server using the Wings SFTP server instance the permissions are checked and returned from the authentication API call made to the Panel. However, credentials are not checked again after the initial handshake. Thus, if a user is removed from a server in the panel or have their permissions modified, those permissions are not updated in the SFTP connection. As a result, a user that has already gained access to a server's files via the SFTP subsystem will maintain those permissions until disconnected (via Wings restart, or a manual disconnection on their end). > [!NOTE] > > This issue impacts the SFTP subsystem for server files ...