deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gjgr-7834-rhxr
Package: matrix-synapse (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-306: Missing Authentication for Critical Function
Vulnerable versions: < 1.106
Patched in: 1.106

Summary: Synapse's unauthenticated writes to the media repository allow planting of problematic content

Details:
### Impact

Synapse before version 1.106 allows, by design, unauthenticated remote participants to trigger a download and caching of remote media from a remote homeserver to the local media repository. Such content then also becomes available for download from the local homeserver in an unauthenticated way. The implication is that unauthenticated remote adversaries can use this functionality to plant problematic content into the media repository.

### Patches

Synapse 1.106 introduces a partial mitigation in the form of new endpoints which require authentication for media downloads. The unauthenticated endpoints will be frozen in a future release, closing the attack vector.

### Workarounds

Though extremely limited, server operators can use more strict rate limits based on IP address.

### References

* https://github.com/matrix-org/matrix-spec-proposals/pull/3916

### For more information

If you have any questions or comments about this advisory, please email us at [security at element.io](mailto:security@element.io).
GitHub Security Advisory: GHSA-4mhg-xv73-xq2x
Package: matrix-synapse (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.106
Patched in: 1.106

Summary: Synapse denial of service through media disk space consumption

Details:
### Impact

Synapse versions before 1.106 are vulnerable to a disk fill attack, where an unauthenticated adversary can induce Synapse to download and cache large amounts of remote media. The default rate limit strategy is insufficient to mitigate this. This can lead to a denial of service, ranging from further media uploads/downloads failing to completely unavailability of the Synapse process, depending on how Synapse was deployed.

### Patches

Synapse 1.106 introduces a new "leaky bucket" rate limit on remote media downloads to reduce the amount of data a user can request at a time. This does not fully address the issue, but does limit an unauthenticated user's ability to request large amounts of data to be cached.

### Workarounds

Synapse deployments can currently decrease the maximum file size allowed, as well as increase request rate limits. However, this does not as effectively address the issue as a dedicated rate limit on remote media downloads.

Server operators may also wish to consider putting media on a dedicated disk or volume, reducing the impact of a disk fill condition.

### References

* https://en.wikipedia.org/wiki/Leaky_bucket#As_a_meter

### For more information

If you have any questions or comments about this advisory, please email us at [security at element.io](mailto:security@element.io).
GitHub Security Advisory: GHSA-59g5-xgcq-4qw3
Package: python-multipart (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.0.18
Patched in: 0.0.18

Summary: Denial of service (DoS) via deformation `multipart/form-data` boundary

Details:
### Summary

When parsing form data, `python-multipart` skips line breaks (CR `\r` or LF `\n`) in front of the first boundary and any tailing bytes after the last boundary. This happens one byte at a time and emits a log event each time, which may cause excessive logging for certain inputs.

An attacker could abuse this by sending a malicious request with lots of data before the first or after the last boundary, causing high CPU load and stalling the processing thread for a significant amount of time. In case of ASGI application, this could stall the event loop and prevent other requests from being processed, resulting in a denial of service (DoS).

### Impact

Applications that use `python-multipart` to parse form data (or use frameworks that do so) are affected. 

### Original Report

This security issue was reported by:
- GitHub security advisory in Starlette on October 30 by @Startr4ck
- Email to `python-multipart` maintainer on October 3 by @mnqazi
GitHub Security Advisory: GHSA-x4x5-jx9j-mmv7
Package: pyspider (PIP)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.3.10
Patched in: unpatched

Summary: pyspider Cross-site Scripting vulnerability

Details:
pyspider through 0.3.10 allows /update XSS. NOTE: This vulnerability only affects products that are no longer supported by the maintainer
GitHub Security Advisory: GHSA-p57h-3cmc-xpjq
Package: zhmcclient (PIP)
Severity: MODERATE (CVSS 8.2)
CWE: CWE-312: Cleartext Storage of Sensitive Information
Vulnerable versions: < 1.18.1
Patched in: 1.18.1

Summary: Python package "zhmcclient" stores passwords in clear text in its HMC and API logs

Details:
### Impact

The Python package "zhmcclient" writes password-like properties in clear text into its HMC and API logs in the following cases:

* The 'boot-ftp-password' and 'ssc-master-pw' properties when creating or updating a partition in DPM mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when updating an LPAR in classic mode, in the zhmcclient API and HMC logs
* The 'ssc-master-pw' and 'zaware-master-pw' properties when creating or updating an image activation profile in classic mode, in the zhmcclient API and HMC logs
* The 'password' property when creating or updating an HMC user, in the zhmcclient API log
* The 'bind-password' property when creating or updating an LDAP server definition, in the zhmcclient API and HMC logs

This issue affects only users of the zhmcclient package that have enabled the Python loggers named "zhmcclient.api" (for the API log) or "zhmcclient.hmc" (for the HMC log) and that use the functions listed above.

### Patches

Has been fixed in zhmcclient version 1.18.1

### Workarounds

Not applicable, since fix is available.

### References

None
GitHub Security Advisory: GHSA-75c5-xw7c-p5pm
Package: PyJWT (PIP)
Severity: LOW (CVSS 2.2)
CWE: CWE-697: Incorrect Comparison
Vulnerable versions: = 2.10.0
Patched in: 2.10.1

Summary: PyJWT Issuer field partial matches allowed

Details:
### Summary
The wrong string if check is run for `iss` checking, resulting in `"acb"` being accepted for `"_abc_"`.

### Details
This is a bug introduced in version [2.10.0](https://github.com/jpadilla/pyjwt/commit/1570e708672aa9036bc772476beae8bfa48f4131#diff-6893ad4a1c5a36b8af3028db8c8bc3b[PII_REDACTED]3fc382faf901eaab008e380R366): checking the "iss" claim
changed from `isinstance(issuer, list)` to `isinstance(issuer,
Sequence)`.

```diff
-        if isinstance(issuer, list):
+        if isinstance(issuer, Sequence):
            if payload["iss"] not in issuer:
                raise InvalidIssuerError("Invalid issuer")
        else:
```

Since str is a Sequnce, but not a list, `in` is also used for string
comparison. This results in `if "abc" not in "__abcd__":` being
checked instead of `if "abc" != "__abc__":`.
### PoC
Check out the unit tests added here: https://github.com/jpadilla/pyjwt-ghsa-75c5-xw7c-p5pm
```python
        issuer = "urn:expected"

        payload = {"iss": "urn:"}

        token = jwt.encode(payload, "secret")

        # decode() succeeds, even though `"urn:" != "urn:expected". No exception is raised.
        with pytest.raises(InvalidIssuerError):
            jwt.decode(token, "secret", issuer=issuer, algorithms=["HS256"])
```


### Impact

I would say the real world impact is not that high, seeing as the signature still has to match. We should still fix it.
GitHub Security Advisory: GHSA-q6mv-284r-mp36
Package: check-jsonschema (PIP)
Severity: MODERATE (CVSS 7.1)
CWE: CWE-349: Acceptance of Extraneous Untrusted Data With Trusted Data
Vulnerable versions: < 0.30.0
Patched in: 0.30.0

Summary: check-jsonschema default caching for remote schemas allows for cache confusion

Details:
### Impact

The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. `https://example.org/schema.json` will be stored as `schema.json`. This naming allows for conflicts. If an attacker can get a user to run `check-jsonschema` against a malicious schema URL, e.g., `https://example.evil.org/schema.json`, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema.

Such a cache confusion attack could be used to allow data to pass validation which should have been rejected.

### Patches

A patch is in progress but has not yet been released.

### Workarounds

- Users can use `--no-cache` to disable caching.
- Users can use `--cache-filename` to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.)
- Users can explicitly download the schema before use as a local file, as in `curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json`
GitHub Security Advisory: GHSA-v7vm-rhmg-8j2r
Package: ethyca-fides (PIP)
Severity: LOW (CVSS 5.7)
CWE: CWE-602: Client-Side Enforcement of Server-Side Security
Vulnerable versions: < 2.50.0
Patched in: 2.50.0

Summary: Password Policy Bypass Vulnerability in Fides Webserver User Accept Invite API

Details:
### Summary

The user invite acceptance API endpoint lacks server-side password policy enforcement, allowing users to set arbitrarily weak passwords by bypassing client-side validation. While the UI enforces password complexity requirements, direct API calls can circumvent these checks, enabling the creation of accounts with passwords as short as a single character.

### Details

When an email messaging provider is enabled and a new user account is created in the system, an invite email containing a special link is sent to the new user's email address. This link directs the new user to a page where they can set their initial password. While the user interface implements password complexity checks, these validations are only performed client-side. The underlying `/api/v1/user/accept-invite` API endpoint does not implement the same password policy validations.

### Impact

This vulnerability allows an invited user to set an extremely weak password for their own account during the initial account setup process. Therefore that specific user's account can be compromised easily by an attacker guessing or brute forcing the password.

### Patches

The vulnerability has been patched in Fides version `2.50.0`. Users are advised to upgrade to this version or later to secure their systems against this threat.

### Workarounds

There are no workarounds.

### Severity

This vulnerability has been assigned a severity of LOW.

Using CVSS v3.1 it could be scored as `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N` (5.7 Medium/Moderate), but the likelihood of a user bypassing client-side password complexity rules to set their own password is very low.
GitHub Security Advisory: GHSA-486g-47cc-8wxf
Package: aiocpa (PIP)
Severity: HIGH (CVSS 0.0)
Vulnerable versions: >= 0.1.13, <= 0.1.14
Patched in: unpatched

Summary: aiocpa contains credential harvesting code

Details:
aiocpa is a user-facing library for generating color gradients of text. Version 0.1.13 introduced obfuscated, malicious code targeting Crypto Pay users, forwarding client credentials to a remote Telegram bot. All versions have been removed from PyPI.
GitHub Security Advisory: GHSA-3864-rp2m-2qfj
Package: libre-chat (PIP)
Severity: MODERATE (CVSS 9.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.0.6
Patched in: unpatched

Summary: libre-chat Path Traversal vulnerability

Details:
An issue in the upload_documents method of libre-chat v0.0.6 allows attackers to execute a path traversal via supplying a crafted filename in an uploaded file.
GitHub Security Advisory: GHSA-qpgc-w4mg-6v92
Package: mlflow (PIP)
Severity: HIGH (CVSS 7.0)
CWE: CWE-276: Incorrect Default Permissions
Vulnerable versions: < 2.16.0
Patched in: 2.16.0

Summary: MLflow's excessive directory permissions allow local privilege escalation

Details:
Excessive directory permissions in MLflow leads to local privilege escalation when using spark_udf. This behavior can be exploited by a local attacker to gain elevated permissions by using a ToCToU attack. The issue is only relevant when the spark_udf() MLflow API is called.
GitHub Security Advisory: GHSA-c392-whpc-vfpr
Package: apache-airflow (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: = 2.10.0
Patched in: 2.10.1

Summary: Apache Airflow vulnerable to Improper Encoding or Escaping of Output

Details:
Example DAG: example_inlet_event_extra.py shipped with Apache Airflow version 2.10.0 has a vulnerability that allows an authenticated attacker with only DAG trigger permission to execute arbitrary commands. If you used that example as the base of your DAGs - please review if you have not copied the dangerous example; see  https://github.com/apache/airflow/pull/41873  for more information. We recommend against exposing the example DAGs in your deployment. If you must expose the example DAGs, upgrade Airflow to version 2.10.1 or later.
GitHub Security Advisory: GHSA-gjcc-jvgw-wvwj
Package: starlite (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.51.16
Patched in: unpatched

Summary: Litestar allows unbounded resource consumption (DoS vulnerability) 

Details:
### Summary
Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests.

### Details
The `Request` methods to parse json, msgpack or form-data all read the entire request stream into memory via `await self.body()` without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen.

For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via `multipart/form-data`, a simple size limit would not be practical. The multipart parser currently used by Litestar expects a single byte string as input and does not support incremental parsing via `Request.stream()`. Applications could bypass the Litestar parser and use a [streaming parser](https://pypi.org/project/multipart/) to read from `Request.stream()` instead, but that would not work with extractors and other features of the framework. Switching the parser for a different implementation is currently not possible via public APIs.

### PoC
Start an applications that accesses `Request.json()`, `Request.msgpack()` or `Request.form()` or uses an extractor that relies on those parsers internally, and send a large request with a matching content type. The actual content of the request does not matter. For example: `curl -F "foo=</dev/random" http://127.0.0.1:8000/`) for `multipart/form-data`. Server memory consumption will increase very quickly until memory (and swap) are exhausted.

### Impact
This is a denial of service (DoS) vulnerability affecting all Litestar applications that process json, msgpack or form-data submission requests.
GitHub Security Advisory: GHSA-gjcc-jvgw-wvwj
Package: litestar (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 2.12.1
Patched in: 2.13.0

Summary: Litestar allows unbounded resource consumption (DoS vulnerability) 

Details:
### Summary
Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests.

### Details
The `Request` methods to parse json, msgpack or form-data all read the entire request stream into memory via `await self.body()` without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen.

For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via `multipart/form-data`, a simple size limit would not be practical. The multipart parser currently used by Litestar expects a single byte string as input and does not support incremental parsing via `Request.stream()`. Applications could bypass the Litestar parser and use a [streaming parser](https://pypi.org/project/multipart/) to read from `Request.stream()` instead, but that would not work with extractors and other features of the framework. Switching the parser for a different implementation is currently not possible via public APIs.

### PoC
Start an applications that accesses `Request.json()`, `Request.msgpack()` or `Request.form()` or uses an extractor that relies on those parsers internally, and send a large request with a matching content type. The actual content of the request does not matter. For example: `curl -F "foo=</dev/random" http://127.0.0.1:8000/`) for `multipart/form-data`. Server memory consumption will increase very quickly until memory (and swap) are exhausted.

### Impact
This is a denial of service (DoS) vulnerability affecting all Litestar applications that process json, msgpack or form-data submission requests.
GitHub Security Advisory: GHSA-2qmj-7962-cjq8
Package: langchain (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 0.0.247
Patched in: 0.0.247

Summary: langchain arbitrary code execution vulnerability

Details:
An issue in langchain allows an attacker to execute arbitrary code via the PALChain in the python exec method.
GitHub Security Advisory: GHSA-3863-2447-669p
Package: transformers (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 4.36.0
Patched in: 4.36.0

Summary: transformers has a Deserialization of Untrusted Data vulnerability

Details:
Deserialization of Untrusted Data in GitHub repository huggingface/transformers prior to 4.36.0.
GitHub Security Advisory: GHSA-vc3v-ppc7-v486
Package: vantage6-node (PIP)
Severity: HIGH (CVSS 7.2)
CWE: CWE-345: Insufficient Verification of Data Authenticity, CWE-358: Improperly Implemented Security Check for Standard
Vulnerable versions: < 4.1.2
Patched in: 4.1.2

Summary: vantage6-server node accepts non-whitelisted algorithms from malicious server

Details:
### Impact
A node does not check if an image is allowed to run if a `parent_id` is set. A malicious party that breaches the server may modify it to set a fake `parent_id` and send a task of a non-whitelisted algorithm. The node will then execute it because the `parent_id` that is set prevents checks from being run. Relevant node code [here](https://github.com/vantage6/vantage6/blob/version/4.1.1/vantage6-node/vantage6/node/docker/docker_manager.py#L265-L268)

This impacts all servers that are breached by an expert user

### Patches
Fixed in v4.1.2

### Workarounds
None
GitHub Security Advisory: GHSA-282v-666c-3fvg
Package: transformers (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-377: Insecure Temporary File
Vulnerable versions: < 4.30.0
Patched in: 4.30.0

Summary: transformers has Insecure Temporary File

Details:
Insecure Temporary File in GitHub repository huggingface/transformers 4.29.2 and prior. A fix is available at commit 80ca92470938bbcc348e2d9cf4734c7c25cb1c43 and has been released as part of version 4.30.0.
GitHub Security Advisory: GHSA-377p-g8gr-5wpg
Package: lief (PIP)
Severity: LOW (CVSS 3.9)
CWE: CWE-457: Use of Uninitialized Variable
Vulnerable versions: < 0.15.0
Patched in: 0.15.0

Summary: LIEF obtain sensitive information via the name parameter

Details:
An issue in LIEF v.0.14.1 allows a local attacker to obtain sensitive information via the name parameter of the machd_reader.c component.
GitHub Security Advisory: GHSA-8w49-h785-mj3c
Package: tornado (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 6.4.1
Patched in: 6.4.2

Summary: Tornado has an HTTP cookie parsing DoS vulnerability

Details:
The algorithm used for parsing HTTP cookies in Tornado versions prior to 6.4.2 sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests.

See also CVE-2024-7592 for a similar vulnerability in cpython.
GitHub Security Advisory: GHSA-5pcj-3m26-w633
Package: patchelf (PIP)
Severity: HIGH (CVSS 9.1)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.16.1.0
Patched in: 0.16.1.0

Summary: Patchelf out-of-bounds read

Details:
Patchelf v0.9 was discovered to contain an out-of-bounds read via the function modifyRPath at src/patchelf.cc.
GitHub Security Advisory: GHSA-g58x-799h-v9h6
Package: pyboolector (PIP)
Severity: HIGH (CVSS 5.5)
CWE: CWE-416: Use After Free
Vulnerable versions: < 3.1.0
Patched in: 3.1.0

Summary: Boolector use after free

Details:
In parser/btorsmt2.c in Boolector 3.0.0, opening a specially crafted input file leads to a use after free in get_failed_assumptions or btor_delete.
GitHub Security Advisory: GHSA-vm3q-58wm-2r2x
Package: pglast (PIP)
Severity: HIGH (CVSS 6.5)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Vulnerable versions: < 0.28
Patched in: 0.28

Summary: libpg_query memory leak

Details:
An issue was discovered in libpg_query 10-1.0.2. There is a memory leak in pg_query_raw_parse in pg_query_parse.c, which might lead to a denial of service.
GitHub Security Advisory: GHSA-vm3q-58wm-2r2x
Package: pg-query (PIP)
Severity: HIGH (CVSS 6.5)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Vulnerable versions: < 0.28
Patched in: 0.28

Summary: libpg_query memory leak

Details:
An issue was discovered in libpg_query 10-1.0.2. There is a memory leak in pg_query_raw_parse in pg_query_parse.c, which might lead to a denial of service.
GitHub Security Advisory: GHSA-98j2-hfxp-8h8r
Package: pydoris (PIP)
Severity: HIGH (CVSS 7.5)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: Apache Doris hardcoded key and IV

Details:
Apache Doris, prior to 1.0.0, used a hardcoded key and IV to initialize the cipher used for ldap password, which may lead to information disclosure.
GitHub Security Advisory: GHSA-5m6v-2xgf-qhrw
Package: mayan-edms (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 4.3.6
Patched in: 4.3.6

Summary: Mayan EDMS DMS XSS vulnerability

Details:
An XSS vulnerability was discovered in the Mayan EDMS DMS. Successful XSS exploitation was observed in the in-product tagging system.