Publish Advisories

GHSA-2j26-frm8-cmj9
GHSA-jx93-g359-86wm
GHSA-rgq9-fqf5-fv58
GHSA-393c-p46r-7c95
GHSA-mvv8-v4jj-g47j

Author: advisory-database[bot]

advisories/github-reviewed/2026/03/GHSA-2j26-frm8-cmj9/GHSA-2j26-frm8-cmj9.json

@@ -1,13 +1,13 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-2j26-frm8-cmj9",
-  "modified": "2026-03-25T20:36:15Z",
+  "modified": "2026-04-07T22:12:32Z",
   "published": "2026-03-23T21:15:16Z",
   "aliases": [
     "CVE-2026-33176"
   ],
   "summary": "Rails Active Support has a possible DoS vulnerability in its number helpers",
-  "details": "### Impact\nActive Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which when converted to a string could be expanded into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability.\n\n### Releases\nThe fixed releases are available at the normal locations.",
+  "details": "### Impact\nActive Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which when converted to a string could be expanded into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability.\n\n### Releases\nThe fixed releases are available at the normal locations.\n\n### Credit\n\nhttps://hackerone.com/manun",
   "severity": [
     {
       "type": "CVSS_V4",

advisories/github-reviewed/2026/03/GHSA-jx93-g359-86wm/GHSA-jx93-g359-86wm.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-jx93-g359-86wm",
-  "modified": "2026-03-12T17:38:54Z",
+  "modified": "2026-04-07T22:12:43Z",
   "published": "2026-03-12T12:30:29Z",
   "aliases": [
     "CVE-2026-3060"
@@ -40,6 +40,10 @@
       "type": "ADVISORY",
       "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3060"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/sgl-project/sglang/pull/20904"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/sgl-project/sglang"
@@ -48,6 +52,10 @@
       "type": "WEB",
       "url": "https://github.com/sgl-project/sglang/blob/main/python/sglang/srt/disaggregation/encode_receiver.py"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/sgl-project/sglang/releases/tag/v0.5.10"
+    },
     {
       "type": "WEB",
       "url": "https://orca.security/resources/blog/sglang-llm-framework-rce-vulnerabilities"

advisories/github-reviewed/2026/03/GHSA-rgq9-fqf5-fv58/GHSA-rgq9-fqf5-fv58.json

@@ -1,7 +1,7 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-rgq9-fqf5-fv58",
-  "modified": "2026-03-12T17:38:58Z",
+  "modified": "2026-04-07T22:12:51Z",
   "published": "2026-03-12T12:30:29Z",
   "aliases": [
     "CVE-2026-3059"
@@ -44,6 +44,10 @@
       "type": "ADVISORY",
       "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3059"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/sgl-project/sglang/pull/20904"
+    },
     {
       "type": "PACKAGE",
       "url": "https://github.com/sgl-project/sglang"
@@ -52,6 +56,10 @@
       "type": "WEB",
       "url": "https://github.com/sgl-project/sglang/blob/main/python/sglang/multimodal_gen/runtime/scheduler_client.py"
     },
+    {
+      "type": "WEB",
+      "url": "https://github.com/sgl-project/sglang/releases/tag/v0.5.10"
+    },
     {
       "type": "WEB",
       "url": "https://orca.security/resources/blog/sglang-llm-framework-rce-vulnerabilities"

advisories/github-reviewed/2026/04/GHSA-393c-p46r-7c95/GHSA-393c-p46r-7c95.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-393c-p46r-7c95",
-  "modified": "2026-04-04T06:06:39Z",
+  "modified": "2026-04-07T22:11:26Z",
   "published": "2026-04-04T06:06:39Z",
   "aliases": [],
   "summary": "Directus: Path Traversal and Broken Access Control in File Management API",
-  "details": "## Summary\n\nCritical vulnerabilities were identified in the Directus file management API that allow unauthorized manipulation of file storage paths and metadata. These issues enable attackers to overwrite files belonging to other users, write files outside intended storage boundaries via path traversal, and potentially achieve remote code execution under certain conditions.\n\n## Details\n\nThe file management API accepts user-controlled parameters that should be restricted to server-side logic only. Specifically, the `filename_disk` parameter can be manipulated in both `POST /files` and `PATCH /files/{id}` requests, enabling two attack vectors:\n\n1. **Path Traversal**: By specifying paths containing `../` sequences in the `filename_disk` parameter during file upload, attackers can write files outside the intended storage prefix.\n\n2. **Broken Access Control**: By modifying the `filename_disk` parameter to reference another user's file, attackers can overwrite legitimate files with malicious content while manipulating metadata fields (such as `uploaded_by`) to obscure the tampering.\n\n## Impact\n\n- **Unauthorized File Overwrite**: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption.\n\n- **Storage Boundary Bypass**: Files can be written to arbitrary locations outside the designated storage area, potentially affecting system configurations or application components.\n\n- **Remote Code Execution**: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded (either via service restart or administrator-triggered extension reload).\n\n- **Data Integrity Compromise**: Sensitive files can be tampered with or replaced without visible indication in the application interface, undermining trust in stored data.\n\n## Mitigation\n\nThe `filename_disk` parameter should not be accepted from client input. File paths must be generated exclusively using server-side logic. If client input must be accepted for any path-like parameters, implementations should normalize paths and strictly verify containment within allowed directories, rejecting path traversal sequences, absolute paths, and path separator variants.",
+  "details": "## Summary\n\nA broken access control vulnerability was identified in the Directus file management API that allows authenticated users to overwrite files belonging to other users by manipulating the `filename_disk` parameter.\n\n## Details\n\nThe `PATCH /files/{id}` endpoint accepts a user-controlled `filename_disk` parameter. By setting this value to match the storage path of another user's file, an attacker can overwrite that file's content while manipulating metadata fields such as `uploaded_by` to obscure the tampering.\n\n## Impact\n\n- **Unauthorized File Overwrite**: Attackers can replace legitimate files with malicious content, creating significant risk of malware propagation and data corruption.\n- **Remote Code Execution**: If the storage backend is shared with the extensions location, attackers can deploy malicious extensions that execute arbitrary code when loaded.\n- **Data Integrity Compromise**: Files can be tampered with or replaced without visible indication in the application interface.\n\n## Mitigation\n\nThe `filename_disk` parameter should be treated as a server-controlled value. Uniqueness of storage paths must be enforced server-side, and `filename_disk` should be excluded from the fields users are permitted to update directly.",
   "severity": [
     {
       "type": "CVSS_V3",
@@ -46,6 +46,7 @@
   "database_specific": {
     "cwe_ids": [
       "CWE-284",
+      "CWE-639",
       "CWE-915"
     ],
     "severity": "HIGH",

advisories/github-reviewed/2026/04/GHSA-mvv8-v4jj-g47j/GHSA-mvv8-v4jj-g47j.json

@@ -1,11 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-mvv8-v4jj-g47j",
-  "modified": "2026-04-04T06:12:07Z",
+  "modified": "2026-04-07T22:11:43Z",
   "published": "2026-04-04T06:12:07Z",
   "aliases": [],
   "summary": "Directus: Sensitive fields exposed in revision history",
-  "details": "### Summary\n\nDirectus stores revision records (in `directus_revisions`) whenever items are created or updated. Due to the revision snapshot code not consistently calling the `prepareDelta` sanitization pipeline, sensitive fields (including user tokens, two-factor authentication secrets, external auth identifiers, auth data, stored credentials, and AI provider API keys) could be stored in plaintext within revision records.\n\nAdditionally, the same sensitive fields were missing from the redaction list used when Directus Flows logged operation payloads involving the `directus_users` collection.\n\n### Impact\nAny user or service account with read access to `directus_revisions` (or flow logs) could retrieve values for fields that are supposed to be concealed or encrypted at rest, including:\n- `token`, `tfa_secret`, `external_identifier`, `auth_data`, `credentials`\n- `ai_openai_api_key`, `ai_anthropic_api_key`, `ai_google_api_key`, `ai_openai_compatible_api_key`\n\nThis could lead to account takeover (via stolen tokens or 2FA secrets) or unauthorized use of third-party API keys stored against users.\n\n### Affected code paths\n\n1. **Item create/update revisions** The data (snapshot) field written to directus_revisions was not processed through prepareDelta, so concealed/encrypted fields were stored without redaction. Relational fields were also included, which should have been excluded.\n2. **Authentication service** When a user was auto-suspended after repeated failed login attempts, the revision record was created with the raw user object (including all sensitive fields) rather than the sanitized delta.\n3. **Flows** The payload redaction list used when writing flow logs was missing `token`, `tfa_secret`, `external_identifier`, `auth_data`, `credentials`, and the AI API key fields, causing these to be written unredacted into flow execution data.",
+  "details": "### Summary\n\nDirectus stores revision records (in `directus_revisions`) whenever items are created or updated. Due to the revision snapshot code not consistently calling the `prepareDelta` sanitization pipeline, sensitive fields (including user tokens, two-factor authentication secrets, external auth identifiers, auth data, stored credentials, and AI provider API keys) could be stored in plaintext within revision records.\n\n### Impact\nAny user or service account with read access to `directus_revisions` (or flow logs) could retrieve values for fields that are supposed to be concealed or encrypted at rest, including:\n- `token`, `tfa_secret`, `external_identifier`, `auth_data`, `credentials`\n- `ai_openai_api_key`, `ai_anthropic_api_key`, `ai_google_api_key`, `ai_openai_compatible_api_key`\n\nThis could lead to account takeover (via stolen tokens or 2FA secrets) or unauthorized use of third-party API keys stored against users.\n\n### Affected code paths\n\n1. **Item create/update revisions** The data (snapshot) field written to directus_revisions was not processed through prepareDelta, so concealed/encrypted fields were stored without redaction. Relational fields were also included, which should have been excluded.\n2. **Authentication service** When a user was auto-suspended after repeated failed login attempts, the revision record was created with the raw user object (including all sensitive fields) rather than the sanitized delta.",
   "severity": [
     {
       "type": "CVSS_V3",