deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-hxvr-gg2w-j48x
Package: backend.ai (PIP)
Severity: HIGH (CVSS 8.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 25.3.3
Patched in: unpatched

Summary: BackendAI vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Details:
Exposure of sensitive data in active sessions in Lablup's BackendAI allows attackers to retrieve credentials for users on the management platform.

NOTE: The maintainers of BackendAI do not consider this report to fit with their threat model and advise users to follow security advice from https://github.com/lablup/backend.ai/pull/7587 in their instances to protect themselves from the conditions that would lead to the situation described in the CVE record.
GitHub Security Advisory: GHSA-h889-475r-wfmm
Package: backend.ai (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 25.3.3
Patched in: unpatched

Summary: Backend.AI Missing Authorization vulnerability

Details:
Missing Authorization in Lablup's BackendAI allows attackers to takeover all active sessions; Accessing, stealing, or altering any data accessible in the session. This vulnerability exists in all current versions of BackendAI.

NOTE: The maintainers of BackendAI do not consider this report to fit with their threat model and advise users to follow security advice from https://github.com/lablup/backend.ai/pull/7587 in their instances to protect themselves from the conditions that would lead to the situation described in the CVE record.
GitHub Security Advisory: GHSA-rh67-4c8j-hjjh
Package: nautobot (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 2.0.0, < 2.4.10
Patched in: 2.4.10

Summary: Nautobot may allows uploaded media files to be accessible without authentication

Details:
### Impact

Files uploaded by users to Nautobot's `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.

For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.

Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.

### Patches

Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.

### Workarounds

No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)

### References
_Are there any links users can visit to find out more?_

- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340
- https://github.com/nautobot/nautobot/commit/d99a53b065129cff3a0fa9abe7355a9ef1ad4c95
GitHub Security Advisory: GHSA-rh67-4c8j-hjjh
Package: nautobot (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.6.32
Patched in: 1.6.32

Summary: Nautobot may allows uploaded media files to be accessible without authentication

Details:
### Impact

Files uploaded by users to Nautobot's `MEDIA_ROOT` directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.

For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the `devicetype-images/` subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.

Similarly, for all other image attachments, while the images *can* be listed by accessing the `/api/extras/image-attachments/` endpoint *as an authenticated user only*, absent that authenticated access, accessing the files would again require guessing file names correctly.

### Patches

Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.

### Workarounds

No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)

### References
_Are there any links users can visit to find out more?_

- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340
- https://github.com/nautobot/nautobot/commit/d99a53b065129cff3a0fa9abe7355a9ef1ad4c95
GitHub Security Advisory: GHSA-wjw6-95h5-4jpx
Package: nautobot (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: >= 2.0.0, < 2.4.10
Patched in: 2.4.10

Summary: Nautobot vulnerable to secrets exposure and data manipulation through Jinja2 templating

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

All users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected.

Due to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot:

1. A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered.
2. A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Nautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

The vulnerability can be partially mitigated by configuring object permissions appropriately to limit the below actions to only trusted users:

- `extras.add_secret`
- `extras.change_secret`
- `extras.view_secret`
- `extras.add_computedfield`
- `extras.change_computedfield`
- `extras.add_customlink`
- `extras.change_customlink`
- `extras.add_jobbutton`
- `extras.change_jobbutton`

### References
_Are there any links users can visit to find out more?_

- https://jinja.palletsprojects.com/en/stable/sandbox/
- https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description
- https://github.com/nautobot/nautobot/pull/7417
- https://github.com/nautobot/nautobot/pull/7429
GitHub Security Advisory: GHSA-wjw6-95h5-4jpx
Package: nautobot (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: < 1.6.32
Patched in: 1.6.32

Summary: Nautobot vulnerable to secrets exposure and data manipulation through Jinja2 templating

Details:
### Impact
_What kind of vulnerability is it? Who is impacted?_

All users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected.

Due to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot:

1. A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered.
2. A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user.

### Patches
_Has the problem been patched? What versions should users upgrade to?_

Nautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability.

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

The vulnerability can be partially mitigated by configuring object permissions appropriately to limit the below actions to only trusted users:

- `extras.add_secret`
- `extras.change_secret`
- `extras.view_secret`
- `extras.add_computedfield`
- `extras.change_computedfield`
- `extras.add_customlink`
- `extras.change_customlink`
- `extras.add_jobbutton`
- `extras.change_jobbutton`

### References
_Are there any links users can visit to find out more?_

- https://jinja.palletsprojects.com/en/stable/sandbox/
- https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description
- https://github.com/nautobot/nautobot/pull/7417
- https://github.com/nautobot/nautobot/pull/7429
GitHub Security Advisory: GHSA-9wj4-8h85-pgrw
Package: OctoPrint (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-140: Improper Neutralization of Delimiters, CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 1.11.2
Patched in: 1.11.2

Summary: OctoPrint Vulnerable to Denial of Service through malformed HTTP request in OctoPrint

Details:
### Impact

OctoPrint versions up until and including 1.11.1 contain a vulnerability that allows any unauthenticated attacker to send a manipulated broken `multipart/form-data` request to OctoPrint and through that make the web server component become unresponsive. This could be used to effectively run a denial of service attack on the OctoPrint server.

### Patches

The vulnerability has been patched in version 1.11.2.

### Workaround

OctoPrint administrators are once more reminded to not make OctoPrint available on hostile networks (e.g. the internet), regardless of whether this vulnerability is patched or not.

### Details

The issue can be triggered by a broken `multipart/form-data` request lacking an end boundary to any of OctoPrint's endpoints implemented through the `octoprint.server.util.tornado.UploadStorageFallbackHandler` request handler. The request handler will get stuck in an endless busy loop, looking for a part of the request that will never come. As Tornado is single-threaded, that will effectively block the whole web server.

The fix adds detection of invalid requests like that and ensures they are handled gracefully with an HTTP 400 Bad Request response.

### Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi.
GitHub Security Advisory: GHSA-m9jh-jf9h-x3h2
Package: OctoPrint (PIP)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: < 1.11.2
Patched in: 1.11.2

Summary: OctoPrint vulnerable to possible file extraction via upload endpoints

Details:
### Impact

OctoPrint versions up until and including 1.11.1 contain a vulnerability that allows an attacker with the `FILE_UPLOAD` permission to exfiltrate files from the host that OctoPrint has read access to, by moving them into the upload folder where they then can be downloaded from.

The primary risk lies in the potential exfiltration of secrets stored inside OctoPrint's config, or further system files. By removing important runtime files, this could also be used to impact the availability of the host. Given that the attacker requires a user account with file upload permissions, the actual impact of this should however hopefully be minimal in most cases.

### Patches

The vulnerability has been patched in version 1.11.2.

### Details

A specially crafted HTTP Request to an affected upload endpoint that contains some form inputs only supposed to be used internally can be used to make OctoPrint move a file that it thinks is a freshly uploaded temporary one into its upload folder.

The following endpoints in OctoPrint are affected:

- `/api/files/{local|sdcard}`
- `/api/languages`
- `/plugin/backup/restore`
- `/plugin/pluginmanager/upload_file`

Further upload endpoints in third party plugins might be affected too.

The fix removes any internal-only form inputs from incoming requests in the central file upload processor component.

### Credits

This vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi
GitHub Security Advisory: GHSA-9hjg-9r4m-mvj7
Package: requests (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: < 2.32.4
Patched in: 2.32.4

Summary: Requests vulnerable to .netrc credentials leak via malicious URLs

Details:
### Impact

Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs.

### Workarounds
For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on your Requests Session ([docs](https://requests.readthedocs.io/en/latest/api/#requests.Session.trust_env)).

### References
https://github.com/psf/requests/pull/6965
https://seclists.org/fulldisclosure/2025/Jun/2
GitHub Security Advisory: GHSA-h92g-3xc3-ww2r
Package: skyvern (PIP)
Severity: HIGH (CVSS 8.5)
CWE: CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: Skyvern has a Jinja runtime leak

Details:
Skyvern through 0.2.0 has a Jinja runtime leak in sdk/workflow/models/block.py.
GitHub Security Advisory: GHSA-jwhx-xcg6-8xhj
Package: aiohttp (PIP)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: >= 3.10.0b1, < 3.10.2
Patched in: 3.10.2

Summary: In aiohttp, compressed files as symlinks are not protected from path traversal

Details:
### Summary
Static routes which contain files with compressed variants (`.gz` or `.br` extension) were vulnerable to path traversal outside the root directory if those variants are symbolic links.

### Details
The server protects static routes from path traversal outside the root directory when `follow_symlinks=False` (default).  It does this by resolving the requested URL to an absolute path and then checking that path relative to the root.  However, these checks are not performed when looking for compressed variants in the `FileResponse` class, and symbolic links are then automatically followed when performing `Path.stat()` and `Path.open()` to send the file.

### Impact
Servers with static routes that contain compressed variants as symbolic links, pointing outside the root directory, or that permit users to upload or create such links, are impacted.

----

Patch: https://github.com/aio-libs/aiohttp/pull/8653/files
GitHub Security Advisory: GHSA-g92j-qhmh-64v2
Package: sentry-sdk (PIP)
Severity: LOW (CVSS 2.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.45.1
Patched in: 1.45.1

Summary: Sentry's Python SDK unintentionally exposes environment variables to subprocesses

Details:
### Impact

The bug in Sentry's Python SDK <2.8.0 results in the unintentional exposure of environment variables to subprocesses despite the `env={}` setting.

### Details

In Python's `subprocess` calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use `env` argument in `subprocess` calls, like in this example:

```
>>> subprocess.check_output(["env"], env={"TEST":"1"})
b'TEST=1\n'
```

If you'd want to not pass any variables, you can set an empty dict:

```
>>> subprocess.check_output(["env"], env={})
b''
```

However, the bug in Sentry SDK <2.8.0 causes **all environment variables** to be passed to the subprocesses when `env={}` is set, unless the Sentry SDK's [Stdlib](https://docs.sentry.io/platforms/python/integrations/default-integrations/#stdlib) integration is disabled. The Stdlib integration is enabled by default.

### Patches
The issue has been patched in https://github.com/getsentry/sentry-python/pull/3251 and the fix released in [sentry-sdk==2.8.0](https://github.com/getsentry/sentry-python/releases/tag/2.8.0). The fix was also backported to [sentry-sdk==1.45.1](https://github.com/getsentry/sentry-python/releases/tag/1.45.1).

### Workarounds

We strongly recommend upgrading to the latest SDK version. However, if it's not possible, and if passing environment variables to child processes poses a security risk for you, there are two options:

1. In your application, replace `env={}` with the minimal dict `env={"EMPTY_ENV":"1"}` or similar.

OR

2. Disable Stdlib integration:
```
import sentry_sdk

# Should go before sentry_sdk.init
sentry_sdk.integrations._DEFAULT_INTEGRATIONS.remove("sentry_sdk.integrations.stdlib.StdlibIntegration")

sentry_sdk.init(...)
```

### References
* Sentry docs: [Default integrations](https://docs.sentry.io/platforms/python/integrations/default-integrations/)
* Python docs: [subprocess module](https://docs.python.org/3/library/subprocess.html)
* Patch https://github.com/getsentry/sentry-python/pull/3251
GitHub Security Advisory: GHSA-g92j-qhmh-64v2
Package: sentry-sdk (PIP)
Severity: LOW (CVSS 2.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 2.0.0a1, < 2.8.0
Patched in: 2.8.0

Summary: Sentry's Python SDK unintentionally exposes environment variables to subprocesses

Details:
### Impact

The bug in Sentry's Python SDK <2.8.0 results in the unintentional exposure of environment variables to subprocesses despite the `env={}` setting.

### Details

In Python's `subprocess` calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use `env` argument in `subprocess` calls, like in this example:

```
>>> subprocess.check_output(["env"], env={"TEST":"1"})
b'TEST=1\n'
```

If you'd want to not pass any variables, you can set an empty dict:

```
>>> subprocess.check_output(["env"], env={})
b''
```

However, the bug in Sentry SDK <2.8.0 causes **all environment variables** to be passed to the subprocesses when `env={}` is set, unless the Sentry SDK's [Stdlib](https://docs.sentry.io/platforms/python/integrations/default-integrations/#stdlib) integration is disabled. The Stdlib integration is enabled by default.

### Patches
The issue has been patched in https://github.com/getsentry/sentry-python/pull/3251 and the fix released in [sentry-sdk==2.8.0](https://github.com/getsentry/sentry-python/releases/tag/2.8.0). The fix was also backported to [sentry-sdk==1.45.1](https://github.com/getsentry/sentry-python/releases/tag/1.45.1).

### Workarounds

We strongly recommend upgrading to the latest SDK version. However, if it's not possible, and if passing environment variables to child processes poses a security risk for you, there are two options:

1. In your application, replace `env={}` with the minimal dict `env={"EMPTY_ENV":"1"}` or similar.

OR

2. Disable Stdlib integration:
```
import sentry_sdk

# Should go before sentry_sdk.init
sentry_sdk.integrations._DEFAULT_INTEGRATIONS.remove("sentry_sdk.integrations.stdlib.StdlibIntegration")

sentry_sdk.init(...)
```

### References
* Sentry docs: [Default integrations](https://docs.sentry.io/platforms/python/integrations/default-integrations/)
* Python docs: [subprocess module](https://docs.python.org/3/library/subprocess.html)
* Patch https://github.com/getsentry/sentry-python/pull/3251
GitHub Security Advisory: GHSA-v3c8-3pr6-gr7p
Package: llama-index (PIP)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.12.28
Patched in: 0.12.28

Summary: llama_index vulnerable to SQL Injection

Details:
Multiple vector store integrations in run-llama/llama_index version v0.12.21 have SQL injection vulnerabilities. These vulnerabilities allow an attacker to read and write data using SQL, potentially leading to unauthorized access to data of other users depending on the usage of the llama-index library in a web application.
GitHub Security Advisory: GHSA-7xr5-9hcq-chf9
Package: Django (PIP)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: < 4.2.22
Patched in: 4.2.22

Summary: Django Improper Output Neutralization for Logs vulnerability

Details:
An issue was discovered in Django 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
GitHub Security Advisory: GHSA-7xr5-9hcq-chf9
Package: Django (PIP)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: >= 5.0a1, < 5.1.10
Patched in: 5.1.10

Summary: Django Improper Output Neutralization for Logs vulnerability

Details:
An issue was discovered in Django 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
GitHub Security Advisory: GHSA-7xr5-9hcq-chf9
Package: Django (PIP)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: >= 5.2, < 5.2.2
Patched in: 5.2.2

Summary: Django Improper Output Neutralization for Logs vulnerability

Details:
An issue was discovered in Django 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
GitHub Security Advisory: GHSA-55g9-6c2x-gf8q
Package: label-studio-ml (PIP)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-502: Deserialization of Untrusted Data
Vulnerable versions: <= 1.0.9
Patched in: unpatched

Summary: HumanSignal label-studio-ml-backend Deserialization of Untrusted Data vulnerability

Details:
A vulnerability has been found in HumanSignal label-studio-ml-backend up to 9fb7f4aa186612806af2becfb621f6ed8d9fdbaf and classified as problematic. Affected by this vulnerability is the function load of the file label-studio-ml-backend/label_studio_ml/examples/yolo/utils/neural_nets.py of the component PT File Handler. The manipulation of the argument path leads to deserialization. An attack has to be approached locally. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available.
GitHub Security Advisory: GHSA-6vx8-pcwv-xhf4
Package: signxml (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-303: Incorrect Implementation of Authentication Algorithm
Vulnerable versions: < 4.0.4
Patched in: 4.0.4

Summary: SignXML's signature verification with HMAC is vulnerable to an algorithm confusion attack

Details:
When verifying signatures with X509 certificate validation turned off and HMAC shared secret set (`signxml.XMLVerifier.verify(require_x509=False, hmac_key=...`), prior versions of SignXML are vulnerable to a potential algorithm confusion attack. Unless the user explicitly limits the expected signature algorithms using the `signxml.XMLVerifier.verify(expect_config=...)` setting, an attacker may supply a signature unexpectedly signed with a key other than the provided HMAC key, using a different (asymmetric key) signature algorithm.

Starting with signxml 4.0.4, specifying `hmac_key` causes the set of accepted signature algorithms to be restricted to HMAC only, if not already restricted by the user.