deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-564f-wx8x-878h
Package: code.vikunja.io/api (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.20.2, < 2.2.0
Patched in: 2.2.0

Summary: Vikunja read-only users can delete project background images via broken object-level authorization

Details:
## Summary

The `DELETE /api/v1/projects/:project/background` endpoint checks `CanRead` permission instead of `CanUpdate`, allowing any user with read-only access to a project to permanently delete its background image.

## Details

The `RemoveProjectBackground` handler (`pkg/modules/background/handler/background.go`) reuses `checkProjectBackgroundRights`, a helper originally written for the read-only `GetProjectBackground` endpoint. This helper only verifies `CanRead` permission. In contrast, the handler for *setting* a background (`setBackgroundPreparations`) correctly checks `CanUpdate`.

As a result, destructive write operations (deleting the background file from storage and clearing the project's `background_file_id` and `background_blur_hash` fields) are gated behind a read-only permission check.

## Impact

A user with read-only access to a project — via direct sharing, team membership, link share tokens with read permission, or read-scoped API tokens — can permanently delete the project's background image. The background file is removed from storage and cannot be recovered. This constitutes unauthorized data destruction.

## Reproduction

1. User A creates a project and sets a background image.
2. User A shares the project with User B with **read-only** permission.
3. User B sends: `DELETE /api/v1/projects/{project_id}/background` with a valid auth token.
4. The request succeeds. The background image is permanently deleted.

## References

- `pkg/modules/background/handler/background.go` — `RemoveProjectBackground` (line 416), `checkProjectBackgroundRights` (line 304), `setBackgroundPreparations` (line 106)
- `pkg/routes/routes.go` line 665 — route registration

## Credits

This vulnerability was found using [GitHub Security Lab Taskflows](https://github.com/GitHubSecurityLab/seclab-taskflows).
GitHub Security Advisory: GHSA-27qj-9gvp-8rh9
Package: github.com/elastic/beats/v7 (GO)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: < 7.0.0-alpha2.0[PII_REDACTED]3743-dec1b31111ec
Patched in: 7.0.0-alpha2.0[PII_REDACTED]3743-dec1b31111ec

Summary: Packetbeat does not properly validate an array index in multiple protocol parser components

Details:
Improper Validation of Array Index (CWE-129) in multiple protocol parser components in Packetbeat can lead Denial of Service via Input Data Manipulation (CAPEC-153). An attacker with the ability to send specially crafted, malformed network packets to a monitored network interface can trigger out-of-bounds read operations, resulting in application crashes or resource exhaustion. This requires the attacker to be positioned on the same network segment as the Packetbeat deployment or to control traffic routed to monitored interfaces.
GitHub Security Advisory: GHSA-5vrw-qjxw-89r5
Package: github.com/elastic/beats/v7 (GO)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 7.0.0-alpha2.0[PII_REDACTED]0137-de072c4e371e
Patched in: 7.0.0-alpha2.0[PII_REDACTED]0137-de072c4e371e

Summary: Metricbeat Allocates Memory with Excessive Size Value Leading to Denial of Service

Details:
Memory Allocation with Excessive Size Value (CWE-789) in the Prometheus remote_write HTTP handler in Metricbeat can lead Denial of Service via Excessive Allocation (CAPEC-130).
GitHub Security Advisory: GHSA-x6gf-mpr2-68h6
Package: github.com/jackc/pgproto3/v2 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: <= 2.3.3
Patched in: unpatched

Summary: Duplicate Advisory: pgproto3: Negative field length panics in DataRow.Decode

Details:
## Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-jqcq-xjh3-6g23. This link is maintained to preserve external references.

## Original Description
A flaw was found in pgproto3. A malicious or compromised PostgreSQL server can exploit this by sending a DataRow message with a negative field length. This input validation vulnerability can lead to a denial of service (DoS) due to a slice bounds out of range panic.
GitHub Security Advisory: GHSA-rv67-7w2g-7976
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.3.0-rc1, < 11.3.1
Patched in: 11.3.1

Summary: Mattermost fails to validate user's authentication method when processing account auth type switch

Details:
Mattermost versions 10.11.x <= 10.11.10 fail to validate user's authentication method when processing account auth type switch which allows an authenticated attacker to change account password without confirmation via falsely claiming a different auth provider.. Mattermost Advisory ID: MMSA-2026-00583
GitHub Security Advisory: GHSA-rv67-7w2g-7976
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.2.0-rc1, < 11.2.3
Patched in: 11.2.3

Summary: Mattermost fails to validate user's authentication method when processing account auth type switch

Details:
Mattermost versions 10.11.x <= 10.11.10 fail to validate user's authentication method when processing account auth type switch which allows an authenticated attacker to change account password without confirmation via falsely claiming a different auth provider.. Mattermost Advisory ID: MMSA-2026-00583
GitHub Security Advisory: GHSA-rv67-7w2g-7976
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.11.0-rc1, < 10.11.11
Patched in: 10.11.11

Summary: Mattermost fails to validate user's authentication method when processing account auth type switch

Details:
Mattermost versions 10.11.x <= 10.11.10 fail to validate user's authentication method when processing account auth type switch which allows an authenticated attacker to change account password without confirmation via falsely claiming a different auth provider.. Mattermost Advisory ID: MMSA-2026-00583
GitHub Security Advisory: GHSA-rv67-7w2g-7976
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 5.3.2-0[PII_REDACTED]4908-ced9a56e3988
Patched in: 5.3.2-0[PII_REDACTED]4908-ced9a56e3988

Summary: Mattermost fails to validate user's authentication method when processing account auth type switch

Details:
Mattermost versions 10.11.x <= 10.11.10 fail to validate user's authentication method when processing account auth type switch which allows an authenticated attacker to change account password without confirmation via falsely claiming a different auth provider.. Mattermost Advisory ID: MMSA-2026-00583
GitHub Security Advisory: GHSA-rv67-7w2g-7976
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 8.0.0[PII_REDACTED]4908-ced9a56e3988
Patched in: 8.0.0[PII_REDACTED]4908-ced9a56e3988

Summary: Mattermost fails to validate user's authentication method when processing account auth type switch

Details:
Mattermost versions 10.11.x <= 10.11.10 fail to validate user's authentication method when processing account auth type switch which allows an authenticated attacker to change account password without confirmation via falsely claiming a different auth provider.. Mattermost Advisory ID: MMSA-2026-00583
GitHub Security Advisory: GHSA-4ppj-6chv-5pgc
Package: github.com/mattermost/mattermost-plugin-msteams (GO)
Severity: HIGH (CVSS 7.6)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.15.1-0[PII_REDACTED]5339-036c761bd3cb
Patched in: 1.15.1-0[PII_REDACTED]5339-036c761bd3cb

Summary: Mattermost Microsoft Teams Plugin fails to properly mask sensitive configuration values

Details:
Mattermost Plugins versions <=2.0.3.0 fail to properly mask sensitive configuration values which allows an attacker with access to support packets to obtain original plugin settings via exported configuration data. Mattermost Advisory ID: MMSA-2026-00606
GitHub Security Advisory: GHSA-6g7g-w4f8-9c9x
Package: github.com/buger/jsonparser (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-125: Out-of-bounds Read, CWE-129: Improper Validation of Array Index
Vulnerable versions: <= 1.1.1
Patched in: 1.1.2

Summary: github.com/buger/jsonparser has a denial of service vulnerability

Details:
The Delete function fails to properly validate offsets when processing malformed JSON input. This can lead to a negative slice index and a runtime panic, allowing a denial of service attack.
GitHub Security Advisory: GHSA-hf8w-x9h5-5gf9
Package: github.com/mattermost/mattermost-plugin-boards (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: < 0.0.0[PII_REDACTED]4135-57c5be5b6ef5
Patched in: 0.0.0[PII_REDACTED]4135-57c5be5b6ef5

Summary: Mattermost Boards Plugin fails to implement authorisation checks on comment block modifications

Details:
Mattermost Plugins versions <=11.3 11.0.3 11.2.2 10.10.11.0 fail to implement authorisation checks on comment block modifications, which allows an authorised attacker with editor permission to modify comments created by other board members.  Mattermost Advisory ID: MMSA-2025-00559
GitHub Security Advisory: GHSA-3366-gw57-fcm5
Package: github.com/ellanetworks/core (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 1.6.0
Patched in: 1.6.0

Summary: Ella Core panics on malformed ULNASTransport Message without a Request Type

Details:
## Summary
Ella Core panics when processing malformed UL NAS Transport NAS messages without a Request Type.

## Impact
An attacker able to send crafted NAS messages to Ella Core can crash the process, causing service disruption for all connected subscribers. No authentication is required.

## Fix
Add a guard when receiving an UL NAS Message without a Request Type given no SM Context.
GitHub Security Advisory: GHSA-826q-wrq4-p23x
Package: github.com/ellanetworks/core (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 1.6.0
Patched in: 1.6.0

Summary: Ella Core panics on malformed NGAP Location Report

Details:
## Summary

Ella Core panics when processing a malformed NGAP LocationReport message with  `ue-presence-in-area-of-interest` event type and omitting the optional `UEPresenceInAreaOfInterestList` IE.

## Impact
An attacker able to send crafted NGAP messages to Ella Core can crash the process, causing service disruption for all connected subscribers. No authentication is required.

## Fix
Added IE presence verification to NGAP message handling.
GitHub Security Advisory: GHSA-q669-4gmv-g8mf
Package: github.com/ellanetworks/core (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: < 1.6.0
Patched in: 1.6.0

Summary: Ella Core panics on invalid PDU Session IDs in NGAP messages

Details:
## Summary

Ella Core panics when processing NGAP messages with invalid PDU Session IDs outside of 1-15.

## Impact
An attacker able to send crafted NGAP messages to Ella Core can crash the process, causing service disruption for all connected subscribers. No authentication is required.

## Fix
Added PDU Session ID validations during NGAP message handling.
GitHub Security Advisory: GHSA-89x7-5m5m-mcmm
Package: github.com/juju/juju (GO)
Severity: HIGH (CVSS 7.6)
CWE: CWE-285: Improper Authorization
Vulnerable versions: >= 0.0.0[PII_REDACTED]0135-f6a66aa91eec, < 0.0.0[PII_REDACTED]1847-d06919eb03ec
Patched in: 0.0.0[PII_REDACTED]1847-d06919eb03ec

Summary: Juju has unauthorized update of out-of-scope Vault secrets

Details:
An authorization bypass vulnerability in the Vault secrets back-end implementation of Juju versions 3.1.6 through 3.6.18 allows an authenticated unit agent to perform unauthorized updates to secret revisions. With sufficient information, an attacker can poison any existing secret revision within the scope of that Vault secret back-end.


### Impact
An authenticated unit agent can update any secret revision of a Vault back-end
that the unit's model uses. With sufficient information, an attacker can poison
any existing secret revision within the scope of that Vault secret back-end.

### Patches
3.6.19
GitHub Security Advisory: GHSA-89xv-2j6f-qhc8
Package: github.com/modelcontextprotocol/go-sdk (GO)
Severity: HIGH (CVSS 7.1)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: <= 1.4.0
Patched in: 1.4.1

Summary: Cross-Site Tool Execution for HTTP Servers without Authorizatrion in github.com/modelcontextprotocol/go-sdk

Details:
The Go SDK's Streamable HTTP transport accepted browser-generated cross-site `POST` requests without validating the `Origin` header and without requiring `Content-Type: application/json`. In deployments without Authorization, especially stateless or sessionless configurations, this allows an arbitrary website to send MCP requests to a local server and potentially trigger tool execution.

#### Impact:

A malicious website may have been able to send cross-site POST requests with `Content-Type: text/plain`, which due to CORS-safelisted properties would reach the MCP message handling without any CORS preflight barrier.

#### Fix:

The SDK was modified to perform `Content-Type` header validation for POST requests and introduced a configurable protection for verifying the origin of the request in commit a433a83. Users are advised to update to v1.4.1 to use this additional protection.

Note: v1.4.1 requires Go 1.25 or later.

#### Credits:

Thank you to Lê Minh Quân for reporting the issue.
GitHub Security Advisory: GHSA-q4r8-xm5f-56gw
Package: github.com/smallstep/certificates (GO)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-287: Improper Authentication, CWE-295: Improper Certificate Validation
Vulnerable versions: < 0.30.0
Patched in: 0.30.0

Summary: step-ca has Unauthenticated Certificate Issuance via SCEP UpdateReq (MessageType=18)

Details:
## Summary

An attacker can force a Step CA SCEP provisioner to create certificates without completing certain protocol authorization checks.

## Details

SCEP requests carry a message type. On receipt of a SCEP request, Step CA starts processing it by parsing its contents. Message types that were considered valid, but not explicitly supported in Step CA, would result in getting parsed successfully. While processing the parsed SCEP message, authorization logic would be skipped for the non-supported message types.

As a result, the request would be treated as authorized, bypassing the authorization checks normally enforced as part of the SCEP protocol and its implementation in Step CA.

Authorization webhooks and regular CA policies, such as allowed names and restrictions on certificate validity periods, remain in place.

## Mitigations

If you are unable to upgrade to v0.30.0 or newer, the attack can be mitigated by (temporarily) disabling or removing SCEP provisioners, or restricting access to SCEP provisioners to trusted clients only.

## Fix

In v0.30.0, additional validation was added to SCEP provisioners, so that they reject unsupported message types.

## Acknowledgements

This issue was identified and reported by Prasanth Sundararajan.

## Embargo List

If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.

Stay safe, and thank you for helping us keep the ecosystem secure.

If you have urgent questions, please contact [security@smallstep.com](mailto:security@smallstep.com).
GitHub Security Advisory: GHSA-q382-vc8q-7jhj
Package: github.com/modelcontextprotocol/go-sdk (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-436: Interpretation Conflict, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 1.4.0
Patched in: 1.4.1

Summary: Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk

Details:
The Go SDK recently transitioned to the `segmentio/encoding` library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with `null` Unicode characters appended at the end as equivalent to their base strings.

#### Impact

When combined with duplicate keys, the described behavior leads to a "last key wins" resolution that could override the intended MCP message. This had the potential for:
  - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.
  - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.

####  Fix:

The `segmentio/encoding` package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (`v0.5.4`). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.

#### Credits:
Thank you to Francesco Lacerenza (Doyensec) for reporting this issue.
GitHub Security Advisory: GHSA-gfgr-6hrj-85ww
Package: github.com/juju/juju (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-708: Incorrect Ownership Assignment
Vulnerable versions: >= 3.0.0, < 3.6.19
Patched in: 3.6.19

Summary: Juju affected by timing ownership claim attack on new external back-end secrets

Details:
A race condition in the secrets management subsystem of Juju versions 3.0.0 through 3.6.18 allows an authenticated unit agent to claim ownership of a newly initialized secret. Between generating a Juju Secret ID and creating the secret's first revision, an attacker authenticated as another unit agent can claim ownership of a known secret. This leads to the attacking unit being able to read the content of the initial secret revision.

### Impact
Between generating a Secret ID and creating the secret's first revision, an
attacker authenticated as another unit agent can claim ownership of a known
secret. This leads to the attacking unit being able to read the content of the
initial secret revision.

### Patches
3.6.19
GitHub Security Advisory: GHSA-g9f6-9775-hffm
Package: github.com/nhost/nhost (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-343: Predictable Value Range from Previous Values, CWE-345: Insufficient Verification of Data Authenticity, CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 0.0.0[PII_REDACTED]4820-c4bd53f042d7
Patched in: 0.0.0[PII_REDACTED]4820-c4bd53f042d7

Summary: Nhost Storage Affected by MIME Type Spoofing via Trusted Client Content-Type Header in Storage Upload

Details:
## Summary

The storage service's file upload handler trusts the client-provided `Content-Type` header without performing server-side MIME type detection. This allows an attacker to upload files with an arbitrary MIME type, bypassing any MIME-type-based restrictions configured on storage buckets.

## Affected Component

- **Service**: `services/storage`
- **File**: `services/storage/controller/upload_files.go`
- **Function**: `getMultipartFile` (lines 48-70)

## Root Cause

In `getMultipartFile`, if the client provides a non-empty `Content-Type` header that isn't `application/octet-stream`, the function returns it as-is without performing content-based detection:

```go
contentType := file.header.Header.Get("Content-Type")
if contentType != "" && contentType != "application/octet-stream" {
    return fileContent, contentType, nil // skip detection entirely
}

// mimetype.DetectReader only reached if client sends no Content-Type
// or sends application/octet-stream
mt, err := mimetype.DetectReader(fileContent)
```

## Impact

**Incorrect MIME type in file metadata.** The MIME type stored in file metadata reflects what the client claims rather than what the file actually contains. Any system consuming this metadata (browsers, CDNs, applications) may handle the file incorrectly based on the spoofed type.

## Suggested Fix

Always detect MIME type from file content using `mimetype.DetectReader`, ignoring the client-provided `Content-Type` header entirely.
GitHub Security Advisory: GHSA-vccx-p757-pv6h
Package: github.com/k1LoW/mo (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 0.18.4
Patched in: 0.18.5

Summary: mo has a XSS via inline SVG script tags in Markdown rendering

Details:
### Summary

When rendering Markdown files containing inline SVG elements with `<script>` tags, the embedded JavaScript is executed in the browser. This is due to `rehype-raw` passing raw HTML (including SVG) through to the DOM without sanitization.

### PoC

```html
<svg><script>alert(1)</script></svg>
```

Embedding the above in a Markdown file opened with mo causes the script to execute.

### Impact

Arbitrary JavaScript execution in the context of the mo application when a user opens a malicious Markdown file. This could lead to data exfiltration of other opened Markdown file contents.

### Remediation

Fixed by adding `rehype-sanitize` to the Markdown rendering pipeline, which strips dangerous elements such as `<script>` while preserving safe HTML.
GitHub Security Advisory: GHSA-5rvc-5cwx-g5x8
Package: github.com/free5gc/udm (GO)
Severity: HIGH (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 PATCH sdm-subscriptions reques

Details:
**Impact**  
This is an Improper Error Handling vulnerability with Information Exposure implications, combined with an HTTP Method Translation issue.  
- **Security Impact**: The UDM incorrectly converts a downstream 400 Bad Request (from UDR) into a 500 Internal Server Error when handling PATCH requests with an empty `supi` path parameter. Additionally, the UDM incorrectly translates the PATCH method to PUT when forwarding to UDR, indicating a deeper architectural issue. 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 PATCH request with an empty `supi` (e.g., double slashes `//` in URL path), the UDM forwards a PUT request to UDR with the malformed path, 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 PATCH operations and may indicate improper HTTP method handling.  
- **Affected Parties**: All deployments of free5GC v4.0.1 using the UDM Nudm_SDM service with PATCH 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 PATCH requests with empty path parameters before they reach UDM.