Publish Advisories

GHSA-f7gq-h8jv-h3cq
GHSA-jj4j-x5ww-cwh9
GHSA-7r7f-9xpj-jmr7
GHSA-pcxq-fjp3-r752
GHSA-m959-cc7f-wv43
GHSA-xqmp-fxgv-xvq5
GHSA-f2g3-hh2r-cwgc
GHSA-gfmv-vh34-h2x5
GHSA-mcww-4hxq-hfr3

Author: advisory-database[bot]

advisories/github-reviewed/2025/06/GHSA-f7gq-h8jv-h3cq/GHSA-f7gq-h8jv-h3cq.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f7gq-h8jv-h3cq",
-  "modified": "2025-06-17T19:56:26Z",
+  "modified": "2026-04-06T23:14:59Z",
   "published": "2025-06-17T14:20:46Z",
   "aliases": [
     "CVE-2025-4754"
@@ -55,9 +55,17 @@
       "type": "WEB",
       "url": "https://github.com/team-alembic/ash_authentication_phoenix/commit/a3253fb4fc7145aeb403537af1c24d3a8d51ffb1"
     },
+    {
+      "type": "WEB",
+      "url": "https://cna.erlef.org/cves/CVE-2025-4754.html"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/team-alembic/ash_authentication_phoenix"
+    },
+    {
+      "type": "WEB",
+      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-4754"
     }
   ],
   "database_specific": {

advisories/github-reviewed/2025/09/GHSA-jj4j-x5ww-cwh9/GHSA-jj4j-x5ww-cwh9.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-jj4j-x5ww-cwh9",
-  "modified": "2025-09-15T16:28:24Z",
+  "modified": "2026-04-06T23:15:03Z",
   "published": "2025-09-15T16:28:24Z",
   "aliases": [
     "CVE-2025-48042"
@@ -55,9 +55,17 @@
       "type": "WEB",
       "url": "https://github.com/ash-project/ash/commit/5d1b6a5d00771fd468a509778637527b5218be9a"
     },
+    {
+      "type": "WEB",
+      "url": "https://cna.erlef.org/cves/CVE-2025-48042.html"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/ash-project/ash"
+    },
+    {
+      "type": "WEB",
+      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48042"
     }
   ],
   "database_specific": {

advisories/github-reviewed/2025/10/GHSA-7r7f-9xpj-jmr7/GHSA-7r7f-9xpj-jmr7.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-7r7f-9xpj-jmr7",
-  "modified": "2025-10-13T13:33:22Z",
+  "modified": "2026-04-06T23:15:07Z",
   "published": "2025-10-13T13:33:22Z",
   "aliases": [
     "CVE-2025-48043"
@@ -48,13 +48,21 @@
       "type": "WEB",
       "url": "https://github.com/ash-project/ash/commit/66d81300065b970da0d2f4528354835d2418c7ae"
     },
+    {
+      "type": "WEB",
+      "url": "https://cna.erlef.org/cves/CVE-2025-48043.html"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/ash-project/ash"
     },
     {
       "type": "WEB",
       "url": "https://github.com/ash-project/ash/releases/tag/v3.6.2"
+    },
+    {
+      "type": "WEB",
+      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48043"
     }
   ],
   "database_specific": {

advisories/github-reviewed/2025/10/GHSA-pcxq-fjp3-r752/GHSA-pcxq-fjp3-r752.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-pcxq-fjp3-r752",
-  "modified": "2025-10-17T20:07:12Z",
+  "modified": "2026-04-06T23:15:11Z",
   "published": "2025-10-17T18:03:06Z",
   "aliases": [
     "CVE-2025-48044"
@@ -55,9 +55,17 @@
       "type": "WEB",
       "url": "https://github.com/ash-project/ash/commit/8b83efa225f657bfc3656ad8ee8485f9b2de923d"
     },
+    {
+      "type": "WEB",
+      "url": "https://cna.erlef.org/cves/CVE-2025-48044.html"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/ash-project/ash"
+    },
+    {
+      "type": "WEB",
+      "url": "https://osv.dev/vulnerability/EEF-CVE-2025-48044"
     }
   ],
   "database_specific": {

advisories/github-reviewed/2026/03/GHSA-m959-cc7f-wv43/GHSA-m959-cc7f-wv43.json

@@ -1,14 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-m959-cc7f-wv43",
-  "modified": "2026-03-31T18:41:23Z",
+  "modified": "2026-04-06T23:13:00Z",
   "published": "2026-03-27T19:56:21Z",
   "aliases": [
     "CVE-2026-34073"
   ],
   "summary": "cryptography has incomplete DNS name constraint enforcement on peer names",
   "details": "## Summary\n\nIn versions of cryptography prior to 46.0.5, DNS name constraints were only validated against SANs within child certificates, and not the \"peer name\" presented during each validation. Consequently, cryptography would allow a peer named `bar.example.com` to validate against a wildcard leaf certificate for `*.example.com`, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for `bar.example.com`.\n\nThis behavior resulted from a gap between RFC 5280 (which defines Name Constraint semantics) and RFC 9525 (which defines service identity semantics): put together, neither states definitively whether Name Constraints should be applied to peer names. To close this gap, cryptography now conservatively rejects any validation where the peer name would be rejected by a name constraint if it were a SAN instead.\n\nIn practice, exploitation of this bypass requires an uncommon X.509 topology, one that the Web PKI avoids because it exhibits these kinds of problems. Consequently, we consider this a medium-to-low impact severity.\n\nSee CVE-2025-61727 for a similar bypass in Go's `crypto/x509`.\n\n## Remediation\n\nUsers should upgrade to 46.0.6 or newer. \n\n## Attribution\n\nReporter: @1seal",
   "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+    },
     {
       "type": "CVSS_V4",
       "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U"

advisories/github-reviewed/2026/03/GHSA-xqmp-fxgv-xvq5/GHSA-xqmp-fxgv-xvq5.json

@@ -1,14 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-xqmp-fxgv-xvq5",
-  "modified": "2026-03-31T18:54:53Z",
+  "modified": "2026-04-06T23:13:23Z",
   "published": "2026-03-30T13:04:03Z",
   "aliases": [
     "CVE-2026-34219"
   ],
   "summary": "libp2p-gossipsub: Remote crash via unchecked Instant overflow in heartbeat backoff expiry handling",
   "details": "## Description\n### Summary\nThe Rust libp2p Gossipsub implementation contains a remotely reachable panic in `backoff` expiry handling.  \nAfter a peer sends a crafted `PRUNE` control message with an attacker-controlled, near-maximum `backoff` value, the value is accepted and stored as an `Instant` near the representable upper bound. On a later heartbeat, the implementation performs unchecked `Instant + Duration` arithmetic (`backoff_time + slack`), which can overflow and panic with:\n`overflow when adding duration to instant`\nThis issue is reachable from any Gossipsub peer over normal `TCP + Noise + mplex/yamux` connectivity and requires no further authentication beyond becoming a protocol peer.\n### Attack Scenario\nAn attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending crafted `PRUNE` control data:\n1. Establish a standard libp2p session (`TCP + Noise`) and negotiate a stream multiplexer (`mplex`/`yamux`).\n2. Open a Gossipsub stream and send an RPC containing `ControlPrune` with a very large `backoff` (chosen near boundary conditions, e.g. `~ i64::MAX - victim_uptime_seconds`; example observed: `9223372036854674580` for ~28h uptime).\n3. The value is parsed from protobuf and passed through `Behaviour::handle_prune()` into mesh/backoff update logic.\n4. Initial storage path uses checked addition (`Instant::now().checked_add(...)`), so the malicious near-max value is retained.\n5. On the next heartbeat (typically within ~43–74s), expiry logic computes `backoff_time + slack` using unchecked addition, which overflows and panics.\n### Impact\nRemote unauthenticated denial of service (critical).  \nAny application exposing an affected `libp2p-gossipsub` listener can be crashed by a network-reachable peer that sends crafted `PRUNE` backoff values. The crash is triggered during heartbeat processing (not immediately at PRUNE parse time), and can be repeated by reconnecting and replaying the message.\n\n### Differences from CVE-2026-33040\nThis advisory is related to CVE-2026-33040 but it is not the same defect. CVE-2026-33040 addressed overflow during backoff insertion by adding checked arithmetic when converting PRUNE backoff into an Instant. The issue in this advisory occurs at a different location and at a different time: a near-maximum backoff can still be stored successfully, and the crash happens later in the heartbeat path when slack is added to that stored Instant using unchecked arithmetic.  This report covers a distinct secondary overflow path in heartbeat expiry handling that remained reachable after the original insertion-side hardening.\n\nThis vulnerability was originally reported by the Security team of the Ethereum Foundation.",
   "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H"
+    },
     {
       "type": "CVSS_V4",
       "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"

advisories/github-reviewed/2026/04/GHSA-f2g3-hh2r-cwgc/GHSA-f2g3-hh2r-cwgc.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f2g3-hh2r-cwgc",
-  "modified": "2026-04-06T17:53:40Z",
+  "modified": "2026-04-06T23:14:51Z",
   "published": "2026-04-06T17:53:40Z",
   "aliases": [
     "CVE-2026-35172"
@@ -59,6 +59,10 @@
       "type": "WEB",
       "url": "https://github.com/distribution/distribution/security/advisories/GHSA-f2g3-hh2r-cwgc"
     },
+    {
+      "type": "ADVISORY",
+      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35172"
+    },
     {
       "type": "WEB",
       "url": "https://github.com/distribution/distribution/commit/078b0783f239b4115d1a979e66f08832084e9d1d"
@@ -75,6 +79,6 @@
     "severity": "HIGH",
     "github_reviewed": true,
     "github_reviewed_at": "2026-04-06T17:53:40Z",
-    "nvd_published_at": null
+    "nvd_published_at": "2026-04-06T20:16:25Z"
   }
 }

advisories/github-reviewed/2026/04/GHSA-gfmv-vh34-h2x5/GHSA-gfmv-vh34-h2x5.json

@@ -1,14 +1,18 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-gfmv-vh34-h2x5",
-  "modified": "2026-04-03T21:42:11Z",
+  "modified": "2026-04-06T23:13:11Z",
   "published": "2026-04-03T21:42:11Z",
   "aliases": [
     "CVE-2026-33951"
   ],
   "summary": "Signal K Server: Unauthenticated Source Priorities Manipulation ",
   "details": "## Summary\n\nThe SignalK Server exposes an unauthenticated HTTP endpoint that allows remote attackers to modify navigation data source priorities. This endpoint, accessible via `PUT /signalk/v1/api/sourcePriorities`, does not enforce authentication or authorization checks and directly assigns user-controlled input to the server configuration.\n\nAs a result, attackers can influence which GPS, AIS, or other sensor data sources are trusted by the system. The changes are immediately applied and persisted to disk, allowing the manipulation to survive server restarts.\n\n### Affected Component\n- **File**: `src/serverroutes.ts`\n- **Endpoint**: `PUT /signalk/v1/api/sourcePriorities` (also accessible at `/skServer/sourcePriorities`)\n- **Lines**: 1064-1076\n- **Function**: Source priorities configuration handler\n\n### Vulnerable Code\n\n```typescript\n// src/serverroutes.ts - Lines 1064-1076\napp.put(\n  `${SERVERROUTESPREFIX}/sourcePriorities`,\n  (req: Request, res: Response) => {\n    app.config.settings.sourcePriorities = req.body\n    app.activateSourcePriorities()\n    writeSettingsFile(app, app.config.settings, (err: any) => {\n      if (err) {\n        res\n          .status(500)\n          .send('Unable to save to sourcePrefences in settings file')\n      } else {\n        res.json({ result: 'ok' })\n      }\n    })\n  }\n)\n```\n## Vulnerability Characteristics\n\n**Missing Authentication**: The endpoint has zero authentication middleware, allowing unauthenticated access from any network-adjacent attacker.\n\n**Direct Configuration Assignment**: User-supplied request body is directly assigned to app.config.settings.sourcePriorities without validation or sanitization.\n\n**Persistent Storage**: Malicious configuration is written to disk via writeSettingsFile(), ensuring changes survive server restarts.\n**Live Configuration Update**: Changes take effect immediately via activateSourcePriorities(), affecting live navigation data processing.\n\n**No Input Validation**: No JSON schema validation, type checking, or field allowlisting is performed on the request body.\n\n## Impact\n- **Navigation Data Manipulation**: Attackers can modify source priorities to change which existing, active source's data is being used",
   "severity": [
+    {
+      "type": "CVSS_V3",
+      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N"
+    },
     {
       "type": "CVSS_V4",
       "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N"

advisories/github-reviewed/2026/04/GHSA-mcww-4hxq-hfr3/GHSA-mcww-4hxq-hfr3.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-mcww-4hxq-hfr3",
-  "modified": "2026-04-04T06:14:41Z",
+  "modified": "2026-04-06T23:14:29Z",
   "published": "2026-04-04T06:14:41Z",
   "aliases": [
     "CVE-2026-30762"
   ],
   "summary": "LightRAG: Hardcoded JWT Signing Secret Allows Authentication Bypass",
-  "details": "Summary:\nThe file lightrag/api/config.py (line 397) uses a default JWT secret \"lightrag-jwt-default-secret\" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.\n\nReproduction:\n1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set\n2. Use PyJWT to sign a token: jwt.encode({\"sub\": \"admin\", \"role\": \"user\"}, \"lightrag-jwt-default-secret\", algorithm=\"HS256\")\n3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>\n4. Access is granted without valid credentials\n\nSuggested Fix:\nRequire TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.\n\n---\nVenkata Avinash Taduturi\ntaduturivenkata@gmail.com",
+  "details": "Subject: Security Vulnerability Report Hardcoded JWT Secret (CVE-2026-30762)\n\nHi HKUDS team,\n\nI'm writing to report a security vulnerability I discovered in LightRAG v1.4.10. This has been assigned CVE-2026-30762 by MITRE.\n\nVulnerability: Hardcoded JWT signing secret\nType: Improper Authentication (CWE-287)\nSeverity: High\nAttack Vector: Remote / Unauthenticated\n\nSummary:\nThe file lightrag/api/config.py (line 397) uses a default JWT secret \"lightrag-jwt-default-secret\" when the TOKEN_SECRET environment variable is not set. The AuthHandler in lightrag/api/auth.py (lines 24-25) uses this secret to sign and verify tokens. An unauthenticated attacker can forge valid JWT tokens using the publicly known default secret and gain access to any protected endpoint.\n\nReproduction:\n1. Install LightRAG v1.4.10 with AUTH_ACCOUNTS configured but no TOKEN_SECRET set\n2. Use PyJWT to sign a token: jwt.encode({\"sub\": \"admin\", \"role\": \"user\"}, \"lightrag-jwt-default-secret\", algorithm=\"HS256\")\n3. Send a request to any protected endpoint with the header: Authorization: Bearer <forged_token>\n4. Access is granted without valid credentials\n\nSuggested Fix:\nRequire TOKEN_SECRET to be explicitly set when AUTH_ACCOUNTS is configured. Refuse to start the API server if authentication is enabled but no custom secret is provided.\n\nI'm following a 90-day responsible disclosure timeline from today's date. Please let me know if you have any questions or need additional information.\n\nBest regards,\nVenkata Avinash Taduturi",
   "severity": [
     {
       "type": "CVSS_V3",