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.

482 vulnerabilities reference this CWE, most recent first.

GHSA-JC9H-J7VP-J9JW

Vulnerability from github – Published: 2022-10-28 19:00 – Updated: 2025-10-13 15:31
VLAI
Details

The HEIDENHAIN Controller TNC 640, version 340590 07 SP5, running HEROS 5.08.3 controlling the HARTFORD 5A-65E CNC machine is vulnerable to improper authentication, which may allow an attacker to deny service to the production line, steal sensitive data from the production line, and alter any products created by the production line.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.2 (Critical)
CVSS:4.0/AV:N/AC:H/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": [],
  "aliases": [
    "CVE-2022-41648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-28T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The HEIDENHAIN Controller TNC 640, version 340590 07 SP5, running HEROS 5.08.3 controlling the HARTFORD 5A-65E CNC machine is vulnerable to improper authentication, which may allow an attacker to deny service to the production line, steal sensitive data from the production line, and alter any products created by the production line.",
  "id": "GHSA-jc9h-j7vp-j9jw",
  "modified": "2025-10-13T15:31:18Z",
  "published": "2022-10-28T19:00:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41648"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-22-298-02"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-298-02"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/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-JF4F-59HF-2932

Vulnerability from github – Published: 2022-03-31 00:00 – Updated: 2022-04-06 00:01
VLAI
Details

In miniadb, there is a possible way to get read/write access to recovery system properties due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-201308542

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-39767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-30T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "In miniadb, there is a possible way to get read/write access to recovery system properties due to an insecure default value. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-201308542",
  "id": "GHSA-jf4f-59hf-2932",
  "modified": "2022-04-06T00:01:52Z",
  "published": "2022-03-31T00:00:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39767"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/android-12l"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JFQG-HF23-QPW2

Vulnerability from github – Published: 2026-04-03 02:46 – Updated: 2026-04-06 23:11
VLAI
Summary
Electron: Context Isolation bypass via contextBridge VideoFrame transfer
Details

Impact

Apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script.

Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected.

Workarounds

Do not pass VideoFrame objects across contextBridge. If an app needs to transfer video frame data, serialize it to an ArrayBuffer or ImageBitmap before bridging.

Fixed Versions

  • 41.0.0-beta.8
  • 40.7.0
  • 39.8.0

For more information

If there are any questions or comments about this advisory, please email security@electronjs.org

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "39.0.0-alpha.1"
            },
            {
              "fixed": "39.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "40.0.0-alpha.1"
            },
            {
              "fixed": "40.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "electron"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "41.0.0-alpha.1"
            },
            {
              "fixed": "41.0.0-beta.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34780"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T02:46:56Z",
    "nvd_published_at": "2026-04-04T01:16:39Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nApps that pass `VideoFrame` objects (from the WebCodecs API) across the `contextBridge` are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged `VideoFrame` to gain access to the isolated world, including any Node.js APIs exposed to the preload script.\n\nApps are only affected if a preload script returns, resolves, or passes a `VideoFrame` object to the main world via `contextBridge.exposeInMainWorld()`. Apps that do not bridge `VideoFrame` objects are not affected.\n\n### Workarounds\nDo not pass `VideoFrame` objects across `contextBridge`. If an app needs to transfer video frame data, serialize it to an `ArrayBuffer` or `ImageBitmap` before bridging.\n\n### Fixed Versions\n* `41.0.0-beta.8`\n* `40.7.0`\n* `39.8.0`\n\n### For more information\nIf there are any questions or comments about this advisory, please email [security@electronjs.org](mailto:security@electronjs.org)",
  "id": "GHSA-jfqg-hf23-qpw2",
  "modified": "2026-04-06T23:11:50Z",
  "published": "2026-04-03T02:46:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/electron/electron/security/advisories/GHSA-jfqg-hf23-qpw2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34780"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/electron/electron"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Electron: Context Isolation bypass via contextBridge VideoFrame transfer"
}

GHSA-JGF9-3C8R-RC2P

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

A vulnerability in Cisco Elastic Services Controllers could allow an authenticated, remote attacker to log in to an affected system as the Linux admin user, aka an Insecure Default Credentials Vulnerability. More Information: CSCvc76651. Known Affected Releases: 21.0.0.

Severity
8.8 (High)
CVSS:3.0/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-2017-6684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-13T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Cisco Elastic Services Controllers could allow an authenticated, remote attacker to log in to an affected system as the Linux admin user, aka an Insecure Default Credentials Vulnerability. More Information: CSCvc76651. Known Affected Releases: 21.0.0.",
  "id": "GHSA-jgf9-3c8r-rc2p",
  "modified": "2022-05-13T01:46:44Z",
  "published": "2022-05-13T01:46:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6684"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170607-esc3"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/98979"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JGH3-FGGC-MCPM

Vulnerability from github – Published: 2026-09-18 17:59 – Updated: 2026-09-18 17:59
VLAI
Summary
Obot: Server-Side Request Forgery via remote MCP server URL
Details

Summary

In affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (169.254.169.254), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses.

Am I affected?

You are affected if you run Obot <= v0.22.1 with authentication enabled and allow privileged users (with the Power User or higher privileges) to register remote MCP servers . The metadata-sync code path that triggers the fetch runs automatically during reconciliation, so no user interaction beyond registration is required.

Details

A remote server's URL (RemoteRuntimeConfig.URL) is accepted at registration after only checking that it is parseable and uses an http/https scheme — the destination is never constrained. Obot then connects to that URL when the server is launched or its OAuth state is checked, and the controller automatically fetches OAuth discovery metadata from it during reconcile. The one egress guard that exists (DisallowLocalhostMCP) is disabled by default, only blocks loopback when enabled, and is absent from the automatic metadata-fetch path. Because the fetched response body is reflected back in Obot's error messages, this is a non-blind SSRF.

Impact

An attacker can reach internal-only services and the cloud metadata service if they have the Power User, Power User Plus, or Admin role. Against 169.254.169.254 this can disclose the host's cloud IAM credentials, enabling a pivot into the cloud account.

Mitigation

Upgrade to v0.23.0 or later, which applies a single outbound egress chokepoint — rejecting loopback, link-local (including 169.254.169.254), RFC1918, and IPv6 ULA on the resolved IP at dial time — uniformly across the remote-MCP client and the OAuth-metadata client.

Severity

CVSS v3.1 Score: 7.6/10 (High) — CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N

Credits

The Obot team would like to thank HE WEI（ギカク）(https://www.linkedin.com/in/gikaku, @hewei-gikaku) for responsibly disclosing this issue in accordance with our security policy.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/obot-platform/obot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-18T17:59:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nIn affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (`169.254.169.254`), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses.\n\n## Am I affected?\n\nYou are affected if you run Obot `\u003c= v0.22.1` with authentication enabled and allow privileged users (with the Power User or higher privileges) to register remote MCP servers . The metadata-sync code path that triggers the fetch runs automatically during reconciliation, so no user interaction beyond registration is required.\n\n## Details\n\nA remote server\u0027s URL (`RemoteRuntimeConfig.URL`) is accepted at registration after only checking that it is parseable and uses an `http`/`https` scheme \u2014 the destination is never constrained. Obot then connects to that URL when the server is launched or its OAuth state is checked, and the controller automatically fetches OAuth discovery metadata from it during reconcile. The one egress guard that exists (`DisallowLocalhostMCP`) is disabled by default, only blocks loopback when enabled, and is absent from the automatic metadata-fetch path. Because the fetched response body is reflected back in Obot\u0027s error messages, this is a non-blind SSRF.\n\n## Impact\n\nAn attacker can reach internal-only services and the cloud metadata service if they have the Power User, Power User Plus, or Admin role. Against `169.254.169.254` this can disclose the host\u0027s cloud IAM credentials, enabling a pivot into the cloud account.\n\n## Mitigation\n\nUpgrade to **v0.23.0** or later, which applies a single outbound egress chokepoint \u2014 rejecting loopback, link-local (including `169.254.169.254`), RFC1918, and IPv6 ULA on the resolved IP at dial time \u2014 uniformly across the remote-MCP client and the OAuth-metadata client.\n\n## Severity\n\nCVSS v3.1 Score: **7.6/10 (High)** \u2014 `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N`\n\n## Credits\n\nThe Obot team would like to thank HE WEI\uff08\u30ae\u30ab\u30af\uff09(https://www.linkedin.com/in/gikaku, [@hewei-gikaku](https://github.com/hewei-gikaku)) for responsibly disclosing this issue in accordance with our [security policy](https://github.com/obot-platform/obot/?tab=security-ov-file).",
  "id": "GHSA-jgh3-fggc-mcpm",
  "modified": "2026-09-18T17:59:46Z",
  "published": "2026-09-18T17:59:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/obot-platform/obot/security/advisories/GHSA-jgh3-fggc-mcpm"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/obot-platform/obot"
    },
    {
      "type": "WEB",
      "url": "https://github.com/obot-platform/obot/releases/tag/v0.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Obot: Server-Side Request Forgery via remote MCP server URL"
}

GHSA-JQFW-J9GV-Q6CP

Vulnerability from github – Published: 2025-05-13 12:31 – Updated: 2025-05-13 12:31
VLAI
Details

A vulnerability has been identified in IEC 1Ph 7.4kW Child socket (8EM1310-2EH04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Child socket/ shutter (8EM1310-2EN04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m (8EM1310-2EJ04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m incl. SIM (8EM1310-2EJ04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket (8EM1310-2EH04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket incl. SIM (8EM1310-2EH04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter (8EM1310-2EN04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter SIM (8EM1310-2EN04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Child cable 7m (8EM1310-3EJ04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket (8EM1310-3EH04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket/ shutter (8EM1310-3EN04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m (8EM1310-3EJ04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m incl. SIM (8EM1310-3EJ04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket (8EM1310-3EH04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket incl. SIM (8EM1310-3EH04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter (8EM1310-3EN04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter SIM (8EM1310-3EN04-3GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child socket (8EM1310-3FH04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket (8EM1310-3FH04-3GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket incl. SI (8EM1310-3FH04-3GA2) (All versions < V2.135), UL Commercial Cellular 48A NTEP (8EM1310-5HF14-1GA2) (All versions < V2.135), UL Commercial Child 40A w/ 15118 HW (8EM1310-4CF14-0GA0) (All versions < V2.135), UL Commercial Child 48A BA Compliant (8EM1315-5CG14-0GA0) (All versions < V2.135), UL Commercial Child 48A w/ 15118 HW (8EM1310-5CF14-0GA0) (All versions < V2.135), UL Commercial Parent 40A with Simcard (8EM1310-4CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A (USPS) (8EM1317-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A BA Compliant (8EM1315-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A with Simcard BA (8EM1310-5CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1310-5CG14-1GA1) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1314-5CG14-2FA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1315-5HG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A,15118 25ft Sim (8EM1310-5CG14-1GA2) (All versions < V2.135), VersiCharge Blue™ 80A AC Cellular (8EM1315-7BG16-1FH2) (All versions < V2.135). Affected devices contain Modbus service enabled by default. This could allow an attacker connected to the same network to remotely control the EV charger.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-31930"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-13T10:15:24Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in IEC 1Ph 7.4kW Child socket (8EM1310-2EH04-0GA0) (All versions \u003c V2.135), IEC 1Ph 7.4kW Child socket/ shutter (8EM1310-2EN04-0GA0) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent cable 7m (8EM1310-2EJ04-3GA1) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent cable 7m incl. SIM (8EM1310-2EJ04-3GA2) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent socket (8EM1310-2EH04-3GA1) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent socket incl. SIM (8EM1310-2EH04-3GA2) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent socket/ shutter (8EM1310-2EN04-3GA1) (All versions \u003c V2.135), IEC 1Ph 7.4kW Parent socket/ shutter SIM (8EM1310-2EN04-3GA2) (All versions \u003c V2.135), IEC 3Ph 22kW Child cable 7m (8EM1310-3EJ04-0GA0) (All versions \u003c V2.135), IEC 3Ph 22kW Child socket (8EM1310-3EH04-0GA0) (All versions \u003c V2.135), IEC 3Ph 22kW Child socket/ shutter (8EM1310-3EN04-0GA0) (All versions \u003c V2.135), IEC 3Ph 22kW Parent cable 7m (8EM1310-3EJ04-3GA1) (All versions \u003c V2.135), IEC 3Ph 22kW Parent cable 7m incl. SIM (8EM1310-3EJ04-3GA2) (All versions \u003c V2.135), IEC 3Ph 22kW Parent socket (8EM1310-3EH04-3GA1) (All versions \u003c V2.135), IEC 3Ph 22kW Parent socket incl. SIM (8EM1310-3EH04-3GA2) (All versions \u003c V2.135), IEC 3Ph 22kW Parent socket/ shutter (8EM1310-3EN04-3GA1) (All versions \u003c V2.135), IEC 3Ph 22kW Parent socket/ shutter SIM (8EM1310-3EN04-3GA2) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA0) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA1) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA2) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Child socket (8EM1310-3FH04-0GA0) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Parent socket (8EM1310-3FH04-3GA1) (All versions \u003c V2.135), IEC ERK 3Ph 22 kW Parent socket incl. SI (8EM1310-3FH04-3GA2) (All versions \u003c V2.135), UL Commercial Cellular 48A NTEP (8EM1310-5HF14-1GA2) (All versions \u003c V2.135), UL Commercial Child 40A w/ 15118 HW (8EM1310-4CF14-0GA0) (All versions \u003c V2.135), UL Commercial Child 48A BA Compliant (8EM1315-5CG14-0GA0) (All versions \u003c V2.135), UL Commercial Child 48A w/ 15118 HW (8EM1310-5CF14-0GA0) (All versions \u003c V2.135), UL Commercial Parent 40A with Simcard (8EM1310-4CF14-1GA2) (All versions \u003c V2.135), UL Commercial Parent 48A (USPS) (8EM1317-5CG14-1GA2) (All versions \u003c V2.135), UL Commercial Parent 48A BA Compliant (8EM1315-5CG14-1GA2) (All versions \u003c V2.135), UL Commercial Parent 48A with Simcard BA (8EM1310-5CF14-1GA2) (All versions \u003c V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1310-5CG14-1GA1) (All versions \u003c V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1314-5CG14-2FA2) (All versions \u003c V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1315-5HG14-1GA2) (All versions \u003c V2.135), UL Commercial Parent 48A,15118 25ft Sim (8EM1310-5CG14-1GA2) (All versions \u003c V2.135), VersiCharge Blue\u2122 80A AC Cellular (8EM1315-7BG16-1FH2) (All versions \u003c V2.135). Affected devices contain Modbus service enabled by default. This could allow an attacker connected to the same network to remotely control the EV charger.",
  "id": "GHSA-jqfw-j9gv-q6cp",
  "modified": "2025-05-13T12:31:36Z",
  "published": "2025-05-13T12:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31930"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-556937.html"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/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-JR9P-4H4J-6C58

Vulnerability from github – Published: 2026-07-14 00:07 – Updated: 2026-07-14 00:07
VLAI
Summary
Kimai: Default APP_SECRET in Docker Image Enables Cookie Forgery and Account Takeover
Details

Summary

The official Kimai Docker image ships with APP_SECRET=change_this_to_something_unique as the default environment variable. The Docker entrypoint does not override or validate this value. Any Kimai instance deployed using the Docker image without explicitly setting APP_SECRET runs with a publicly-known Symfony kernel.secret, enabling an unauthenticated attacker to forge HMAC-signed cookies and login links to take over any account including super_admin.

Details

Dockerfile:263 sets ENV APP_SECRET=change_this_to_something_unique. This value is consumed by config/packages/framework.yaml:7 as kernel.secret, which Symfony uses to HMAC-sign:

  • The KIMAI_REMEMBER remember-me cookie
  • LoginLink signatures
  • Password reset URLs
  • CSRF tokens

The .docker/entrypoint.sh does not check for or replace the default sentinel value. The bare-metal .env.dist:38 ships the same default. No startup-time guard exists anywhere in the codebase that refuses to start when APP_SECRET equals the sentinel.

User IDs are sequential integers starting from 1. The first super_admin account is almost always id=1. User IDs are visible in some URLs and API responses.

A PoC was provided, but removed for security reasons.

Impact

Any Kimai instance deployed via the official Docker image without overriding APP_SECRET can be compromised from the internet. An unauthenticated attacker who can reach the Kimai URL can forge authentication tokens and log in as any user if: - a username is known AND - the correct account ID for this username is guessed AND - the account has no active 2FA (two factor) authentication

Solution

  • The entrypoint.sh file is updated and now contains a script that generates a random APP_SECRET via bin2hex(random_bytes(32)) which will be stored in /opt/kimai/var/data/.appsecret
  • The entrypoint.sh will create the file /opt/kimai/.env.local containing the APP_SECRET, either fetched from the Docker Environment or from the newly created secret file
  • The documentation was updated to highlight the importance of using a random secret for APP_SECRET
  • The Dockerfile removed default APP_SECRET=change_this_to_something_unique
  • Login links now contain more entropy (see GHSA-m492-gv72-xvxj) - so even without all previous changes, attackers won't be able to generate Login links even for installations that have a hard-coded APP_SECRET=change_this_to_something_unique

See https://www.kimai.org/en/security/ghsa-jr9p-4h4j-6c58 for more information.

Severity
9.1 (Critical)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/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= 2.57.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.58.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52824"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T00:07:59Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nThe official Kimai Docker image ships with `APP_SECRET=change_this_to_something_unique` as the default environment variable. The Docker entrypoint does not override or validate this value. Any Kimai instance deployed using the Docker image without explicitly setting `APP_SECRET` runs with a publicly-known Symfony `kernel.secret`, enabling an unauthenticated attacker to forge HMAC-signed cookies and login links to take over any account including super_admin.\n\n### Details\n\n`Dockerfile:263` sets `ENV APP_SECRET=change_this_to_something_unique`. This value is consumed by `config/packages/framework.yaml:7` as `kernel.secret`, which Symfony uses to HMAC-sign:\n\n- The `KIMAI_REMEMBER` remember-me cookie\n- LoginLink signatures\n- Password reset URLs\n- CSRF tokens\n\nThe `.docker/entrypoint.sh` does not check for or replace the default sentinel value. The bare-metal `.env.dist:38` ships the same default. No startup-time guard exists anywhere in the codebase that refuses to start when `APP_SECRET` equals the sentinel.\n\nUser IDs are sequential integers starting from 1. The first super_admin account is almost always `id=1`. User IDs are visible in some URLs and API responses.\n\n*A PoC was provided, but removed for security reasons.*\n\n### Impact\n\nAny Kimai instance deployed via the official Docker image without overriding `APP_SECRET` can be compromised from the internet. An unauthenticated attacker who can reach the Kimai URL can forge authentication tokens and log in as any user if:\n- a username is known AND\n- the correct account ID for this username is guessed AND\n- the account has no active 2FA (two factor) authentication\n\n## Solution\n\n- The entrypoint.sh file is updated and now contains a script that generates a random `APP_SECRET` via `bin2hex(random_bytes(32))` which will be stored in  `/opt/kimai/var/data/.appsecret`\n- The entrypoint.sh will create the file `/opt/kimai/.env.local` containing the `APP_SECRET`, either fetched from the Docker Environment or from the newly created secret file\n- The documentation was updated to highlight the importance of using a random secret for `APP_SECRET`\n- The Dockerfile removed default `APP_SECRET=change_this_to_something_unique`\n- Login links now contain more entropy (see GHSA-m492-gv72-xvxj) - so even without all previous changes, attackers won\u0027t be able to generate Login links even for installations that have a hard-coded `APP_SECRET=change_this_to_something_unique`\n\nSee [https://www.kimai.org/en/security/ghsa-jr9p-4h4j-6c58](https://www.kimai.org/en/security/ghsa-jr9p-4h4j-6c58) for more information.",
  "id": "GHSA-jr9p-4h4j-6c58",
  "modified": "2026-07-14T00:07:59Z",
  "published": "2026-07-14T00:07:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-jr9p-4h4j-6c58"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai: Default APP_SECRET in Docker Image Enables Cookie Forgery and Account Takeover"
}

GHSA-JXXV-8R27-VM4P

Vulnerability from github – Published: 2026-10-01 15:40 – Updated: 2026-10-01 15:40
VLAI
Summary
vm2 CLI provides no sandbox isolation - host-realm require() is reachable from sandboxed scripts
Details

Summary

The vm2 command-line tool installed by npm install -g vm2 and documented in the README's "CLI" section runs the supplied script under NodeVM with require:{external:true} and no root / context / builtin configured. With these defaults the resolver loads every relative or absolute require() target through the host require() function, executing the attacker's module body in the host Node.js process before the result is ever proxied back into the sandbox. A single attacker-controlled file passed to vm2 ./script.js can call require(__filename) to re-execute itself in host realm and reach fs, child_process, etc. The documented sandbox runner is therefore equivalent to node ./script.js. No additional files, flags, or user interaction are required.

Details

The vulnerability lets a malicious sandboxed script - the file argument to the documented vm2 <file> CLI - execute arbitrary code in the host Node.js process, crossing the sandbox → host boundary that vm2 is meant to enforce.

Vulnerable code path

  1. Source - bin/vm2:3 → lib/cli.js:7-18. process.argv[2] is the attacker-authored script path. The CLI invokes: js NodeVM.file(path, { verbose: true, require: { external: true } }); Without require.root, require.context, nor require.builtin.
  2. Hop - lib/nodevm.js:618-636. NodeVM.file reads the file and calls new NodeVM(options).run(body, resolvedFilename).
  3. Hop - lib/nodevm.js:335 → lib/resolver-compat.js:205-266 (makeResolverFromLegacyOptions). Destructures external:true, rootPaths=undefined, hostRequire=defaultRequire (line 218), context='host' (default, line 219). Because typeof externalOpt !== 'object' (line 265) it returns a CustomResolver with checkedRootPaths=undefined and pathContext = () => 'host' (line 263).
  4. Hop - lib/setup-node-sandbox.js:86-123 (requireImpl). Sandbox require(id) resolves via resolver.resolve(...) (lib/nodevm.js:380-383). lib/resolver.js:244-275 handles absolute/relative specifiers; tryFile at lib/resolver.js:327-329 gates on this.isPathAllowed(x).
  5. Barrier (gap) - lib/resolver-compat.js:53-54: js isPathAllowed(filename) { if (this.rootPaths === undefined) return true; With no root configured, every filesystem path is allowed. checkAccess (lib/resolver.js:39-42) delegates to the same method.
  6. Sink - lib/resolver-compat.js:74-77: js loadJS(vm, mod, filename) { if (this.pathContext(filename, 'js') !== 'host') return super.loadJS(...); const m = this.hostRequire(filename); // ← host-realm require() mod.exports = vm.readonly(m); } hostRequire is defaultRequire (lib/resolver-compat.js:20-23) - the real host require(). The required module's top-level body executes in the host realm before vm.readonly() wraps the exports; wrapping happens too late to constrain side-effects. loadNode (lib/resolver-compat.js:80-83) is identical for .node native addons (process.dlopen in host).

PoC

Save the following as /tmp/poc.js:

'use strict';
try {
    // Host realm: fs is available - write sentinel and stop.
    const fs = require('fs');
    fs.writeFileSync('/tmp/vm2.proof', 'host pid=' + process.pid + '\n');
    console.log('HOST realm: wrote /tmp/vm2.proof');
} catch (e) {
    // Sandbox realm: require('fs') threw ENOTFOUND. Re-require this file -
    // the CLI resolver loads it via host require() (resolver-compat.js:76).
    console.log('sandbox realm: fs blocked (' + e.message + '); escaping');
    require(__filename);
}

Run via the shipped CLI exactly as the README documents:

node ./bin/vm2 /tmp/poc.js        # or `vm2 /tmp/poc.js` after `npm i -g vm2`

Observed output:

sandbox realm: fs blocked (Cannot find module 'fs'); escaping
HOST realm: wrote /tmp/vm2.proof

/tmp/vm2.proof exists, written by fs.writeFileSync from a script whose direct require('fs') was blocked by the sandbox. The first line proves the boundary exists; the second proves it was crossed.

Impact

A user who follows the README's CLI section and runs vm2 ./untrusted.js on an attacker-supplied file gets arbitrary code execution as that user - the sandbox provides no isolation in this configuration. The blast radius is the full host Node.js process: fs, child_process, process.dlopen, network, environment.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-453",
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:40:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThe `vm2` command-line tool installed by `npm install -g vm2` and documented in the README\u0027s \"CLI\" section runs the supplied script under `NodeVM` with `require:{external:true}` and no `root` / `context` / `builtin` configured. With these defaults the resolver loads every relative or absolute `require()` target through the **host** `require()` function, executing the attacker\u0027s module body in the host Node.js process before the result is ever proxied back into the sandbox. A single attacker-controlled file passed to `vm2 ./script.js` can call `require(__filename)` to re-execute itself in host realm and reach `fs`, `child_process`, etc. The documented sandbox runner is therefore equivalent to `node ./script.js`. No additional files, flags, or user interaction are required.\n\n### Details\nThe vulnerability lets a **malicious sandboxed script** - the file argument to the documented `vm2 \u003cfile\u003e` CLI - execute arbitrary code in the **host Node.js process**, crossing the sandbox \u2192 host boundary that vm2 is meant to enforce.\n\n#### Vulnerable code path\n\n1. **Source** - `bin/vm2:3` \u2192 `lib/cli.js:7-18`. `process.argv[2]` is the\n   attacker-authored script path. The CLI invokes:\n   ```js\n   NodeVM.file(path, { verbose: true, require: { external: true } });\n   ```\n   Without `require.root`, `require.context`, nor `require.builtin`.\n2. **Hop** - `lib/nodevm.js:618-636`. `NodeVM.file` reads the file and calls\n   `new NodeVM(options).run(body, resolvedFilename)`.\n3. **Hop** - `lib/nodevm.js:335` \u2192 `lib/resolver-compat.js:205-266`\n   (`makeResolverFromLegacyOptions`). Destructures `external:true`,\n   `rootPaths=undefined`, `hostRequire=defaultRequire` (line 218),\n   `context=\u0027host\u0027` (default, line 219). Because `typeof externalOpt !== \u0027object\u0027`\n   (line 265) it returns a `CustomResolver` with `checkedRootPaths=undefined` and\n   `pathContext = () =\u003e \u0027host\u0027` (line 263).\n4. **Hop** - `lib/setup-node-sandbox.js:86-123` (`requireImpl`). Sandbox\n   `require(id)` resolves via `resolver.resolve(...)` (`lib/nodevm.js:380-383`).\n   `lib/resolver.js:244-275` handles absolute/relative specifiers; `tryFile` at\n   `lib/resolver.js:327-329` gates on `this.isPathAllowed(x)`.\n5. **Barrier (gap)** - `lib/resolver-compat.js:53-54`:\n   ```js\n   isPathAllowed(filename) {\n       if (this.rootPaths === undefined) return true;\n   ```\n   With no `root` configured, **every** filesystem path is allowed. `checkAccess`\n   (`lib/resolver.js:39-42`) delegates to the same method.\n6. **Sink** - `lib/resolver-compat.js:74-77`:\n   ```js\n   loadJS(vm, mod, filename) {\n       if (this.pathContext(filename, \u0027js\u0027) !== \u0027host\u0027) return super.loadJS(...);\n       const m = this.hostRequire(filename);   // \u2190 host-realm require()\n       mod.exports = vm.readonly(m);\n   }\n   ```\n   `hostRequire` is `defaultRequire` (`lib/resolver-compat.js:20-23`) - the real\n   host `require()`. The required module\u0027s **top-level body executes in the host\n   realm** before `vm.readonly()` wraps the exports; wrapping happens too late to\n   constrain side-effects. `loadNode` (`lib/resolver-compat.js:80-83`) is\n   identical for `.node` native addons (`process.dlopen` in host).\n\n### PoC\nSave the following as `/tmp/poc.js`:\n\n```js\n\u0027use strict\u0027;\ntry {\n    // Host realm: fs is available - write sentinel and stop.\n    const fs = require(\u0027fs\u0027);\n    fs.writeFileSync(\u0027/tmp/vm2.proof\u0027, \u0027host pid=\u0027 + process.pid + \u0027\\n\u0027);\n    console.log(\u0027HOST realm: wrote /tmp/vm2.proof\u0027);\n} catch (e) {\n    // Sandbox realm: require(\u0027fs\u0027) threw ENOTFOUND. Re-require this file -\n    // the CLI resolver loads it via host require() (resolver-compat.js:76).\n    console.log(\u0027sandbox realm: fs blocked (\u0027 + e.message + \u0027); escaping\u0027);\n    require(__filename);\n}\n```\n\nRun via the shipped CLI exactly as the README documents:\n\n```sh\nnode ./bin/vm2 /tmp/poc.js        # or `vm2 /tmp/poc.js` after `npm i -g vm2`\n```\n\nObserved output:\n\n```\nsandbox realm: fs blocked (Cannot find module \u0027fs\u0027); escaping\nHOST realm: wrote /tmp/vm2.proof\n```\n\n`/tmp/vm2.proof` exists, written by `fs.writeFileSync` from a script whose\ndirect `require(\u0027fs\u0027)` was blocked by the sandbox. The first line proves the\nboundary exists; the second proves it was crossed.\n\n\n### Impact\nA user who follows the README\u0027s CLI section and runs `vm2 ./untrusted.js` on an\nattacker-supplied file gets **arbitrary code execution as that user** - the\nsandbox provides no isolation in this configuration. The blast radius is the\nfull host Node.js process: `fs`, `child_process`, `process.dlopen`, network,\nenvironment.",
  "id": "GHSA-jxxv-8r27-vm4p",
  "modified": "2026-10-01T15:40:46Z",
  "published": "2026-10-01T15:40:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-jxxv-8r27-vm4p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92950"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/903017c8a1eae9aba947ec854468b48155e79f86"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-sandbox-escape-via-cli-require"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2 CLI provides no sandbox isolation - host-realm require() is reachable from sandboxed scripts"
}

GHSA-M2C9-V8XF-797H

Vulnerability from github – Published: 2025-04-09 12:30 – Updated: 2025-04-09 12:30
VLAI
Details

CWE-1188: Initialization of a Resource with an Insecure Default vulnerability exists that could lead to loss of confidentiality when a malicious user, having physical access, sets the radio in factory default mode where the product does not correctly initialize all data.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
4.1 (Medium)
CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-2441"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-09T11:15:42Z",
    "severity": "MODERATE"
  },
  "details": "CWE-1188: Initialization of a Resource with an Insecure Default vulnerability exists that could lead to loss of\nconfidentiality when a malicious user, having physical access, sets the radio in factory default mode where the\nproduct does not correctly initialize all data.",
  "id": "GHSA-m2c9-v8xf-797h",
  "modified": "2025-04-09T12:30:24Z",
  "published": "2025-04-09T12:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2441"
    },
    {
      "type": "WEB",
      "url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2025-098-02\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2025-098-02.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/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"
    }
  ]
}

GHSA-M2M9-VHW3-W774

Vulnerability from github – Published: 2026-05-12 18:30 – Updated: 2026-05-12 18:30
VLAI
Details

Insecure Default Initialization of Resource vulnerability allows Authentication Bypass via API access. This issue affects Pandora FMS: from 777 through 800

Severity
9.1 (Critical)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/S:N/AU:N/R:U/V:C/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-30805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T16:16:12Z",
    "severity": "CRITICAL"
  },
  "details": "Insecure Default Initialization of Resource vulnerability allows Authentication Bypass via API access. This issue affects Pandora FMS: from 777 through 800",
  "id": "GHSA-m2m9-vhw3-w774",
  "modified": "2026-05-12T18:30:37Z",
  "published": "2026-05-12T18:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30805"
    },
    {
      "type": "WEB",
      "url": "https://pandorafms.com/en/security/common-vulnerabilities-and-exposures"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/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:N/AU:N/R:U/V:C/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

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