ghsa

An issue discovered in esptool 4.6.2 allows attackers to view sensitive information via weak cryptographic algorithm.

### Summary An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack. ### Details The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it. A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2). ### PoC <details> <summary>AsyncSSH Client 2.14.0 (simple_client.py example) connecting to Asyn...

### Impact This advisory addresses an issue when a DynamoDB Set attribute is marked as SIGN_ONLY in the AWS Database Encryption SDK (DB-ESDK) for DynamoDB. This also includes when a Set is part of a List or a Map. DB-ESDK for DynamoDB supports `SIGN_ONLY` and `ENCRYPT_AND_SIGN` attribute actions. In version 3.1.0 and below, when a Set type is assigned a `SIGN_ONLY` attribute action, there is a chance that signature validation of the record containing a Set will fail on read, even if the Set attributes contain the same values. The probability of a failure depends on the order of the elements in the Set combined with how DynamoDB returns this data, which is undefined. This update addresses the issue by ensuring that any Set values are canonicalized in the same order while written to DynamoDB as when read back from DynamoDB. ### Patches Fixed in version 3.1.1 We recommend all users upgrade as soon as possible. ### Workarounds None ### References For more information on how to addres...

### Impact An ajax function in module blockreassurance allows modifying any value in the configuration table ### Patches v5.1.4 ### Workarounds no workaround available ### References

# Introduction This write-up describes a vulnerability found in [Label Studio](https://github.com/HumanSignal/label-studio), a popular open source data labeling tool. The vulnerability was found to affect versions before `1.8.2`, where a patch was introduced. # Overview In [Label Studio version 1.8.1](https://github.com/HumanSignal/label-studio/tree/1.8.1), a hard coded Django `SECRET_KEY` was set in the application settings. The Django `SECRET_KEY` is used for signing session tokens by the web application framework, and should never be shared with unauthorised parties. However, the Django framework inserts a `_auth_user_hash` claim in the session token that is a HMAC hash of the account's password hash. That claim would normally prevent forging a valid Django session token without knowing the password hash of the account. However, any authenticated user can exploit an Object Relational Mapper (ORM) Leak vulnerability in Label Studio to leak the password hash of any account on the ...

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.