deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vfgx-5q85-58q3
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-330: Use of Insufficiently Random Values
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt has non-cryptographic PRNG used for steganography pixel selection

Details:
### Summary

The `generate_pseudorandom_sequence()` function in `openssl_encrypt/plugins/steganography/core/utils.py` at **lines 89-91** uses Python's `random` module (Mersenne Twister) for steganographic pixel/sample selection.

### Affected Code

```python
random.seed(seed)
sequence = random.sample(range(max_value), min(length, max_value))
return sequence
```

Additionally, the steganography password is stored as a plain Python string (not `SecureBytes`) and only 8 bytes (64 bits) of the SHA-256 hash are used for the seed, reducing effective security to 64 bits.

### Impact

The Mersenne Twister's state can be recovered from approximately 624 outputs. An attacker who knows or guesses the password can predict the PRNG sequence and determine exactly which pixels contain hidden data, potentially extracting the hidden data without the password.

### Recommended Fix

- Use HMAC-DRBG or `secrets` module for cryptographically secure pixel selection
- Use full 32-byte SHA-256 output as seed material
- Store the password in `SecureBytes` instead of a plain string

### Fix

Fixed in commit `09e96e0` on branch `releases/1.4.x` — replaced random.seed(hash(password)) with HMAC-SHA256 based CSPRNG (Fisher-Yates shuffle) and numpy Generator with HMAC-derived seeds across all steganography format modules.
GitHub Security Advisory: GHSA-h3m5-p59h-x88p
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-256: Plaintext Storage of a Password
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt has visible password in process list via --password CLI argument

Details:
### Summary

Passwords passed via the `--password` / `-p` CLI argument in `openssl_encrypt/modules/crypt_cli_subparser.py` at **lines 150-154** are visible to any user on the system via `ps aux` or `/proc/[pid]/cmdline`.

### Affected Code

```python
subparser.add_argument(
    "--password", "-p",
    help="Password (will prompt if not provided, or use CRYPT_PASSWORD environment variable)",
)
```

Similarly, `--keystore-password` exposes the keystore password.

### Impact

On multi-user systems, any user can observe the encryption password by listing processes. The `CRYPT_PASSWORD` environment variable alternative is also visible via `/proc/[pid]/environ` (though with slightly restricted access).

### Recommended Fix

- Document the security implications prominently
- Recommend interactive prompting (already supported) as the secure default
- Consider supporting password file descriptors (`--password-fd`) or reading from stdin
- Consider marking the argument as deprecated in favor of interactive prompting

### Fix

Fixed in commit `e78a366` on branch `releases/1.4.x` — added --password-file and --password-fd arguments; added OPENSSL_ENCRYPT_PASSWORD env var support; --password now emits deprecation warning.
GitHub Security Advisory: GHSA-h45m-mgcp-q388
Package: openssl-encrypt (PIP)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt: TOTP rate limiter is in-memory only — not shared across workers, lost on restart

Details:
## Severity: HIGH

### Summary

The TOTP brute-force rate limiter in `openssl_encrypt_server/modules/pepper/totp.py` at **lines 47-98** uses an in-memory `defaultdict(list)` as a class variable.

### Affected Code

```python
class TOTPRateLimiter:
    def __init__(self, ...):
        self.attempts: Dict[str, List[datetime]] = defaultdict(list)
        self.lockouts: Dict[str, datetime] = {}

class TOTPService:
    _rate_limiter = TOTPRateLimiter()  # Class variable, in-memory only
```

### Impact

1. Rate limit state is **not shared** across multiple server instances/workers — an attacker can distribute attempts
2. All rate limit state is **lost on server restart** — allows immediate retry
3. In multi-worker deployments, each worker has independent rate limit state

### Recommended Fix

- Use Redis or the database for rate limit state storage
- Or use a shared-memory approach for multi-worker deployments
- At minimum, persist lockout state to survive restarts

### Fix

Fixed in commit `2749bc0` on branch `releases/1.4.x` — added abstract RateLimitBackend with InMemoryBackend and DatabaseBackend implementations; defaults to DatabaseBackend when DB available.
GitHub Security Advisory: GHSA-j48q-4c78-rhf9
Package: openssl-encrypt (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-427: Uncontrolled Search Path Element
Vulnerable versions: < 1.4.0
Patched in: 1.4.0

Summary: openssl-encrypt: Dynamic .so loading for Whirlpool uses broad glob pattern without integrity verification

Details:
## Severity: HIGH

### Summary

The Whirlpool hash implementation in `openssl_encrypt/modules/registry/hash_registry.py` at **lines 570-589** uses glob patterns to find `.so` modules in site-packages and loads the first match via `importlib` without verifying module integrity.

### Affected Code

```python
for site_pkg in site.getsitepackages():
    pattern = os.path.join(site_pkg, "whirlpool*py313*.so")
    py313_modules = glob.glob(pattern)
    if py313_modules:
        module_path = py313_modules[0]  # Takes first match
        loader = ExtensionFileLoader("whirlpool", module_path)
        spec = importlib.util.spec_from_file_location("whirlpool", module_path, loader=loader)
        whirlpool_module = importlib.util.module_from_spec(spec)
        spec.loader.exec_module(whirlpool_module)
```

### Impact

The glob pattern `"whirlpool*py313*.so"` is broad and takes the first match without verifying:
- File hash/signature
- File ownership/permissions
- Whether it's a legitimate module

If an attacker can place a malicious `.so` file matching this pattern in any site-packages directory, it will be loaded and native code executed.

### Recommended Fix

- Verify the module's integrity (hash or signature) before loading
- Use a specific filename rather than a glob pattern
- Check file permissions and ownership

### Fix

Fixed in commit `963d0d1` on branch `releases/1.4.x` — added os.path.realpath() to resolve symlinks and validation that found .so files are within known site-packages directories before loading.
GitHub Security Advisory: GHSA-8prr-286p-4w7j
Package: alerta-server (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 9.1.0
Patched in: 9.1.0

Summary: alerta-server has potential SQL Injection vulnerability in Query String Syntax (q=) API

Details:
### Impact
The Query string search API (q=) was vulnerable to SQL injection via the Postgres query parser, which built WHERE clauses by interpolating user-supplied search terms directly into SQL strings via f-strings.

### Patches
Fixed in v9.1.0. The Postgres query parser now uses parameterized queries with %(name)s placeholders passed to psycopg2's cursor.execute(), preventing SQL injection through the ?q= parameter. The MongoDB backend was not affected.

### Workarounds
Upgrade to v9.1.0 or later. If unable to upgrade, deploy a proxy in front of the Alerta API to sanitize the q= parameter.

### Resources
https://github.com/alerta/alerta/pull/712/files
https://owasp.org/www-community/attacks/SQL_Injection
GitHub Security Advisory: GHSA-g6pg-52vf-843h
Package: mlflow (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 3.8.1
Patched in: unpatched

Summary: MLFlow allows Tracing + Assessments Access

Details:
In the latest version of mlflow/mlflow, when the `basic-auth` app is enabled, tracing and assessment endpoints are not protected by permission validators. This allows any authenticated user, including those with `NO_PERMISSIONS` on the experiment, to read trace information and create assessments for traces they should not have access to. This vulnerability impacts confidentiality by exposing trace metadata and integrity by allowing unauthorized creation of assessments. Deployments using `mlflow server --app-name=basic-auth` are affected.
GitHub Security Advisory: GHSA-xmpv-j7p2-j873
Package: nautobot (PIP)
Severity: LOW (CVSS 2.7)
CWE: CWE-521: Weak Password Requirements
Vulnerable versions: >= 3.0.0, < 3.0.10
Patched in: 3.0.10

Summary: Nautobot: Management of users via REST API does not apply configured password validators

Details:
### Impact

In Nautobot versions prior to 2.4.30 or prior to 3.0.10, user creation and editing via the REST API fails to apply the password validation rules defined by Django's `AUTH_PASSWORD_VALIDATORS` setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's `nautobot_config.py` to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak or otherwise do not comply with configured standards.

Management of users via the Nautobot admin UI does correctly enforce configured password validation at this time.

### Patches

The issue is resolved in Nautobot versions 2.4.30 and 3.0.10 and later.

- https://github.com/nautobot/nautobot/pull/8778
- https://github.com/nautobot/nautobot/pull/8779

### Workarounds

Review which users have been granted object permissions to create and modify user accounts as well as having access tokens for the REST API, and restrict access as appropriate.

It may be appropriate furthermore to rotate passwords for any user accounts suspected to have been given weak passwords.

### References

- https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-AUTH_PASSWORD_VALIDATORS
- http://docs.djangoproject.com/en/4.2/topics/auth/passwords/#password-validation
GitHub Security Advisory: GHSA-xmpv-j7p2-j873
Package: nautobot (PIP)
Severity: LOW (CVSS 2.7)
CWE: CWE-521: Weak Password Requirements
Vulnerable versions: < 2.4.30
Patched in: 2.4.30

Summary: Nautobot: Management of users via REST API does not apply configured password validators

Details:
### Impact

In Nautobot versions prior to 2.4.30 or prior to 3.0.10, user creation and editing via the REST API fails to apply the password validation rules defined by Django's `AUTH_PASSWORD_VALIDATORS` setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's `nautobot_config.py` to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak or otherwise do not comply with configured standards.

Management of users via the Nautobot admin UI does correctly enforce configured password validation at this time.

### Patches

The issue is resolved in Nautobot versions 2.4.30 and 3.0.10 and later.

- https://github.com/nautobot/nautobot/pull/8778
- https://github.com/nautobot/nautobot/pull/8779

### Workarounds

Review which users have been granted object permissions to create and modify user accounts as well as having access tokens for the REST API, and restrict access as appropriate.

It may be appropriate furthermore to rotate passwords for any user accounts suspected to have been given weak passwords.

### References

- https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-AUTH_PASSWORD_VALIDATORS
- http://docs.djangoproject.com/en/4.2/topics/auth/passwords/#password-validation
GitHub Security Advisory: GHSA-m8x7-r2rg-vh5g
Package: fastmcp (PIP)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: FastMCP has a Command Injection vulnerability - Gemini CLI

Details:
Server names containing shell metacharacters (e.g., `&`) can cause command injection on Windows when passed to `fastmcp install claude-code` or `fastmcp install gemini-cli`. These install paths use `subprocess.run()` with a list argument, but on Windows the target CLIs often resolve to `.cmd` wrappers that are executed through `cmd.exe`, which interprets metacharacters in the flattened command string.

PoC:
```python
from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]
```

```
fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py
```

On Windows, this opens Calculator via the `&calc` in the server name.

Impact:
Arbitrary command execution with the privileges of the user running `fastmcp install`. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a `.cmd` wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.
GitHub Security Advisory: GHSA-w7rv-gfp4-j9j3
Package: slippers (PIP)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.6.2
Patched in: 0.6.3

Summary: Slippers Vulnerable to Cross-Site Scripting (XSS) in `attrs` Template Tag

Details:
## Summary

A Cross-site Scripting (XSS) vulnerability exists in the `{% attrs %}` template tag of the `slippers` Django package. When a context variable containing untrusted data is passed to `{% attrs %}`, the value is interpolated into an HTML attribute string without escaping, allowing an attacker to break out of the attribute context and inject arbitrary HTML or JavaScript into the rendered page.

## Vulnerability details

### Root cause

`AttrsNode` is a custom `Node` subclass registered via `register.tag()`. Unlike `register.simple_tag()`, which automatically applies `conditional_escape()` when autoescape is on, custom `Node.render()` methods receive no automatic escaping and are fully responsible for sanitising their output. `attr_string()` fails to do this:

```python
def attr_string(key: str, value: Any):
    if isinstance(value, bool):
        return key if value else ""
    key = key.replace("_", "-")
    return f'{key}="{value}"'   # value is not escaped
```

### Attack scenario

Given a template that uses `{% attrs %}` with a user-supplied value:

```django
{% load slippers %}
<input {% attrs type placeholder %}>
```

```python
render(request, "search.html", {"placeholder": request.GET.get("q", "")})
```

An attacker crafting a request with `q=" onmouseover="alert(document.cookie)" x="` produces:

```html
<input type="text" placeholder="" onmouseover="alert(document.cookie)" x="">
```

## Impact

Any template that passes values derived from user input, database content, or other untrusted sources to `{% attrs %}` is vulnerable. Successful exploitation can lead to session hijacking, credential theft, arbitrary actions on behalf of the victim, and page defacement.

## Remediation

Replace the f-string in `attr_string()` with `format_html()`, which escapes both key and value:

```python
from django.utils.html import format_html

def attr_string(key: str, value: Any):
    if isinstance(value, bool):
        return key if value else ""
    key = key.replace("_", "-")
    return format_html('{}="{}"', key, value)
```

Until a patch is available, sanitise untrusted values before passing them to `{% attrs %}`, for example with `django.utils.html.escape()` in the view layer.
GitHub Security Advisory: GHSA-5239-wwwm-4pmq
Package: Pygments (PIP)
Severity: LOW (CVSS 3.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 2.20.0
Patched in: 2.20.0

Summary: Pygments has Regular Expression Denial of Service (ReDoS) due to Inefficient Regex for GUID Matching

Details:
A security flaw has been discovered in pygments before 2.20.0. The impacted element is the function AdlLexer of the file pygments/lexers/archetype.py. The manipulation results in inefficient regular expression complexity. The attack is only possible with local access. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.
GitHub Security Advisory: GHSA-7fqq-q52p-2jjg
Package: OpenCC (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: OpenCC  has an Out-of-bounds read when processing truncated UTF-8 input

Details:
### Summary

OpenCC versions before 1.2.0 contain two `CWE-125: Out-of-bounds Read` issues caused by length validation failures in UTF-8 processing. When handling malformed or truncated UTF-8 input, OpenCC trusted derived length values without enforcing the invariant that processed length must not exceed the remaining input buffer. This could result in out-of-bounds reads during segmentation or conversion.

### Details

Two independent code paths in OpenCC failed to enforce the invariant:

`matchedLength <= remainingLength`

Both paths assumed derived length values were valid and within input bounds, but did not validate that assumption against the remaining buffer. This created the following failure chain:

`invalid UTF-8 -> incorrect derived length -> incorrect pointer advance -> remaining-length desynchronization -> out-of-bounds read`

In `MaxMatchSegmentation::Segment`, this could desynchronize remaining-length tracking and cause out-of-bounds reads during prefix matching.

In `Conversion::Convert(const char*)`, similar logic could advance processing past the end of the input string and read beyond the null terminator into adjacent memory. In some cases, unintended heap bytes could be propagated into the conversion result.

PR #1005 fixes both issues by explicitly tracking input boundaries, recomputing remaining length on each iteration, and clamping processed lengths so the buffer-bound invariant is preserved.

Affected versions:

* All versions before 1.2.0

Patched version:

* 1.2.0

### PoC

Build a vulnerable version with AddressSanitizer enabled and process input ending with a truncated UTF-8 sequence, such as a missing final byte of a 3-byte character. The original report and ASan reproduction are available in [Issue #997](https://github.com/BYVoid/OpenCC/issues/997).

### Impact

This vulnerability may cause process crashes and limited, non-deterministic information disclosure when OpenCC processes malformed or attacker-controlled UTF-8 input. The issue does not indicate arbitrary write or code execution.

OpenCC is distributed through system and language-specific package managers, prebuilt binaries, container images, and downstream software, so affected versions may be present even when it is not listed as a direct dependency. Users should upgrade all installed or bundled copies of OpenCC to 1.2.0 or later.

### Credit

OpenCC thanks @oneafter for reporting the issue.
GitHub Security Advisory: GHSA-m959-cc7f-wv43
Package: cryptography (PIP)
Severity: LOW (CVSS 5.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 46.0.6
Patched in: 46.0.6

Summary: cryptography has incomplete DNS name constraint enforcement on peer names

Details:
## Summary

In versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named `bar.example.com` to validate against a wildcard leaf certificate for `*.example.com`, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for `bar.example.com`.

This behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.

In practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.

See CVE-2025-61727 for a similar bypass in Go's `crypto/x509`.

## Remediation

Users should upgrade to 46.0.6 or newer. 

## Attribution

Reporter: @1seal
GitHub Security Advisory: GHSA-p4hh-mq57-gq8x
Package: signify (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: < 0.9.2
Patched in: 0.9.2

Summary: Signify allows a remote attacker to escalate privileges via the signed_data.py and the context.py components

Details:
An issue in ralphje Signify before v.0.9.2 allows a remote attacker to escalate privileges via the signed_data.py and the context.py components
GitHub Security Advisory: GHSA-8c4j-f57c-35cf
Package: langflow-base (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: <= 0.5.0
Patched in: 0.5.1

Summary: Langflow: Authenticated Users Can Read, Modify, and Delete Any Flow via Missing Ownership Check

Details:
## Vulnerability

### IDOR in `GET/PATCH/DELETE /api/v1/flow/{flow_id}`

The `_read_flow` helper in `src/backend/base/langflow/api/v1/flows.py` branched on the `AUTO_LOGIN` setting to decide whether to filter by `user_id`. When `AUTO_LOGIN` was `False` (i.e., authentication was enabled), neither branch enforced an ownership check — the query returned any flow matching the given UUID regardless of who owned it.

This exposed any authenticated user to:

- **Read** any other user's flow, including embedded plaintext API keys
- **Modify** the logic of another user's AI agents
- **Delete** flows belonging to other users

The vulnerability was introduced by the conditional logic that was meant to accommodate public/example flows (those with `user_id = NULL`) under auto-login mode, but inadvertently left the authenticated path without an ownership filter.

---

## Fix (PR #8956)

The fix removes the `AUTO_LOGIN` conditional entirely and unconditionally scopes the query to the requesting user:

```diff
-    auth_settings = settings_service.auth_settings
-    stmt = select(Flow).where(Flow.id == flow_id)
-    if auth_settings.AUTO_LOGIN:
-        stmt = stmt.where(
-            (Flow.user_id == user_id) | (Flow.user_id == None)  # noqa: E711
-        )
+    stmt = select(Flow).where(Flow.id == flow_id).where(Flow.user_id == user_id)
```

All three operations — read, update, and delete — route through `_read_flow`, so the single change covers the full attack surface. A cross-user isolation test (`test_read_flows_user_isolation`) was added to prevent regression.

---

## Acknowledgements

Langflow thanks the security researcher who responsibly disclosed this vulnerability:

- **[@chximn-dt](https://github.com/chximn-dt)**