deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pwm3-7fv4-g6xx
Package: wagtail (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: >= 7.1, < 7.3.2
Patched in: 7.3.2

Summary: Wagtail has improper permission handling when deleting form submissions

Details:
### Impact

A CMS user with limited access to form pages could delete submissions to form pages they don't have access to by crafting a form submission to delete submissions on a page they do have access to for submissions they don't. 

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

### Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.


### Acknowledgements

Wagtail thanks Vishal Shukla @shukla304 for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-pwm3-7fv4-g6xx
Package: wagtail (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: < 7.0.7
Patched in: 7.0.7

Summary: Wagtail has improper permission handling when deleting form submissions

Details:
### Impact

A CMS user with limited access to form pages could delete submissions to form pages they don't have access to by crafting a form submission to delete submissions on a page they do have access to for submissions they don't. 

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin.

### Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.


### Acknowledgements

Wagtail thanks Vishal Shukla @shukla304 for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-c4mr-889m-vgf6
Package: wagtail (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: >= 7.1, < 7.3.2
Patched in: 7.3.2

Summary: Wagtail has improper permission handling when viewing page history

Details:
### Impact

A CMS user without the ability to edit a page could still access the history report for the page, potentially resulting in disclosure of sensitive information.

### Patches
Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.

### Acknowledgements

Wagtail thanks Seoyoung Kang @seoyoung-kang who is from AhnLab and also an independent security researcher for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-c4mr-889m-vgf6
Package: wagtail (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: < 7.0.7
Patched in: 7.0.7

Summary: Wagtail has improper permission handling when viewing page history

Details:
### Impact

A CMS user without the ability to edit a page could still access the history report for the page, potentially resulting in disclosure of sensitive information.

### Patches
Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.

### Acknowledgements

Wagtail thanks Seoyoung Kang @seoyoung-kang who is from AhnLab and also an independent security researcher for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-c6wj-9vcj-75pj
Package: wagtail (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: >= 7.1, < 7.3.2
Patched in: 7.3.2

Summary: Wagtail has improper permission handling when comparing revisions

Details:
### Impact

A CMS user without the ability to edit a page could access revisions of the page through the revision compare view if they knew the primary key of two revisions. This could potentially result in disclosure of sensitive information.

### Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.

### Acknowledgements

Many thanks to Seoyoung Kang @seoyoung-kang from AhnLab and an independent security researcher for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-c6wj-9vcj-75pj
Package: wagtail (PIP)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-280: Improper Handling of Insufficient Permissions or Privileges 
Vulnerable versions: < 7.0.7
Patched in: 7.0.7

Summary: Wagtail has improper permission handling when comparing revisions

Details:
### Impact

A CMS user without the ability to edit a page could access revisions of the page through the revision compare view if they knew the primary key of two revisions. This could potentially result in disclosure of sensitive information.

### Patches

Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix.

### Workarounds

No workaround is available.

### Acknowledgements

Many thanks to Seoyoung Kang @seoyoung-kang from AhnLab and an independent security researcher for reporting this issue.

### For more information
If there are any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html)
* Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
GitHub Security Advisory: GHSA-c7wp-3qh5-55pv
Package: open-webui (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 0.8.12
Patched in: 0.9.0

Summary: Open WebUI Missing Access Check on Channel Members Endpoint for Standard Channels

Details:
# Missing Access Check on Channel Members Endpoint for Standard Channels

## Affected Component

Channel members listing endpoint:
- `backend/open_webui/routers/channels.py` (lines 445-507, `get_channel_members_by_id`)

## Affected Versions

Current main branch and likely all versions with the channels feature.

## Description

The `GET /api/v1/channels/{id}/members` endpoint only checks membership for `group` and `dm` channel types (lines 467-469). For standard channels — including private ones — there is no `channel_has_access` check before returning the member list. Any authenticated user who knows a private channel's UUID can enumerate all users with access to that channel.

```python
# Line 467-469: only group/dm channels are checked
if channel.type in ['group', 'dm']:
    if not Channels.is_user_channel_member(channel.id, user.id, db=db):
        raise HTTPException(...)
# Standard channels fall through with NO access check
```

Compare with other channel endpoints (e.g., `get_channel_messages` at line 688) which correctly call `channel_has_access(user.id, channel, permission='read')` for standard channels.

## CVSS 3.1 Breakdown

| Metric | Value | Rationale |
|--------|-------|-----------|
| Attack Vector | Network (N) | Exploited remotely via API call |
| Attack Complexity | Low (L) | Single API call, no special conditions |
| Privileges Required | Low (L) | Requires a valid user account |
| User Interaction | None (N) | No victim interaction required |
| Scope | Unchanged (U) | Impact is within the channel authorization boundary |
| Confidentiality | Low (L) | Leaks user identities and details for a private channel |
| Integrity | None (N) | No data modification |
| Availability | None (N) | No denial of service |

## Attack Scenario

1. Attacker obtains a private standard channel's UUID (via logs, browser history, URL observation, or other API responses).
2. Attacker calls `GET /api/v1/channels/{id}/members`.
3. The server returns the full list of permitted users including their IDs, names, emails, roles, and profile images.
4. The attacker has no access to the channel's messages (those endpoints check access correctly), but now knows exactly who does.

## Impact

- Leaks the identity and personal details of every user with access to a private channel
- Reveals organizational structure and project assignments
- Enables targeted social engineering against channel members

## Preconditions

- Channels feature must be enabled (disabled by default)
- Attacker must know the channel UUID (not guessable, but obtainable through indirect means)
GitHub Security Advisory: GHSA-hp5m-24vp-vq2q
Package: open-webui (PIP)
Severity: HIGH (CVSS 7.1)
CWE: CWE-284: Improper Access Control, CWE-862: Missing Authorization
Vulnerable versions: <= 0.8.12
Patched in: 0.9.0

Summary: Open WebUI's responses passthrough endpoint lacks access control authorization

Details:
## Summary

The /responses endpoint in the OpenAI router accepts any authenticated user and forwards requests directly to upstream LLM providers without enforcing per-model access control. While the primary chat completion endpoint (generate_chat_completion) checks model ownership, group membership, and AccessGrants before allowing a request, the /responses proxy only validates that the user has a valid session via get_verified_user.

This allows any authenticated user — regardless of role or group assignment — to interact with any model configured on the instance by sending a POST request to /api/openai/responses with an arbitrary model ID.

## Impact

As per OWASP TOP 10 LLM:

- **Model Denial of Service (OWASP LLM04):** An unauthorized user can submit resource-intensive requests to expensive models (e.g., o1-pro, GPT-4o) that were explicitly restricted by the administrator. In shared deployments, this can exhaust API budgets or rate limits, causing total service disruption for all legitimate users.

- **Model Theft (OWASP LLM10):** If the instance proxies access to fine-tuned or self-hosted models, unauthorized users can freely interact with them, enabling capability extraction or model distillation without authorization.

- **Access Policy Bypass:** Administrators lose the ability to enforce cost-tier restrictions, team-based model assignments, or compliance boundaries through the existing access control system.

The endpoint is a raw passthrough proxy and does not resolve workspace model configurations (system prompts, knowledge bases, RAG pipelines). Therefore, workspace-specific confidential data is not directly exposed through this vector.

PR: https://github.com/open-webui/open-webui/pull/23481
GitHub Security Advisory: GHSA-fp53-qcf8-2xx2
Package: bugsink (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 2.1.2
Patched in: 2.1.3

Summary: Bunsink has an SSRF bypass in `validate_webhook_url`

Details:
## Summary

Bugsink’s webhook URL validation in versions 2.1.2 and earlier could be (partially) bypassed because of a mismatch in URL parsing.

In some malformed URLs, Python’s standard URL  parser (urllib) and the HTTP client stack (requests / urllib3) do not agree on which host is actually being targeted. That could allow a webhook URL to pass Bugsink’s outbound-host checks while the actual HTTP request is sent somewhere else.

## Impact

This issue affects Bugsink’s outbound webhook integrations.

An attacker who can supply or influence a webhook URL may be able to make Bugsink send an outbound HTTP POST request to a host that should have been blocked by the webhook validation logic, including loopback,
private, or otherwise non-allowlisted destinations.

The practical impact is limited:

- this is an outbound webhook SSRF issue, not a general-purpose proxy
- Bugsink does not follow redirects for these webhook requests
- the request shape is constrained by how the malformed URL is normalized by the HTTP client
- this does not give arbitrary control over every possible request path

In other words, this is a real validation bypass, but it is narrower than a full arbitrary-request primitive.

## Technical Details

The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post.

For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public
hostname during validation, while the HTTP client actually connects to a different host.

## Fix

The fix has two parts:

1. Bugsink now normalizes webhook URLs using the same HTTP client stack that will later send them, and applies validation to that normalized form.
2. Bugsink now outright rejects raw webhook URLs containing characters outside the RFC URL character set, rather than relying on downstream normalization of malformed input.

Together, these changes remove the parser discrepancy and make webhook URL handling stricter and more predictable.

## Workarounds

If users cannot upgrade immediately:

- restrict who can configure or modify webhook URLs
- review existing webhook configurations for malformed or unusual URLs
- prefer tightly controlled outbound network policy at the deployment level
GitHub Security Advisory: GHSA-v4gp-hf5j-4566
Package: rdiffweb (PIP)
Severity: HIGH (CVSS 8.1)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 2.10.6
Patched in: 2.10.6

Summary: IKUS Rdiffweb allows an attacker with any valid or stolen access token to act as other users

Details:
IKUS Rdiffweb version 2.10.5 and below have an improper authorization flaw that allows an attacker with any valid or stolen access token to act as other users. The API does not enforce binding between the authenticated subject and the targeted user/tenant, so crafted requests can read or modify other users data and, in some cases, perform privileged actions. This issue may enable cross-tenant access. Fixed in version 2.10.6.
GitHub Security Advisory: GHSA-q9m2-fhv9-3jcf
Package: potato-annotation (PIP)
Severity: MODERATE (CVSS 5.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 2.0.0, < 2.4.5
Patched in: 2.4.5

Summary: `potato-annotation` has a Project-Boundary Bypass

Details:
## Summary
`validate_path_security` uses string-prefix containment (`startswith`) for boundary checks. This allows paths that are **outside** the intended project directory but share its prefix string (e.g., `/tmp/potato_proj_demo_evil/...` vs `/tmp/potato_proj_demo`) to be accepted.

## Details
### Affected source location (root cause)
**File:** `potato/server_utils/config_module.py`

**Snippet (lines 370–373):**
```python
real_path = os.path.realpath(normalized_path)
real_base = os.path.realpath(base_dir)
if not real_path.startswith(real_base):
    raise ConfigSecurityError(...)
```

**Snippet (lines 384–389):**
```python
real_path = os.path.realpath(normalized_path)
check_dir = project_dir if project_dir else base_dir
real_check_dir = os.path.realpath(check_dir)
if not real_path.startswith(real_check_dir):
    raise ConfigSecurityError(...)
```

`startswith()` is string-based, so `/tmp/potato_proj_demo_evil/...` passes when checked against `/tmp/potato_proj_demo`.

### Confirmed affected call sites
**File:** `potato/server_utils/config_module.py`

1) `validate_file_paths` task_dir branch (line 2113)
```python
validated_task_dir = validate_path_security(task_dir, project_dir)
```

2) `validate_file_paths` data_files branch (line 2151)
```python
validated_path = validate_path_security(file_path, base_dir, project_dir)
```

3) `validate_training_config` training.data_file branch (line 2286)
```python
validated_path = validate_path_security(data_file, base_dir, project_dir)
```

## PoC
```python
from potato.server_utils.config_module import validate_path_security

base = '/tmp/potato_proj_demo'
vuln = '/tmp/potato_proj_demo_evil/file.txt'

try:
    print('inside=', validate_path_security('/tmp/potato_proj_demo/file.txt', base, base))
except Exception as e:
    print('inside_error=', type(e).__name__, e)

try:
    validate_path_security('/tmp/other_demo/file.txt', base, base)
except Exception as e:
    print('baseline=', type(e).__name__, e)

print('trigger=', validate_path_security(vuln, base, base))
```

## Impact
- Can allow unauthorized sibling-prefix file access outside intended project boundary.
- Can affect read paths (`data_files`, `training.data_file`, `base_css`, `header_logo`) and output/path placement depending on configuration.
GitHub Security Advisory: GHSA-9f6m-65v9-x9g2
Package: MindsDB (PIP)
Severity: MODERATE (CVSS 7.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: <= 26.0.1
Patched in: unpatched

Summary: MindsDB has an Improper Access Control Issue

Details:
A weakness has been identified in MindsDB up to 26.01. This impacts the function exec of the file mindsdb/integrations/handlers/byom_handler/proc_wrapper.py of the component Engine Handler. Executing a manipulation can lead to unrestricted upload. The attack can be executed remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-39j6-4867-gg4w
Package: utcp-http (PIP)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.1.1
Patched in: 1.1.2

Summary: utcp-http vulnerable to SSRF via attacker-controlled OpenAPI servers[0].url in HTTP communication protocol

Details:
## Summary

The `utcp-http` plugin is vulnerable to a blind Server-Side Request Forgery (SSRF) caused by a trust-boundary inconsistency between manual discovery and tool invocation. `register_manual()` validates the discovery URL against an HTTPS / loopback allowlist, but `call_tool()` and `call_tool_streaming()` reuse the resolved `tool_call_template.url` directly without revalidating. An attacker who hosts a malicious OpenAPI spec on a legitimate HTTPS endpoint can declare `servers: [{ url: "http://169.254.169.254" }]` (or any internal address) in the spec; the OpenAPI converter blindly trusts that value and the tool becomes a blind SSRF primitive that exposes cloud metadata, internal services, and other firewalled-only endpoints to the LLM caller.

All three HTTP-class protocols (`utcp_http.http`, `utcp_http.streamable_http`, `utcp_http.sse`) shared the same gap, plus a separate prefix-bypass: the previous `startswith("http://localhost")` check let URLs like `http://localhost.evil.com` through.

## Impact

A remote attacker who can convince the agent (via the LLM context, prompt injection, or a tool-discovery surface) to register their HTTPS OpenAPI URL can:
- Map internal networks behind the agent.
- Read AWS/GCP IAM credentials from cloud metadata endpoints (`http://169.254.169.254`, `http://metadata.google.internal`).
- Reach unauthenticated internal services (Elasticsearch, Redis HTTP, internal admin panels).
- Have responses returned to the LLM, which combined with prompt injection enables exfiltration back to the attacker.

## Affected versions

`utcp-http <= 1.1.1`.

## Patched versions

`utcp-http 1.1.2`.

## Patch

Commit: 5b16e43 on `dev`.

- New `utcp_http._security` helper: `ensure_secure_url(url, context=...)` parses the URL with `urllib.parse.urlparse` and validates the hostname (not a string prefix) against the loopback set, closing the `localhost.evil.com` bypass.
- All three protocols call `ensure_secure_url(url, context="manual discovery")` in `register_manual` (replacing the duplicated prefix check) and `ensure_secure_url(url, context="tool invocation")` immediately before each aiohttp request in `call_tool` / `call_tool_streaming`. The runtime check is the actual SSRF fix.
- New regression tests in `test_security.py` pin the accept/reject decisions and explicitly cover the historical bypass cases.

## Workarounds

For users who cannot upgrade immediately:
- Refuse to call `register_manual` with any URL controlled by an untrusted party, even over HTTPS.
- Restrict outbound network access from the host running the agent so internal addresses (RFC1918, 169.254.0.0/16, loopback for cloud metadata) are unreachable.

## Credit

Discovered and reported by [@YLChen-007](https://github.com/YLChen-007) in #83.