ghsa

Apache Superset contains an improper access control vulnerability in its /explore endpoint. A missing authorization check allows an authenticated user to discover metadata about datasources they do not have permission to access. By iterating through the datasource_id in the URL, an attacker can enumerate and confirm the existence and names of protected datasources, leading to sensitive information disclosure. This issue affects Apache Superset: before 5.0.0. Users are recommended to upgrade to version 5.0.0, which fixes the issue.

A stored Cross-Site Scripting (XSS) vulnerability exists in Apache Superset's chart visualization. An authenticated user with permissions to edit charts can inject a malicious payload into a column's label. The payload is not properly sanitized and gets executed in the victim's browser when they hover over the chart, potentially leading to session hijacking or the execution of arbitrary commands on behalf of the user. This issue affects Apache Superset: before 5.0.0. Users are recommended to upgrade to version 5.0.0, which fixes the issue.

When a guest user accesses a chart in Apache Superset, the API response from the /chart/data endpoint includes a query field in its payload. This field contains the underlying query, which improperly discloses database schema information, such as table names, to the low-privileged guest user. This issue affects Apache Superset: before 4.1.3. Users are recommended to upgrade to version 4.1.3, which fixes the issue.

A bypass of the DISALLOWED_SQL_FUNCTIONS security feature in Apache Superset allows for the execution of blocked SQL functions. An attacker can use a special inline block to circumvent the denylist. This allows a user with SQL Lab access to execute functions that were intended to be disabled, leading to the disclosure of sensitive database information like the software version. This issue affects Apache Superset: before 5.0.0. Users are recommended to upgrade to version 5.0.0, which fixes the issue.

The Custom MCPs feature is designed to execute OS commands, for instance, using tools like `npx` to spin up local MCP Servers. However, Flowise's inherent authentication and authorization model is minimal and lacks role-based access controls (RBAC). Furthermore, in Flowise versions before 3.0.1 the default installation operates without authentication unless explicitly configured. This combination allows unauthenticated network attackers to execute unsandboxed OS commands.

User-controlled input flows to an unsafe implementation of a dynamic Function constructor, allowing network attackers to run arbitrary unsandboxed JS code in the context of the host, by sending a simple POST request.

Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default. The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters. This has been assigned the CVE identifier CVE-2025-24293. Versions Affected: >= 5.2.0 Not affected: < 5.2.0 Fixed Versions: 7.1.5.2, 7.2.2.2, 8.0.2.1 Impact ------ This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor. Vulnerable code will look something similar to this: ``` <%= image_tag blob.variant(params[:t] => params[:v]) %> ``` Where the transformation method or its arguments are untrusted arbitrary input. All users running an affected release should either upgrade or use one of the wo...

A Helm contributor discovered an improper validation of type error when parsing Chart.yaml and index.yaml files that can lead to a panic. ### Impact There are two areas of YAML validation that were impacted. First, when a `Chart.yaml` file had a `null` maintainer or the `child` or `parent` of a dependencies `import-values` could be parsed as something other than a string, `helm lint` would panic. Second, when an `index.yaml` had an empty entry in the list of chart versions Helm would panic on interactions with that repository. ### Patches This issue has been resolved in Helm v3.18.5. ### Workarounds Ensure YAML files are formatted as Helm expects prior to processing them with Helm. ### References Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense.

A Helm contributor discovered that it was possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination. ### Impact A malicious chart can point `$ref` in _values.schema.json_ to a device (e.g. `/dev/*`) or other problem file which could cause Helm to use all available memory and have an out of memory (OOM) termination. ### Patches This issue has been resolved in Helm v3.18.5. ### Workarounds Make sure that all Helm charts that are being loaded into Helm doesn't have any reference of `$ref` pointing to `/dev/zero`. ### References Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense.

The HTTP/2 [MadeYouReset vulnerability](https://galbarnahum.com/made-you-reset) has a mild effect on swift-nio-http2. swift-nio-http2 mostly protects against MadeYouReset by using a number of existing denial-of-service prevention patterns that we added in response to the RapidReset vulnerabilities. The result is that servers are not vulnerable to naive attacks based on MadeYouReset, and the naive PoC examples do not affect swift-nio-http2. However, in 1.38.0 we added some defense-in-depth measures as a precautionary measure that detect clients behaving "weirdly". These defense in depth measures tackle resource drain attacks where attackers interleave attack traffic with legitimate traffic to try to evade our existing DoS prevention mechanisms. We recommend all adopters move to 1.38.0 as soon as possible to mitigate against more sophisticated attacks that may appear in the future. We are very grateful to @galbarnahum, @AnatBB, and @YanivRL for their reporting and assistance with our...