ghsa

Deserialization of untrusted data in IPC and Parquet readers in PyArrow versions 0.14.0 to 14.0.0 allows arbitrary code execution. An application is vulnerable if it reads Arrow IPC, Feather or Parquet data from untrusted sources (for example user-supplied input files). This vulnerability only affects PyArrow, not other Apache Arrow implementations or bindings. It is recommended that users of PyArrow upgrade to 14.0.1. Similarly, it is recommended that downstream libraries upgrade their dependency requirements to PyArrow 14.0.1 or later. PyPI packages are already available, and we hope that conda-forge packages will be available soon. If it is not possible to upgrade, maintainers provide a separate package `pyarrow-hotfix` that disables the vulnerability on older PyArrow versions. See https://pypi.org/project/pyarrow-hotfix/ for instructions.

Versions of the package chromedriver before 119.0.1 are vulnerable to Command Injection when setting the chromedriver.path to an arbitrary system binary. This could lead to unauthorized access and potentially malicious actions on the host system. **Note:** An attacker must have access to the system running the vulnerable chromedriver library to exploit it. The success of exploitation also depends on the permissions and privileges of the process running chromedriver.

An issue discovered in Axios 0.8.1 through 1.5.1 inadvertently reveals the confidential XSRF-TOKEN stored in cookies by including it in the HTTP header X-XSRF-TOKEN for every request made to any host allowing attackers to view sensitive information.

### Summary `slsa-verifier<=2.4.0` does not correctly verify npm's [publish](https://github.com/npm/attestation/tree/main/specs/publish/v0.1) attestations signature. ### Proof of concept Steps to reproduce: 1. `curl -Sso attestations.json $(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.attestations.url')` 2. `curl -Sso supreme-goggles.tgz "$(npm view @trishankatdatadog/supreme-goggles --json | jq -r '.dist.tarball')"` 3. In `attestations.json`, take the value addressed by the `jq` selector `.attestations[0].bundle.dsseEnvelope.payload`, base64decode it, tamper with it, base64encode that, and replace the original value with that. Save the file as `attestations_tampered.json`. Here is an example command to replace the package name with `@attacker/malicious`: `jq -r ".attestations[0].bundle.dsseEnvelope.payload = \"$(jq -r '.attestations[0].bundle.dsseEnvelope.payload | @base64d' < attestations.json | jq '.subject[0].name = "pkg:npm/%40attacker/malicious"' | b...

Microweber CMS prior to version 2.0.3 is vulnerable to stored Cross Site Scripting (XSS) via the profile picture file upload functionality.

### Impact When adding a block in blockreassurance module, a BO user can modify the http request and give the path of any file in the project instead of an image. When deleting the block from the BO, the file will be deleted. It is possible to make the website completely unavailable by removing index.php for example. ### Patches v5.1.4 ### Workarounds No workaround available ### References

### Impact ZITADEL provides administrators the possibility to define a `Lockout Policy` with a maximum amount of failed password check attempts. On every failed password check, the amount of failed checks is compared against the configured maximum. Exceeding the limit, will lock the user and prevent further authentication. In the affected implementation it was possible for an attacker to start multiple parallel password checks, giving him the possibility to try out more combinations than configured in the `Lockout Policy`. ### Patches 2.x versions are fixed on >= [2.40.5](https://github.com/zitadel/zitadel/releases/tag/v2.40.5) 2.38.x versions are fixed on >= [2.38.3](https://github.com/zitadel/zitadel/releases/tag/v2.38.3) ### Workarounds There is no workaround since a patch is already available. ### References None ### Questions If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Impact The Fides web application allows data subject users to request access to their personal data. If the request is approved by the data controller user operating the Fides web application, the data subject's personal data can then retrieved from connected systems and data stores before being bundled together as a data subject access request package for the data subject to download. Supported data formats for the package include json and csv, but the most commonly used format is a series of HTML files compressed in a ZIP file. Once downloaded and unzipped, the data subject user can browse the HTML files on their local machine. It was identified that there was no validation of input coming from e.g. the connected systems and data stores which is later reflected in the downloaded data. This can result in an HTML injection that can be abused e.g. for phishing attacks or malicious JavaScript code execution, but only in the context of the data subject's browser accessing a HTML pag...

### Impact An issue in s2n-quic could result in unnecessary resource utilization when peers open streams beyond advertised limits. Impacted versions: <= v1.30.0. ### Patches The patch is included in v1.31.0 [1]. ### Workarounds There is no workaround. Applications using s2n-quic should upgrade to the most recent release of s2n-quic. If you have any questions or comments about this advisory, we ask that you contact AWS Security via our vulnerability reporting page [2] or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. [1] https://github.com/aws/s2n-quic/releases/tag/v1.31.0 [2] https://aws.amazon.com/security/vulnerability-reporting

### Summary Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in `pkg/cosign.FetchAttestations`. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests. Alterna...