deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-rhf7-wvw3-vjvm
Package: github.com/patrickhener/goshs/v2 (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 2.0.2
Patched in: 2.0.2

Summary: goshs has Cross-Origin Arbitrary File Write via Missing CSRF on PUT and Wildcard CORS

Details:
### Summary
The PUT upload handler (`httpserver/updown.go`) lacks the CSRF token validation that was added to the POST upload handler during the GHSA-jrq5-hg6x-j6g3 fix. Combined with the unconditional `Access-Control-Allow-Origin: *` on the OPTIONS preflight handler (`httpserver/server.go`), any website can write arbitrary files to a goshs instance through the victim's browser — bypassing network isolation (e.g. localhost, internal network).

### Details
**Root Cause 1 — Missing CSRF on PUT** (`httpserver/updown.go:19`)

When GHSA-jrq5-hg6x-j6g3 was fixed (commit `e3c3d37`), `checkCSRF()` was added to the POST `upload()` function (line 78) but not to the PUT `put()` function directly above it in the same file. This means PUT requests are accepted without any CSRF token.

```go
// POST — protected 
func (fs *FileServer) upload(w http.ResponseWriter, req *http.Request) {
    if !fs.checkCSRF(w, req) { return }
    // ...
}

// PUT — unprotected 
func (fs *FileServer) put(w http.ResponseWriter, req *http.Request) {
    // No checkCSRF call
    // ...
}
```

**Root Cause 2 — Wildcard CORS** (`httpserver/server.go:126`)

The OPTIONS handler unconditionally returns permissive CORS headers:

```go
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Methods", "POST, PUT, OPTIONS")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type, Authorization")
```

This allows any website's JavaScript to pass the browser's CORS preflight check and send PUT requests to the goshs server.

### PoC
[poc.zip](https://github.com/user-attachments/files/26828829/poc.zip)

Please extract the uploaded compressed file before proceeding

1. bash poc.sh
<img width="543" height="376" alt="스크린샷 2026-04-17 오후 11 08 13" src="https://github.com/user-attachments/assets/a695cbc8-133e-4e80-a2f5-9fe9fd36b569" />




### Impact
- Arbitrary file write to the goshs webroot from any website the victim visits
- File overwrite — existing files can be silently replaced
GitHub Security Advisory: GHSA-2hp7-65r3-wv54
Package: github.com/orneryd/nornicdb (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-1392: Use of Default Credentials
Vulnerable versions: < 1.0.42-hotfix
Patched in: 1.0.42-hotfix

Summary: NornicDB has Improper Network Binding in its Bolt Server, allowing unauthorized remote access

Details:
## Summary

The `--address` CLI flag (and `NORNICDB_ADDRESS` / `server.host` config key) is plumbed through to the HTTP server correctly but **never reaches the Bolt server config**. The Bolt listener therefore always binds to the wildcard address (all interfaces), regardless of what the user configures.

On a LAN, this exposes the graph database — with its default `admin:password` credentials — to any device sharing the network.

## Version

- `nornicdb v1.0.39`
- Built from commit `afe7c9d` on `main`
- Platform: macOS (darwin 25.4.0, arm64)

## Reproduction

```
$ nornicdb serve --address 127.0.0.1 --bolt-port 7687 --http-port 7474 ...
```

Output claims Bolt is on localhost:
```
Bolt server listening on bolt://localhost:7687
```

But the actual socket:
```
$ netstat -an -p tcp | grep 7687
tcp46      0      0  *.7687                 *.*                    LISTEN

$ lsof -iTCP:7687 -sTCP:LISTEN -n -P
nornicdb ... IPv6 ... TCP *:7687 (LISTEN)
```

HTTP port is correctly bound:
```
tcp4  127.0.0.1.7474   *.*  LISTEN
```

Reachable from another host on the LAN:
```
$ nc -z 192.168.x.y 7687
Connection to 192.168.x.y port 7687 [tcp/*] succeeded!
```

Setting `NORNICDB_BOLT_ADDRESS=127.0.0.1` or `server.host: "127.0.0.1"` in `config.yaml` has **no effect** on the Bolt listener.

## Root Cause

In `pkg/bolt/server.go:774-776`:

```go
func (s *Server) ListenAndServe() error {
    addr := fmt.Sprintf(":%d", s.config.Port)
    listener, err := net.Listen("tcp", addr)
    ...
}
```

`bolt.Config` (line 474) has no `Host`/`Address`/`Addr` field — only `Port`. The CLI flag `--address` is stored in a local variable in `cmd/nornicdb/main.go:80` and used to format user-facing log output (line 637–644), but is never copied into `boltConfig` at line 600–609 when Bolt is initialized.

Since `ListenAndServe` calls `net.Listen("tcp", ":7687")` with an empty host, Go binds the wildcard socket on all interfaces.

## Suggested Fix

1. Add a `Host string` field to `bolt.Config` (default `"127.0.0.1"`, matching the CLI flag default).
2. In `cmd/nornicdb/main.go` around line 601, wire it through:
   ```go
   boltConfig.Host = address
   boltConfig.Port = boltPort
   ```
3. In `pkg/bolt/server.go:775`, use the host:
   ```go
   addr := net.JoinHostPort(s.config.Host, strconv.Itoa(s.config.Port))
   ```

## Security Impact

- Default `admin:password` credentials + wildcard binding = anyone on the same WiFi can issue arbitrary Cypher queries (read, write, delete nodes) against NornicDB instances running with default setup.
- Users following the README will reasonably assume `--address 127.0.0.1` (the documented default) binds *both* protocols to localhost.
- Workaround: host-firewall rules (e.g. macOS `pf`) blocking non-loopback → 7687. Not discoverable from the docs.
GitHub Security Advisory: GHSA-hjh7-r5w8-5872
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: < 3.6.5
Patched in: 3.6.5

Summary: SiYuan: Path Traversal via Double URL Encoding in `/export/` Endpoint (Incomplete Fix Bypass for CVE-2026-30869)

Details:
### Summary
The fix for CVE-2026-30869 in SiYuan v3.5.10 only added a denylist check (`IsSensitivePath`) but did not address the root cause — a redundant `url.PathUnescape()` call in `serveExport()`. An authenticated attacker can use double URL encoding (`%252e%252e`) to traverse directories and read arbitrary workspace files including the full SQLite database (`siyuan.db`), kernel log, and all user documents.

### Details
In `kernel/server/serve.go`, the `serveExport()` function (line 314-320) processes file paths as follows:

```go
filePath := strings.TrimPrefix(c.Request.URL.Path, "/export/")
decodedPath, err := url.PathUnescape(filePath)     // second decode
fullPath := filepath.Join(exportBaseDir, decodedPath)
```

Go's HTTP server already decodes percent-encoded characters once during request parsing. The additional `url.PathUnescape()` call creates a double-decode vulnerability:

1. Attacker sends: `GET /export/%252e%252e/siyuan.db`
2. Go HTTP decodes `%25` → `%`, result: `URL.Path = /export/%2e%2e/siyuan.db`
3. Go's path cleaner sees `%2e%2e` as literal characters (not `..`), no redirect occurs
4. `url.PathUnescape("%2e%2e")` decodes to `..`
5. `filepath.Join(exportBaseDir, "../siyuan.db")` resolves to `<workspace>/temp/siyuan.db`

The CVE-2026-30869 fix added `IsSensitivePath()` which blocks `<workspace>/conf/` and OS-level paths (`/etc`, `/root`, etc.). However, it does NOT block:
- `<workspace>/temp/siyuan.db` — full document database
- `<workspace>/temp/blocktree.db` — block tree database
- `<workspace>/temp/siyuan.log` — kernel log
- `<workspace>/temp/asset_content.db` — asset content database

Note: the `/appearance/` handler in the same file correctly uses `gulu.File.IsSubPath()` to validate paths (line 447), but this check is missing from the `/export/` handler.

### PoC
[poc.zip](https://github.com/user-attachments/files/26866234/poc.zip)
Please extract the uploaded compressed file before proceeding

1. docker compose up -d --build
2. sh poc.sh

<img width="550" height="184" alt="스크린샷 2026-04-19 오후 5 08 30" src="https://github.com/user-attachments/assets/6aea4334-0b5a-4f45-bd1f-ecfad61ba524" />




### Impact
- Data exfiltration: An authenticated user (including low-privilege Publish/Reader users via the Publish service) can download the entire SQLite document database containing all blocks, documents, attributes, and full-text search indexes.
- Information disclosure: Kernel log (`siyuan.log`) leaks internal server paths, versions, configuration details, and error messages.
GitHub Security Advisory: GHSA-j88v-2chj-qfwx
Package: github.com/jackc/pgx (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 3.6.2
Patched in: unpatched

Summary: pgx: SQL Injection via placeholder confusion with dollar quoted string literals

Details:
### Impact

SQL Injection can occur when:

1. The non-default simple protocol is used.
2. A dollar quoted string literal is used in the SQL query.
3. That string literal contains text that would be would be interpreted as a placeholder outside of a string literal.
4. The value of that placeholder is controllable by the attacker.

e.g.

```go
attackValue := `$tag$; drop table canary; --`
_, err = tx.Exec(ctx, `select $tag$ $1 $tag$, $1`, pgx.QueryExecModeSimpleProtocol, attackValue)
```

This is unlikely to occur outside of a contrived scenario.

### Patches

The problem is resolved in v5.9.2.

### Workarounds

Do not use the simple protocol to execute queries matching all the above conditions.
GitHub Security Advisory: GHSA-j88v-2chj-qfwx
Package: github.com/jackc/pgx/v4 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: <= 4.18.3
Patched in: unpatched

Summary: pgx: SQL Injection via placeholder confusion with dollar quoted string literals

Details:
### Impact

SQL Injection can occur when:

1. The non-default simple protocol is used.
2. A dollar quoted string literal is used in the SQL query.
3. That string literal contains text that would be would be interpreted as a placeholder outside of a string literal.
4. The value of that placeholder is controllable by the attacker.

e.g.

```go
attackValue := `$tag$; drop table canary; --`
_, err = tx.Exec(ctx, `select $tag$ $1 $tag$, $1`, pgx.QueryExecModeSimpleProtocol, attackValue)
```

This is unlikely to occur outside of a contrived scenario.

### Patches

The problem is resolved in v5.9.2.

### Workarounds

Do not use the simple protocol to execute queries matching all the above conditions.
GitHub Security Advisory: GHSA-j88v-2chj-qfwx
Package: github.com/jackc/pgx/v5 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 5.9.2
Patched in: 5.9.2

Summary: pgx: SQL Injection via placeholder confusion with dollar quoted string literals

Details:
### Impact

SQL Injection can occur when:

1. The non-default simple protocol is used.
2. A dollar quoted string literal is used in the SQL query.
3. That string literal contains text that would be would be interpreted as a placeholder outside of a string literal.
4. The value of that placeholder is controllable by the attacker.

e.g.

```go
attackValue := `$tag$; drop table canary; --`
_, err = tx.Exec(ctx, `select $tag$ $1 $tag$, $1`, pgx.QueryExecModeSimpleProtocol, attackValue)
```

This is unlikely to occur outside of a contrived scenario.

### Patches

The problem is resolved in v5.9.2.

### Workarounds

Do not use the simple protocol to execute queries matching all the above conditions.
GitHub Security Advisory: GHSA-3m6q-h5gj-7mrw
Package: code.gitea.io/gitea (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: < 1.25.0
Patched in: 1.25.0

Summary: Gitea has insecure default SSH settings

Details:
## Summary

The built-in SSH server currently advertises a number of key exchange, MAC, and host key algorithms that are considered weak or broken. The defaults should be tightened so a fresh installation passes a baseline SSH security audit out of the box.

## Details

Running `ssh-audit` against a default deployment flags the following as `fail`:

- **Key exchange**
  - `ecdh-sha2-nistp256`
  - `ecdh-sha2-nistp384`
  - `ecdh-sha2-nistp521`
- **MAC**
  - `hmac-sha1`
- **Host key**
  - `ssh-rsa`

## Reproduction

```sh
docker run -it --rm positronsecurity/ssh-audit -p 2222 gitea.local
```

## Impact

Default deployments expose algorithms that are known-weak or deprecated upstream. The current workaround requires manually setting several `GITEA__server__SSH_SERVER_*` variables, which most users will never do.

### Workaround

```ini
[server]
SSH_SERVER_KEY_EXCHANGES = curve25519-sha256, diffie-hellman-group14-sha256
SSH_SERVER_CIPHERS       = chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com
SSH_SERVER_MACS          = hmac-sha2-256-etm@openssh.com, hmac-sha2-256
```

There is no exposed option to restrict host key algorithms, so `ssh-rsa` remains advertised.

## Acceptance criteria

- [ ] Default `SSH_SERVER_KEY_EXCHANGES`, `SSH_SERVER_CIPHERS`, and `SSH_SERVER_MACS` updated to the secure list above.
- [ ] New `SSH_SERVER_HOST_KEY_ALGORITHMS` option added, with a default that excludes `ssh-rsa`.
- [ ] Documentation updated to reflect the new defaults.
- [ ] `ssh-audit` against a fresh install reports no `[fail]` entries.
GitHub Security Advisory: GHSA-29rg-wmcw-hpf4
Package: github.com/projectdiscovery/nuclei/v3 (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-284: Improper Access Control
Vulnerable versions: >= 3.0.0, < 3.8.0
Patched in: 3.8.0

Summary: Nuclei: Local File Read via require() Module Loader Bypass

Details:
A vulnerability in Nuclei's JavaScript protocol runtime allows JavaScript templates to read local `.js` and `.json` files through the `require()` function, bypassing the default local file access restriction.

**Affected Component**

The issue is in the JavaScript runtime's module loading system. The goja `require()` function used a default host filesystem loader without routing through the `allow-local-file-access` check.

**Description**

The goja require() function in Nuclei's JavaScript protocol runtime used the default host filesystem loader, which allowed JavaScript templates to import .js and .json files from anywhere on the host filesystem, ignoring the allow-local-file-access (-lfa) option that controls file access outside the template directory.

The impact is limited to `.js` and `.json` files, as goja's module loader only resolves those extensions. That said, this is still enough to expose sensitive data stored in JSON configuration files like `package.json`, credential stores, or cloud configuration files sitting on the host filesystem.

**Affected Users**

- **CLI users** running untrusted or third-party JavaScript templates.
- **SDK users** who have integrated Nuclei into platforms where end-users can supply JavaScript templates, especially when relying on the default file access restriction to limit filesystem reads.

> [!NOTE]
The `require()` module loader only resolves `.js` and `.json` files. Other file types cannot be read through this vector.

**Patches**

- The vulnerability is fixed in Nuclei v3.8.0. Upgrading is strongly recommended. 
- Fix reference: #7332

**Mitigation**

Upgrade to Nuclei v3.8.0, where the `require()` registry is rebuilt per execution and file-backed module loads are routed through the same `allow-local-file-access` check as the rest of the filesystem operations.

In the meantime, avoid running JavaScript templates from unverified sources.

**Workarounds**

If upgrading is not an option, avoid running untrusted JavaScript templates entirely. There is no flag or configuration that mitigates this on affected versions.

**Acknowledgments**

Nuceli thanks @AkashHamal0x01 for reporting this issue through responsible disclosure via security@projectdiscovery.io
GitHub Security Advisory: GHSA-57j5-qwp2-vqp6
Package: github.com/openfga/openfga (GO)
Severity: MODERATE (CVSS 5.0)
CWE: CWE-706: Use of Incorrectly-Resolved Name or Reference, CWE-863: Incorrect Authorization
Vulnerable versions: < 1.14.1
Patched in: 1.14.1

Summary: OpenFGA has Improper Policy Enforcement

Details:
### Description
In OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.

### Am I Affected?
Users are affected if their applications meet the following preconditions:

* The model has relations which rely on condition evaluation.
* Caching is enabled.

### Fix
Upgrade to OpenFGA v1.14.1.

### Acknowledgement
OpenFGA would like to thank @bugbunny-research for the detailed report.
GitHub Security Advisory: GHSA-rw2c-8rfq-gwfv
Package: github.com/daptin/daptin (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.11.4
Patched in: 0.11.4

Summary: Daptin: SQL injection via unvalidated goqu.L() calls in aggregate API

Details:
## Summary

The `/aggregate/:typename` endpoint accepted `column` and `group` query parameters that were passed verbatim to `goqu.L()` — a raw SQL literal expression builder — without any validation. This bypassed all parameterization and allowed authenticated users with any valid session to inject arbitrary SQL expressions.

## Impact

An authenticated low-privilege user could:
- Extract data from any table via subquery: `(SELECT group_concat(email) FROM user_account) as leak`
- Disclose database internals: `sqlite_version()`, `(SELECT sql FROM sqlite_master)`
- Exfiltrate cross-table data via correlated subqueries

The vulnerability was confirmed locally; `user_account.email` values were extracted via a crafted `column` parameter by a non-admin user.

## Root Cause

`goqu.L(userInput)` in `server/resource/resource_aggregate.go` inserted user-supplied query parameters directly into the SQL string with no validation.

## Fix (v0.11.4)

All `goqu.L()` calls on user-controlled input were eliminated and replaced with:
- Structural expression parsing supporting all documented API forms
- Schema-based column validation (column names checked against entity schema via `TableInfo().GetColumnByName()`)
- Exact-match allowlist for aggregate functions (`count`, `sum`, `avg`, `min`, `max`, `first`, `last`) and scalar functions (`date`, `strftime`, `upper`, `lower`, etc.)
- Safe goqu constructors (`goqu.I()`, `goqu.SUM()`, `goqu.Func()`) for all generated expressions
- `allowedTables` scope enforcement: qualified column refs (`table.col`) validated against root entity + explicitly joined tables only

Two additional DoS bugs were fixed in the same commit: `uuid.MustParse` panic on malformed UUID input and an index-out-of-range panic in `ToOrderedExpressionArray` on empty sort expressions.

## Credits

Reported by @VashuVats.
GitHub Security Advisory: GHSA-rx35-6rhx-7858
Package: github.com/tektoncd/pipeline (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 1.11.0
Patched in: 1.11.1

Summary: Tekton Pipelines: VolumeMount path restriction bypass via missing filepath.Clean in /tekton/ check

Details:
## Summary

A validation bypass in the VolumeMount path restriction allows mounting volumes under restricted `/tekton/` internal paths by using `..` path traversal components. The restriction check uses `strings.HasPrefix` without `filepath.Clean`, so a path like `/tekton/home/../results` passes validation but resolves to `/tekton/results` at runtime.

## Details

Tekton Pipelines restricts VolumeMount paths under `/tekton/` (except `/tekton/home`) to prevent users from interfering with internal execution state. The validation at `pkg/apis/pipeline/v1/container_validation.go` checks mount paths using `strings.HasPrefix` without normalizing the path first:

```go
if strings.HasPrefix(vm.MountPath, "/tekton/") &&
    !strings.HasPrefix(vm.MountPath, "/tekton/home") {
    // reject
}
```

Because `/tekton/home` is an allowed prefix, a path like `/tekton/home/../results` passes both checks. At runtime, the container runtime resolves `..` and the actual mount point becomes `/tekton/results`.

The same pattern exists in `pkg/apis/pipeline/v1beta1/task_validation.go`.

## Impact

An authenticated user with Task or TaskRun creation permissions can mount volumes over internal Tekton paths, potentially:

- Writing fake task results that downstream pipelines trust
- Reading or modifying step scripts before execution
- Interfering with entrypoint coordination state

## Patches

A patch is available at [v1.11.1](https://github.com/tektoncd/pipeline/releases/tag/v1.11.1).

## Workarounds

- Use admission controllers (OPA/Gatekeeper, Kyverno) to validate that VolumeMount paths do not contain `..` components.
- In multi-tenant setups, restrict who can create Task and TaskRun resources via RBAC.

## Affected Versions

All versions through **v1.11.0** (both `v1` and `v1beta1` APIs).

## Acknowledgments

This vulnerability was reported by [@kodareef5](https://github.com/kodareef5).
GitHub Security Advisory: GHSA-p49j-v9wc-wg57
Package: github.com/openbao/openbao (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-1259: Improper Restriction of Security Token Assignment
Vulnerable versions: < 0.0.0[PII_REDACTED]2526-f58111d2ca54
Patched in: 0.0.0[PII_REDACTED]2526-f58111d2ca54

Summary: OpenBao's Token Store Allows Cross-Namespace Renewal, Revocation

Details:
### Impact

OpenBao's namespaces provide multi-tenant separation. A tenant who leaks token accessors can have their token revoked or renewed by a privileged administrator in another tenant.

### Patches

This was addressed in v2.5.3.
GitHub Security Advisory: GHSA-6vgr-cp5c-ffx3
Package: github.com/openbao/openbao (GO)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 0.0.0[PII_REDACTED]5735-b596b0882620
Patched in: 0.0.0[PII_REDACTED]5735-b596b0882620

Summary: OpenBao's SQL Injection in PostgreSQL database secrets engine

Details:
### Impact

When OpenBao revoked privileges on a role in the PostgreSQL database secrets engine, OpenBao failed to use proper database quoting on schema names provided by PostgreSQL. This could lead to role revocation failures, or more rarely, SQL injection as the management user.

This vulnerability was originally from HashiCorp Vault.

### Patches

This was addressed in v2.5.3.

### Workarounds

Audit table schemas and ensure database users cannot create new schemas and grant privileges on them.