deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-p9hg-pq3q-v9gv
Package: github.com/free5gc/udm (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-158: Improper Neutralization of Null Byte or NUL Character, CWE-248: Uncaught Exception
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: free5GC UDM vulnerable to null byte injection in URL path parameters causing 500 Internal Server Error

Details:
**Impact**  
This is an Improper Input Validation vulnerability with Denial of Service and Injection implications.  
- **Security Impact**: A remote attacker can inject null bytes (URL-encoded as `%00`) into the `supi` path parameter of the UDM's Nudm_SubscriberDataManagement API. This causes URL parsing failure in Go's `net/url` package with the error "invalid control character in URL", resulting in a 500 Internal Server Error. This null byte injection vulnerability can be exploited for denial of service attacks.  
- **Functional Impact**: When the `supi` parameter contains null characters, the UDM attempts to construct a URL for UDR that includes these control characters. Go's URL parser rejects them, causing the request to fail with 500 instead of properly validating input and returning 400 Bad Request.  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the UDM Nudm_SDM service with endpoints that include path parameters (e.g., `/nudm-sdm/v2/{supi}/am-data`).

**Patches**  
Yes, the issue has been patched.  
The fix is implemented in PR free5gc/udm#79.  
Users should upgrade to the next release of free5GC that includes this commit.

**Workarounds**  
There is no direct workaround at the application level. The recommendation is to apply the provided patch or implement API gateway-level validation to reject requests containing null bytes in path parameters before they reach UDM.
GitHub Security Advisory: GHSA-3g9h-9hp4-654v
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-306: Missing Authentication for Critical Function
Vulnerable versions: <= 3.6.1
Patched in: 3.6.2

Summary: SiYuan has an Unauthenticated WebSocket DoS via Auth Keepalive Bypass

Details:
## Summary
The SiYuan kernel WebSocket server accepts unauthenticated connections when a specific “auth keepalive” query parameter is present. After connection, incoming messages are parsed using unchecked type assertions on attacker-controlled JSON.

A remote attacker can send malformed messages that trigger a runtime panic, potentially crashing the kernel process and causing denial of service.

## Details
**1. Authentication Bypass via Keepalive Query**

Unauthenticated connections are accepted if the request URI matches a specific pattern intended for an authentication page keepalive.

**File: kernel/server/serve.go**

```
if !authOk {
    authOk = strings.Contains(s.Request.RequestURI, "/ws?app=siyuan") &&
             strings.Contains(s.Request.RequestURI, "&id=auth&type=auth")
}

```

**2. Unsafe Type Assertions on Untrusted Input**

Incoming JSON messages are parsed into a generic map and fields are accessed without validation.

**File: kernel/server/serve.go**

```
cmdStr := request["cmd"].(string)
cmdId  := request["reqId"].(float64)
param  := request["param"].(map[string]interface{})

```
Malformed or missing fields trigger a runtime panic.
The handler does not implement local panic recovery, allowing crashes to propagate.

## PoC
**Step 1 — Prepare workspace directory**

```sh
mkdir -p ./workspace
```

**Step 2 — Run SiYuan container**

```
docker run -d \
  -p 6806:6806 \
  -e SIYUAN_ACCESS_AUTH_CODE_BYPASS=true \
  -v $(pwd)/workspace:/siyuan/workspace \
  b3log/siyuan \
  --workspace=/siyuan/workspace
```

Service becomes reachable at http://127.0.0.1:6806

**Step 3 — Confirm service availability**

Open in browser:

```sh
http://127.0.0.1:6806
```

**Step 4 — Connect to unauthenticated WebSocket endpoint**

```sh
ws://127.0.0.1:6806/ws?app=siyuan&id=auth&type=auth
```

This connection is accepted without credentials.

**Step 5 — Send malformed payload**

Payload:

```sh

{}

```

**Step 6 — Observe behavior**

Monitor container logs:

```sh

docker logs -f <container_id>

```
## Impact
An unauthenticated attacker with network access can repeatedly crash the kernel, causing persistent denial of service.

Impact is highest when the service is exposed beyond localhost (e.g., Docker deployments, reverse proxies, LAN access, or public hosting).
GitHub Security Advisory: GHSA-958m-gxmc-mccm
Package: github.com/free5gc/udm (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-209: Generation of Error Message Containing Sensitive Information
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: free5GC UDM incorrectly returns 500 for empty supi path parameter in DELETE sdm-subscriptions request

Details:
**Impact**  
This is an Improper Error Handling  vulnerability with Information Exposure implications.  
- **Security Impact**: The UDM incorrectly converts a downstream 400 Bad Request (from UDR) into a 500 Internal Server Error when handling DELETE requests with an empty `supi` path parameter. This leaks internal error handling behavior and makes it difficult for clients to distinguish between client-side errors and server-side failures.  
- **Functional Impact**: When a client sends a DELETE request with an empty `supi` (e.g., double slashes `//` in URL path), the UDM forwards the malformed request to UDR, which correctly returns 400. However, UDM propagates this as 500 SYSTEM_FAILURE instead of returning the appropriate 400 error to the client. This violates REST API best practices for DELETE operations.  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the UDM Nudm_SDM service with DELETE operations on sdm-subscriptions endpoint.

**Patches**  
Yes, the issue has been patched.  
The fix is implemented in PR free5gc/udm#79.  
Users should upgrade to the next release of free5GC that includes this commit.

**Workarounds**  
There is no direct workaround at the application level. The recommendation is to apply the provided patch or implement API gateway-level validation to reject DELETE requests with empty path parameters before they reach UDM.
GitHub Security Advisory: GHSA-7g27-v5wj-jr75
Package: github.com/free5gc/udm (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference, CWE-478: Missing Default Case in Multiple Condition Expression
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: free5GC UDM DataChangeNotification Procedure Panic Due to Nil Pointer Dereference

Details:
**Impact**  
This is a NULL Pointer Dereference vulnerability leading to Denial of Service.  
- **Security Impact**: A remote attacker can cause the UDM service to panic and crash by sending a crafted POST request to the `/sdm-subscriptions` endpoint with a malformed URL path containing path traversal sequences (`../`) and a large JSON payload. The `DataChangeNotificationProcedure` function in `notifier.go` attempts to access a nil pointer without proper validation, causing a complete service crash with "runtime error: invalid memory address or nil pointer dereference".  
- **Functional Impact**: The service crashes completely, requiring manual restart. All UDM functionality is disrupted until recovery.  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the UDM HTTP callback functionality.

**Patches**  
Yes, the issue has been patched.  
The fix is implemented in PR free5gc/udm#78.  
Users should upgrade to the next release of free5GC that includes this commit.

**Workarounds**  
There is no direct workaround at the application level. The recommendation is to apply the provided patch or implement API gateway-level filtering to block requests containing path traversal sequences.
GitHub Security Advisory: GHSA-4jrw-92fg-4jwx
Package: github.com/free5gc/ausf (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: free5GC AUSF UE Authentication Panic on Nil SuciSupiMap Interface Conversion

Details:
**Impact**  
This is an Improper Null Check vulnerability leading to Denial of Service.  
- **Security Impact**: A remote attacker can cause the AUSF service to panic and crash by sending a crafted UE authentication request that triggers a nil interface conversion in the `GetSupiFromSuciSupiMap` function. This results in complete denial of service for the AUSF authentication service.  
- **Functional Impact**: The `GetSupiFromSuciSupiMap` function attempts to perform an interface conversion from `interface{}` to `*context.SuciSupiMap` without checking if the underlying value is nil. When `SuciSupiMap` is nil, the code panics with "interface conversion: interface {} is nil, not *context.SuciSupiMap".  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the AUSF UE authentication service (`/nausf-auth/v1/ue-authentications` endpoint).

**Patches**  
Yes, the issue has been patched.  
The fix is implemented in PR free5gc/ausf#52 (commit: [add specific commit hash if available]).  
Users should upgrade to the next release of free5GC that includes this commit.

**Workarounds**  
There is no direct workaround at the application level. The recommendation is to apply the provided patch or restrict access to the AUSF API to trusted sources only.
GitHub Security Advisory: GHSA-7c47-xr7q-p6hg
Package: github.com/free5gc/nrf (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.4.2
Patched in: 1.4.2

Summary: free5GC NRF Discovery EncodeGroupId Function Panics on Malformed group-id-list Parameter

Details:
**Impact**  
This is an Improper Input Validation vulnerability leading to Denial of Service.  
- **Security Impact**: A remote attacker can cause the NRF service to panic and crash by sending a crafted HTTP GET request with a malformed `group-id-list` parameter. This results in complete denial of service for the NRF discovery service.  
- **Functional Impact**: The `EncodeGroupId` function attempts to access array indices [0], [1], [2] without validating the length of the split data. When the parameter contains insufficient separator characters, the code panics with "index out of range".  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the NRF discovery service.

**Patches**  
Yes, the issue has been patched.  
The fix is implemented in PR free5gc/nrf#80 (commit: [add fix reference here]).  
Users should upgrade to the next release of free5GC that includes this commit.

**Workarounds**  
There is no direct workaround at the application level. The recommendation is to apply the provided patch or restrict access to the NRF API to trusted sources only.
GitHub Security Advisory: GHSA-6g43-577r-wf4x
Package: github.com/free5gc/chf (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: < 1.2.2
Patched in: 1.2.2

Summary: Out-of-Bounds Slice Access in free5GC CHF Leading to DoS

Details:
### Impact
This is an out-of-bounds slice access vulnerability in the CHF `nchf-convergedcharging` service.
A valid authenticated request to PUT `/nchf-convergedcharging/v3/recharging/:ueId?ratingGroup=...` can trigger a server-side panic in `github.com/free5gc/chf/internal/sbi.(*Server).RechargePut(...)` due to an out-of-range slice access. In the reported runtime, Gin recovery converts the panic into HTTP 500, but the recharge path remains remotely panic-triggerable and can be abused repeatedly to degrade recharge functionality and flood logs. In deployments without equivalent recovery handling, this panic may cause more severe service disruption.

### Patches
https://github.com/free5gc/chf/pull/61

### Workarounds
- Restrict access to the `nchf-convergedcharging` recharge endpoint to strictly trusted NF callers only.
- Apply rate limiting or network ACLs in front of the CHF SBI interface to reduce repeated panic-trigger attempts.
- If the recharge API is not required, temporarily disable or block external reachability to this route.
- Ensure panic recovery, monitoring, and alerting are enabled.
GitHub Security Advisory: GHSA-g2pf-ww5m-2r9m
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]0401-d90285929ca0
Patched in: 1.80.0-v2.20.0[PII_REDACTED]0401-d90285929ca0

Summary: Zitadel is missing enforcement of organization scopes

Details:
### Summary

A vulnerability in Zitadel's OAuth2/OIDC interface, which allowed users to bypass organization enforcement during authentication.

### Impact

Zitadel allows applications to enforce an organzation context during authentication using [scopes](https://zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes) (`urn:zitadel:iam:org:id:{id}` and `urn:zitadel:iam:org:domain:primary:{domainname}`). If enforced, a user needs to be part of the required organization to sign in.

While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints.
This allowed users to bypass the restriction and sign in with users from other organizations.

Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.12.2` (including RC versions)
- **3.x**: `3.0.0` through `3.4.8` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by validating the provided scopes and enforcing the organization existence when processing the authorization request. Additionally it will prevent the use of a session of a user which does not belong to the required organization on the OIDC service endpoints ([CreateCallback](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.CreateCallback) and [Authorize or Deny Device Authorization](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.AuthorizeOrDenyDeviceAuthorization) endpoints).

4.x: Upgrade to >=[4.12.3](https://github.com/zitadel/zitadel/releases/tag/v4.12.3)
3.x: Update to >=[3.4.9](https://github.com/zitadel/zitadel/releases/tag/v3.4.9)

### Workarounds

The recommended solution is to upgrade to a patched version. 

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to @motoki317 for reporting this vulnerability.
GitHub Security Advisory: GHSA-g2pf-ww5m-2r9m
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.0.0-rc.1, < 3.4.9
Patched in: 3.4.9

Summary: Zitadel is missing enforcement of organization scopes

Details:
### Summary

A vulnerability in Zitadel's OAuth2/OIDC interface, which allowed users to bypass organization enforcement during authentication.

### Impact

Zitadel allows applications to enforce an organzation context during authentication using [scopes](https://zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes) (`urn:zitadel:iam:org:id:{id}` and `urn:zitadel:iam:org:domain:primary:{domainname}`). If enforced, a user needs to be part of the required organization to sign in.

While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints.
This allowed users to bypass the restriction and sign in with users from other organizations.

Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.12.2` (including RC versions)
- **3.x**: `3.0.0` through `3.4.8` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by validating the provided scopes and enforcing the organization existence when processing the authorization request. Additionally it will prevent the use of a session of a user which does not belong to the required organization on the OIDC service endpoints ([CreateCallback](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.CreateCallback) and [Authorize or Deny Device Authorization](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.AuthorizeOrDenyDeviceAuthorization) endpoints).

4.x: Upgrade to >=[4.12.3](https://github.com/zitadel/zitadel/releases/tag/v4.12.3)
3.x: Update to >=[3.4.9](https://github.com/zitadel/zitadel/releases/tag/v3.4.9)

### Workarounds

The recommended solution is to upgrade to a patched version. 

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to @motoki317 for reporting this vulnerability.
GitHub Security Advisory: GHSA-g2pf-ww5m-2r9m
Package: github.com/zitadel/zitadel (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 4.0.0-rc.1, <= 4.12.2
Patched in: 4.12.3

Summary: Zitadel is missing enforcement of organization scopes

Details:
### Summary

A vulnerability in Zitadel's OAuth2/OIDC interface, which allowed users to bypass organization enforcement during authentication.

### Impact

Zitadel allows applications to enforce an organzation context during authentication using [scopes](https://zitadel.com/docs/apis/openidoauth/scopes#reserved-scopes) (`urn:zitadel:iam:org:id:{id}` and `urn:zitadel:iam:org:domain:primary:{domainname}`). If enforced, a user needs to be part of the required organization to sign in.

While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints.
This allowed users to bypass the restriction and sign in with users from other organizations.

Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.12.2` (including RC versions)
- **3.x**: `3.0.0` through `3.4.8` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by validating the provided scopes and enforcing the organization existence when processing the authorization request. Additionally it will prevent the use of a session of a user which does not belong to the required organization on the OIDC service endpoints ([CreateCallback](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.CreateCallback) and [Authorize or Deny Device Authorization](https://zitadel.com/docs/reference/api/oidc/zitadel.oidc.v2.OIDCService.AuthorizeOrDenyDeviceAuthorization) endpoints).

4.x: Upgrade to >=[4.12.3](https://github.com/zitadel/zitadel/releases/tag/v4.12.3)
3.x: Update to >=[3.4.9](https://github.com/zitadel/zitadel/releases/tag/v3.4.9)

### Workarounds

The recommended solution is to upgrade to a patched version. 

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to @motoki317 for reporting this vulnerability.
GitHub Security Advisory: GHSA-xpvf-6qcc-9jqc
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.3.0-rc1, < 11.3.1
Patched in: 11.3.1

Summary: Mattermost fails to validate team-specific upload_file permissions

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to validate team-specific upload_file permissions which allows a guest user to post files in channels where they lack upload_file permission via uploading files in a team where they have permission and reusing the file metadata in a POST request to a different team. Mattermost Advisory ID: MMSA-2025-00553
GitHub Security Advisory: GHSA-xpvf-6qcc-9jqc
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.2.0-rc1, < 11.2.3
Patched in: 11.2.3

Summary: Mattermost fails to validate team-specific upload_file permissions

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to validate team-specific upload_file permissions which allows a guest user to post files in channels where they lack upload_file permission via uploading files in a team where they have permission and reusing the file metadata in a POST request to a different team. Mattermost Advisory ID: MMSA-2025-00553
GitHub Security Advisory: GHSA-xpvf-6qcc-9jqc
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.11.0-rc1, < 10.11.11
Patched in: 10.11.11

Summary: Mattermost fails to validate team-specific upload_file permissions

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to validate team-specific upload_file permissions which allows a guest user to post files in channels where they lack upload_file permission via uploading files in a team where they have permission and reusing the file metadata in a POST request to a different team. Mattermost Advisory ID: MMSA-2025-00553
GitHub Security Advisory: GHSA-xpvf-6qcc-9jqc
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 5.3.2-0[PII_REDACTED]4005-c7f6efdfb035
Patched in: 5.3.2-0[PII_REDACTED]4005-c7f6efdfb035

Summary: Mattermost fails to validate team-specific upload_file permissions

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to validate team-specific upload_file permissions which allows a guest user to post files in channels where they lack upload_file permission via uploading files in a team where they have permission and reusing the file metadata in a POST request to a different team. Mattermost Advisory ID: MMSA-2025-00553
GitHub Security Advisory: GHSA-xpvf-6qcc-9jqc
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.0.0[PII_REDACTED]4005-c7f6efdfb035
Patched in: 8.0.0[PII_REDACTED]4005-c7f6efdfb035

Summary: Mattermost fails to validate team-specific upload_file permissions

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to validate team-specific upload_file permissions which allows a guest user to post files in channels where they lack upload_file permission via uploading files in a team where they have permission and reusing the file metadata in a POST request to a different team. Mattermost Advisory ID: MMSA-2025-00553
GitHub Security Advisory: GHSA-gqv7-j2j8-qmwq
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 11.3.0-rc1, < 11.3.1
Patched in: 11.3.1

Summary: Mattermost fails to canonicalize IPv4-mapped IPv6 addresses before reserved IP validation

Details:
Mattermost versions 11.3.x <= 11.3.0, 11.2.x <= 11.2.2, 10.11.x <= 10.11.10 fail to canonicalize IPv4-mapped IPv6 addresses before reserved IP validation which allows an attacker to perform SSRF attacks against internal services via IPv4-mapped IPv6 literals (e.g., [::ffff:127.0.0.1]).. Mattermost Advisory ID: MMSA-2026-00585