deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-w5wv-wvrp-v5m5
Package: github.com/akuity/kargo (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.8.0-rc.1, < 1.8.7
Patched in: 1.8.7

Summary: Kargo's `GetConfig()` and `RefreshResource()` API endpoints allow unauthenticated access

Details:
### Impact

A bug was found with authentication checks on the `GetConfig()` API endpoint. This allowed unauthenticated users to access this endpoint by specifying an `Authorization` header with any non-empty `Bearer` token value, regardless of validity.  This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks.

Additionally, the same bug affected the `RefreshResource` endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. `RefreshResource` sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server.

This vulnerability was identified by security researchers, and there are no known reports of exploitation in the wild.

### Patches

This problem has been patched in the previous 3 versions of Kargo. Based on our information, almost all users are on one of these versions. If for some reason you cannot upgrade from an earlier version, please reach out to us.

### Workarounds

There are no workarounds for this issue, so it is highly recommended to upgrade at the earliest possible

### Additional details

This issue was caused by fallback logic in token authentication. The majority of Kargo endpoints are backed by Kubernetes objects, and for these endpoints, unrecognized token types are passed to the Kubernetes API for validation. However, the affected endpoints do not use Kubernetes or used an internal client not subject to authentication, so unrecognized tokens had no validation fallback. As a result, any request with a non-empty `Bearer` token in the `Authorization` header was incorrectly treated as authorized.
GitHub Security Advisory: GHSA-w5wv-wvrp-v5m5
Package: github.com/akuity/kargo (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.7.0-rc.1, < 1.7.7
Patched in: 1.7.7

Summary: Kargo's `GetConfig()` and `RefreshResource()` API endpoints allow unauthenticated access

Details:
### Impact

A bug was found with authentication checks on the `GetConfig()` API endpoint. This allowed unauthenticated users to access this endpoint by specifying an `Authorization` header with any non-empty `Bearer` token value, regardless of validity.  This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks.

Additionally, the same bug affected the `RefreshResource` endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. `RefreshResource` sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server.

This vulnerability was identified by security researchers, and there are no known reports of exploitation in the wild.

### Patches

This problem has been patched in the previous 3 versions of Kargo. Based on our information, almost all users are on one of these versions. If for some reason you cannot upgrade from an earlier version, please reach out to us.

### Workarounds

There are no workarounds for this issue, so it is highly recommended to upgrade at the earliest possible

### Additional details

This issue was caused by fallback logic in token authentication. The majority of Kargo endpoints are backed by Kubernetes objects, and for these endpoints, unrecognized token types are passed to the Kubernetes API for validation. However, the affected endpoints do not use Kubernetes or used an internal client not subject to authentication, so unrecognized tokens had no validation fallback. As a result, any request with a non-empty `Bearer` token in the `Authorization` header was incorrectly treated as authorized.
GitHub Security Advisory: GHSA-w5wv-wvrp-v5m5
Package: github.com/akuity/kargo (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.6.3
Patched in: 1.6.3

Summary: Kargo's `GetConfig()` and `RefreshResource()` API endpoints allow unauthenticated access

Details:
### Impact

A bug was found with authentication checks on the `GetConfig()` API endpoint. This allowed unauthenticated users to access this endpoint by specifying an `Authorization` header with any non-empty `Bearer` token value, regardless of validity.  This vulnerability did allow for exfiltration of configuration data such as endpoints for connected Argo CD clusters. This data could allow an attacker to enumerate cluster URLs and namespaces for use in subsequent attacks.

Additionally, the same bug affected the `RefreshResource` endpoint. This endpoint does not lead to any information disclosure, but could be used by an unauthenticated attacker to perform a denial-of-service style attack against the Kargo API. `RefreshResource` sets an annotation on specific Kubernetes resources to trigger reconciliations. If run on a constant loop, this could also slow down legitimate requests to the Kubernetes API server.

This vulnerability was identified by security researchers, and there are no known reports of exploitation in the wild.

### Patches

This problem has been patched in the previous 3 versions of Kargo. Based on our information, almost all users are on one of these versions. If for some reason you cannot upgrade from an earlier version, please reach out to us.

### Workarounds

There are no workarounds for this issue, so it is highly recommended to upgrade at the earliest possible

### Additional details

This issue was caused by fallback logic in token authentication. The majority of Kargo endpoints are backed by Kubernetes objects, and for these endpoints, unrecognized token types are passed to the Kubernetes API for validation. However, the affected endpoints do not use Kubernetes or used an internal client not subject to authentication, so unrecognized tokens had no validation fallback. As a result, any request with a non-empty `Bearer` token in the `Authorization` header was incorrectly treated as authorized.
GitHub Security Advisory: GHSA-25mh-hp8x-cgrv
Package: kubevirt.io/kubevirt (GO)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 1.7.0
Patched in: unpatched

Summary: KubeVirt Guest Agent DoS via Excessive Network Interface Reports

Details:
A flaw was found in KubeVirt. A user within a virtual machine (VM), if the guest agent is active, can exploit this by causing the agent to report an excessive number of network interfaces. This action can overwhelm the system's ability to store VM configuration updates, effectively blocking changes to the Virtual Machine Instance (VMI). This allows the VM user to restrict the VM administrator's ability to manage the VM, leading to a Denial of Dervice for administrative operations.
GitHub Security Advisory: GHSA-86rf-68f4-2cph
Package: github.com/go-viper/mapstructure/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-117: Improper Output Neutralization for Logs
Vulnerable versions: < 2.4.0
Patched in: 2.4.0

Summary: Duplicate Advisory: go-viper's mapstructure May Leak Sensitive Information in Logs When Processing Malformed Data

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-2464-8j7c-4cjm. This link is maintained to preserve external references.

### Original Description
A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.
GitHub Security Advisory: GHSA-j49h-6577-5xwq
Package: github.com/gmrtd/gmrtd (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.17.2
Patched in: 0.17.2

Summary: gmrtd ReadFile Vulnerable to Denial of Service via Excessive TLV Length Values

Details:
# Unbounded TLV length in ReadFile can cause Denial of Service

## Summary

A Denial of Service vulnerability was identified in `ReadFile()` where unbounded TLV length values could lead to excessive CPU and memory usage when processing data from a malicious or non-compliant NFC source. This issue has been fixed by enforcing strict limits on acceptable TLV lengths.

## Affected Versions

- **Affected:** All versions prior to **v0.17.2**
- **Fixed in:** **v0.17.2**

## Details

`ReadFile()` processes BER-TLV encoded data returned from an NFC or APDU source via a `Transceiver` interface. Prior to the fix, the implementation did not enforce an upper bound on long-form TLV length values.

A malicious or non-compliant NFC endpoint could advertise an excessively large length (up to 4 GB), causing the library to:

- Perform a very large number of read iterations  
- Allocate excessive memory  
- Consume significant CPU resources  
- Block execution for an extended period  

While such lengths are unrealistic for compliant MRTD or ISO 7816 devices, they can be produced by emulated or malicious sources, or by untrusted inputs routed through higher-level APIs.

## Impact

Applications using `gmrtd` to read data from NFC or APDU sources may experience:

- Excessive CPU usage  
- Memory exhaustion  
- Application hangs or denial of service  

No confidentiality or data integrity impact has been identified.

## Resolution

This issue has been resolved in **v0.17.2**.

The fix introduces:

- Enforcement of maximum allowable TLV lengths  
- Upper bounds on the number of read operations required to retrieve a file  
- Rejection of APDUs that exceed the requested response length  

## Recommendation

Users should **upgrade to v0.17.2 or later**.

No additional mitigation is required once the library is updated.

## Credits

Discovered and reported by **@ramrunner**.
GitHub Security Advisory: GHSA-mxxc-p822-2hx9
Package: github.com/zalando/skipper (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.24.0
Patched in: 0.24.0

Summary: Skipper Ingress Controller Allows Unauthorized Access to Internal Services via ExternalName

Details:
### Impact

When running Skipper as an Ingress controller, users with permissions to create an Ingress and a Service of type ExternalName can create routes that enable them to use Skipper's network access to reach internal services.

### Patches

https://github.com/zalando/skipper/releases/tag/v0.24.0 disables Kubernetes ExternalName by default.

### Workarounds

Developers can allow list targets of an ExternalName by using `-kubernetes-only-allowed-external-names=true` and allow list via regular expressions `-kubernetes-allowed-external-name '^[a-z][a-z0-9-.]+[.].allowed.example$'` 

### References

https://kubernetes.io/docs/concepts/services-networking/service/#externalname
GitHub Security Advisory: GHSA-qqgv-v353-cv8p
Package: github.com/go-gitea/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea does not properly validate ownership when toggling OpenID URI visibility

Details:
Gitea does not properly validate ownership when toggling OpenID URI visibility. An authenticated user may be able to change the visibility settings of other users' OpenID identities.
GitHub Security Advisory: GHSA-4xx9-vc8v-87hv
Package: github.com/go-gitea/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea does not properly validate repository ownership when linking attachments to releases

Details:
Gitea does not properly validate repository ownership when linking attachments to releases. An attachment uploaded to a private repository could potentially be linked to a release in a different public repository, making it accessible to unauthorized users.
GitHub Security Advisory: GHSA-393c-qgvj-3xph
Package: github.com/go-gitea/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea does not properly validate repository ownership when deleting Git LFS locks

Details:
Gitea does not properly validate repository ownership when deleting Git LFS locks. A user with write access to one repository may be able to delete LFS locks belonging to other repositories.
GitHub Security Advisory: GHSA-9cgq-wp42-4rpq
Package: github.com/go-gitea/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface

Details:
Gitea does not properly verify authorization when canceling scheduled auto-merges via the web interface. A user with read access to pull requests may be able to cancel auto-merges scheduled by other users.
GitHub Security Advisory: GHSA-rw22-5hhq-pfpf
Package: github.com/go-gitea/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea does not properly validate project ownership in organization project operations

Details:
Gitea does not properly validate project ownership in organization project operations. A user with project write access in one organization may be able to modify projects belonging to a different organization.
GitHub Security Advisory: GHSA-j8xr-c56q-m8jj
Package: github.com/go-gitea/gitea (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea improperly exposes issue titles and repository names through previously started stopwatches

Details:
Gitea's stopwatch API does not re-validate repository access permissions. After a user's access to a private repository is revoked, they may still view issue titles and repository names through previously started stopwatches.
GitHub Security Advisory: GHSA-2vgv-hgv4-22mh
Package: github.com/go-gitea/gitea (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea improperly exposes issue and pull request titles

Details:
Gitea's notification API does not re-validate repository access permissions when returning notification details. After a user's access to a private repository is revoked, they may still view issue and pull request titles through previously received notifications.
GitHub Security Advisory: GHSA-hgr3-x44x-33hx
Package: code.gitea.io/gitea (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea has improper access control for uploaded attachments

Details:
Gitea does not properly verify repository context when deleting attachments. A user who previously uploaded an attachment to a repository may be able to delete it after losing access to that repository by making the request through a different repository they can access.
GitHub Security Advisory: GHSA-8fwc-qjw5-rvgp
Package: code.gitea.io/gitea (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 1.25.4
Patched in: 1.25.4

Summary: Gitea may send release notification emails for private repositories to users whose access has been revoked

Details:
Gitea may send release notification emails for private repositories to users whose access has been revoked. When a repository is changed from public to private, users who previously watched the repository may continue to receive release notifications, potentially disclosing release titles, tags, and content.
GitHub Security Advisory: GHSA-c32p-wcqj-j677
Package: github.com/cometbft/cometbft (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: <= 0.37.17
Patched in: 0.37.18

Summary: CometBFT has inconsistencies between how commit signatures are verified and how block time is derived

Details:
# CSA-2026-001: Tachyon

## Description

**Name:** CSA-2026-001: Tachyon

**Criticality:** Critical (Catastrophic Impact; Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))

**Affected versions:** All versions of CometBFT

**Affected users:** Validators and protocols relying on block timestamps

## Description

A consensus-level vulnerability was discovered in CometBFT's "BFT Time" implementation due to an inconsistency between how commit signatures are verified and how block time is derived.

This breaks a core BFT Time guarantee: "A faulty process cannot arbitrarily increase the Time value."

## Impact

Downstream impact on chains affects any module, smart contract, or system that relies on the block timestamp.

## Patches

The new CometBFT releases [v0.38.21](https://github.com/cometbft/cometbft/releases/tag/v0.38.21) and [v0.37.18](https://github.com/cometbft/cometbft/releases/tag/v0.37.18) fix this issue. The `main` unreleased branch is also patched.

## Workarounds

There are no effective workarounds for this vulnerability. Upgrading to patched versions is required.

## Timeline

- January 8, 2026, 5:27PM UTC: Issue reported to Cosmos Bug Bounty Program
- January 9, 2026, 4:55AM UTC: Issue triaged and validated by core team
- January 12, 2026, 10:25PM UTC: Core team completes patch for the issue
- January 13, 2026 4:41PM UTC: Pre-notification delivered to ecosystem partners
- January 23, 2026, 3:00PM UTC: Patch made available

## Credits

This issue was reported to the Cosmos Bug Bounty Program on HackerOne. Credit to SEAL 911 and [QED Audit](https://x.com/QED_Audit) for the discovery and help with the patch.

If you believe you have found a bug in the Cosmos Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.

If you have questions about Cosmos security efforts, please reach out to our official communication channel at security@cosmoslabs.io.

A Github Security Advisory for this issue is available in the CometBFT repository. For more information about CometBFT, see https://docs.cometbft.com/.
GitHub Security Advisory: GHSA-c32p-wcqj-j677
Package: github.com/cometbft/cometbft (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: >= 0.38.0-alpha.1, <= 0.38.20
Patched in: 0.38.21

Summary: CometBFT has inconsistencies between how commit signatures are verified and how block time is derived

Details:
# CSA-2026-001: Tachyon

## Description

**Name:** CSA-2026-001: Tachyon

**Criticality:** Critical (Catastrophic Impact; Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))

**Affected versions:** All versions of CometBFT

**Affected users:** Validators and protocols relying on block timestamps

## Description

A consensus-level vulnerability was discovered in CometBFT's "BFT Time" implementation due to an inconsistency between how commit signatures are verified and how block time is derived.

This breaks a core BFT Time guarantee: "A faulty process cannot arbitrarily increase the Time value."

## Impact

Downstream impact on chains affects any module, smart contract, or system that relies on the block timestamp.

## Patches

The new CometBFT releases [v0.38.21](https://github.com/cometbft/cometbft/releases/tag/v0.38.21) and [v0.37.18](https://github.com/cometbft/cometbft/releases/tag/v0.37.18) fix this issue. The `main` unreleased branch is also patched.

## Workarounds

There are no effective workarounds for this vulnerability. Upgrading to patched versions is required.

## Timeline

- January 8, 2026, 5:27PM UTC: Issue reported to Cosmos Bug Bounty Program
- January 9, 2026, 4:55AM UTC: Issue triaged and validated by core team
- January 12, 2026, 10:25PM UTC: Core team completes patch for the issue
- January 13, 2026 4:41PM UTC: Pre-notification delivered to ecosystem partners
- January 23, 2026, 3:00PM UTC: Patch made available

## Credits

This issue was reported to the Cosmos Bug Bounty Program on HackerOne. Credit to SEAL 911 and [QED Audit](https://x.com/QED_Audit) for the discovery and help with the patch.

If you believe you have found a bug in the Cosmos Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.

If you have questions about Cosmos security efforts, please reach out to our official communication channel at security@cosmoslabs.io.

A Github Security Advisory for this issue is available in the CometBFT repository. For more information about CometBFT, see https://docs.cometbft.com/.
GitHub Security Advisory: GHSA-w2gr-585j-r428
Package: github.com/elastic/beats/v7 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: >= 9.2.0, < 9.2.4
Patched in: 9.2.4

Summary: Metricbeat affected by multiple denial of service vulnerabilities

Details:
Improper Validation of Array Index (CWE-129) exists in Metricbeat can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed payloads sent to the Graphite server metricset or Zookeeper server metricset. Additionally, Improper Input Validation (CWE-20) exists in the Prometheus helper module that can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed metric data.
GitHub Security Advisory: GHSA-w2gr-585j-r428
Package: github.com/elastic/beats/v7 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: >= 9.0.0, < 9.1.10
Patched in: 9.1.10

Summary: Metricbeat affected by multiple denial of service vulnerabilities

Details:
Improper Validation of Array Index (CWE-129) exists in Metricbeat can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed payloads sent to the Graphite server metricset or Zookeeper server metricset. Additionally, Improper Input Validation (CWE-20) exists in the Prometheus helper module that can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed metric data.
GitHub Security Advisory: GHSA-w2gr-585j-r428
Package: github.com/elastic/beats/v7 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-129: Improper Validation of Array Index
Vulnerable versions: >= 8.0.0, < 8.19.10
Patched in: 8.19.10

Summary: Metricbeat affected by multiple denial of service vulnerabilities

Details:
Improper Validation of Array Index (CWE-129) exists in Metricbeat can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed payloads sent to the Graphite server metricset or Zookeeper server metricset. Additionally, Improper Input Validation (CWE-20) exists in the Prometheus helper module that can allow an attacker to cause a Denial of Service through Input Data Manipulation (CAPEC-153) via specially crafted, malformed metric data.