Vulnerability-Lookup

GHSA-7648-JMWF-VW7J

Vulnerability from github – Published: 2026-10-28 21:13 – Updated: 2026-10-28 21:13

Summary

systeminformation has prototype pollution in `networkStats()` via the interface name

Details

Summary

networkStats() keeps a per interface cache for computing rx_sec / tx_sec between calls. The cache is a plain JavaScript object and is indexed with the interface name the caller supplied. Passing the name __proto__ makes every cache write land on Object.prototype instead of the cache, polluting every object in the Node.js process.

An application is affected if it passes untrusted input as the ifaces argument of si.networkStats() and runs on FreeBSD, OpenBSD or NetBSD.

Details

The vulnerable code

lib/network.js declares the cache as a plain object:

const _network = {};

calcNetworkSpeed() writes into it, keyed by the interface name:

} else {
  if (!_network[iface]) {
    _network[iface] = {};
  }
  _network[iface].rx_bytes  = rx_bytes;
  _network[iface].tx_bytes  = tx_bytes;
  _network[iface].rx_sec    = null;
  _network[iface].tx_sec    = null;
  _network[iface].ms        = Date.now();
  _network[iface].last_ms   = 0;
  _network[iface].operstate = operstate;
}

With iface === '__proto__' this misbehaves twice:

_network['__proto__'] does not read a missing own property — it invokes the inherited __proto__ getter and returns Object.prototype, which is truthy. The if (!_network[iface]) guard therefore never creates the {} placeholder.
Each following assignment writes onto Object.prototype.

After one call, rx_bytes, tx_bytes, rx_sec, tx_sec, ms, last_ms and operstate are visible on every object in the process. A second call takes the other branch (_network['__proto__'].ms is now truthy) and keeps them updated.

Why the existing sanitizing does not help

The interface name does pass through util.sanitizeString(iface, true) before it is used as the cache key. That function is a shell metacharacter filter, built to stop command injection in the netstat / ifconfig invocations — a different threat. Property names made of letters and underscores are legitimate interface names and pass through untouched:

"a;id"        -> "aid"
"a$(id)"      -> "aid"
"a|id"        -> "aid"
"a`id`"       -> "aid"
"__proto__"   -> "__proto__"     <-- unchanged
"constructor" -> "constructor"   <-- unchanged

The sanitizer is doing its job; the gap is that no layer treats the value as an object key.

Reachability

The cache write is guarded incidentally on three of four platform branches. These guards exist for unrelated reasons and are not a deliberate defence:

Platform	Code path	Reachable with an arbitrary name?
Linux / Android	`fs.existsSync('/sys/class/net/' + ifaceSanitized)`	No — a non-existent interface returns early
macOS	requires `netstat` to emit a data row beyond the header	No — verified on macOS 27, `Object.prototype` stays clean
Windows	`if (rx_bytes && tx_bytes)` — requires a real adapter match	No
FreeBSD / OpenBSD / NetBSD	`if (!error) { …; result = calcNetworkSpeed(ifaceSanitized, …) }`	Yes — the call sits outside the parsing loop, so any successful `netstat` exit reaches it, and `netstat -ibndI <unknown>` prints only its header and exits `0`

The important part is not that three platforms happen to be safe, but that nothing in the design prevents the write. Any future platform branch without such a guard reopens the issue, which is why the fix is applied at the cache rather than at the call sites.

Age

The pattern predates the v5 line — git log -S "_network[iface] = {}" traces it back to a refactoring before v3.42.5. The v3 and v4 lines are end of life; the advisory covers v5.

Impact

The attacker controls which attributes appear on Object.prototype but not their values — those come from the interface statistics (rx_bytes, ms, operstate …). The attribute names are fixed by the library, so this is not an arbitrary-key pollution primitive.

The consequences are therefore application specific and arise from name collisions:

Any application code that tests if (obj.operstate), if (obj.ms) or similar on an object that should not have those properties now takes the wrong branch.
for…in loops over plain objects gain seven extra enumerable keys, which can corrupt serialisation, configuration merging or validation logic.
Libraries that use {} as a lookup map and check membership with in or truthiness can return values for keys that were never inserted.

No path to remote code execution is known, and the values cannot be chosen by the attacker.

Proof of concept

The underlying primitive (any platform)

const { calcNetworkSpeed } = require('systeminformation/lib/network.js'); // internal
const cache = {};                       // the declaration used by the library
calcNetworkSpeed('__proto__', 1, 2, 'up', 0, 0, 0, 0);

console.log({}.rx_bytes);               // 1
console.log({}.operstate);              // 'up'
console.log(Object.prototype.hasOwnProperty('rx_bytes')); // true

End to end through the public API (FreeBSD / OpenBSD / NetBSD)

const si = require('systeminformation');

(async () => {
  console.log('before:', {}.operstate);   // undefined
  await si.networkStats('__proto__');     // an attacker supplied interface name
  console.log('after :', {}.operstate);   // 'up'  -> Object.prototype is polluted
})();

On Linux, macOS and Windows the same call returns an empty result set and leaves Object.prototype untouched, for the reasons in the Reachability table.

Patch

lib/network.js — give the cache a null prototype, so __proto__ becomes an ordinary own property instead of a setter into the prototype chain:

-const _network = {};
+const _network = Object.create(null);

This is the smallest change that fixes the class of problem rather than one reachable path:

It is independent of the platform branches, so no guard has to be added or maintained.
It keeps behaviour identical for every legitimate interface name — Object.keys(), member reads and writes all work unchanged on a null prototype object.
It matches the pattern already used elsewhere in the codebase (lib/filesystem.js:114-115, lib/graphics.js:1060, lib/graphics.js:1087).
Object.create is ES5.1, well below the declared engines.node >= 10.0.0.

After the patch the hostile name is stored as a normal cache entry:

const cache = Object.create(null);
// ... cache['__proto__'] holds the stats object, Object.prototype is untouched

Workarounds

For users who cannot upgrade immediately, either of these is sufficient:

Validate the interface name before calling — accept only names returned by si.networkInterfaces(), or reject the names __proto__, constructor and prototype.
Never pass untrusted input as the ifaces argument. Passing '*' or omitting the argument is unaffected, because those names come from the system rather than the caller.

Freezing Object.prototype (Object.freeze(Object.prototype)) also prevents the write, but it has wide-reaching side effects on other dependencies and is not recommended as a general mitigation.

Affected versions

All 5.x releases up to and including 5.33.12. Earlier major lines contain the same pattern but are end of life.

What was verified, and what was not

Verified on this machine (macOS 27, Node 24):

the pollution primitive, by calling the cache write with iface = '__proto__';
that util.sanitizeString('__proto__', true) returns the string unchanged, while shell metacharacters are stripped;
that unpatched v5 on macOS does not pollute through the public API;
that netstat -bdnI <unknown-interface> prints only its header and exits 0;
that the patch stores the hostile key as an own property and leaves Object.prototype clean.

Not verified, because no such host was available:

end to end exploitation on FreeBSD, OpenBSD or NetBSD. That conclusion is derived from reading the BSD branch of networkStatsSingle() — where the calcNetworkSpeed() call sits outside the row parsing loop and is reached whenever netstat exits successfully — combined with the observed netstat exit behaviour above. Worth confirming on a BSD host before publishing, since the affected-platform list depends on it.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "systeminformation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.33.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-116674"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1321"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:13:32Z",
    "nvd_published_at": "2026-10-27T17:16:59Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`networkStats()` keeps a per interface cache for computing `rx_sec` / `tx_sec` between calls.\nThe cache is a plain JavaScript object and is indexed with the interface name the caller\nsupplied. Passing the name `__proto__` makes every cache write land on `Object.prototype`\ninstead of the cache, polluting every object in the Node.js process.\n\nAn application is affected if it passes untrusted input as the `ifaces` argument of\n`si.networkStats()` and runs on FreeBSD, OpenBSD or NetBSD.\n\n## Details\n\n### The vulnerable code\n\n`lib/network.js` declares the cache as a plain object:\n\n```js\nconst _network = {};\n```\n\n`calcNetworkSpeed()` writes into it, keyed by the interface name:\n\n```js\n} else {\n  if (!_network[iface]) {\n    _network[iface] = {};\n  }\n  _network[iface].rx_bytes  = rx_bytes;\n  _network[iface].tx_bytes  = tx_bytes;\n  _network[iface].rx_sec    = null;\n  _network[iface].tx_sec    = null;\n  _network[iface].ms        = Date.now();\n  _network[iface].last_ms   = 0;\n  _network[iface].operstate = operstate;\n}\n```\n\nWith `iface === \u0027__proto__\u0027` this misbehaves twice:\n\n1. `_network[\u0027__proto__\u0027]` does not read a missing own property \u2014 it invokes the inherited\n   `__proto__` getter and returns `Object.prototype`, which is truthy. The\n   `if (!_network[iface])` guard therefore never creates the `{}` placeholder.\n2. Each following assignment writes onto `Object.prototype`.\n\nAfter one call, `rx_bytes`, `tx_bytes`, `rx_sec`, `tx_sec`, `ms`, `last_ms` and `operstate`\nare visible on **every** object in the process. A second call takes the other branch\n(`_network[\u0027__proto__\u0027].ms` is now truthy) and keeps them updated.\n\n### Why the existing sanitizing does not help\n\nThe interface name does pass through `util.sanitizeString(iface, true)` before it is used as\nthe cache key. That function is a **shell metacharacter** filter, built to stop command\ninjection in the `netstat` / `ifconfig` invocations \u2014 a different threat. Property names made\nof letters and underscores are legitimate interface names and pass through untouched:\n\n```\n\"a;id\"        -\u003e \"aid\"\n\"a$(id)\"      -\u003e \"aid\"\n\"a|id\"        -\u003e \"aid\"\n\"a`id`\"       -\u003e \"aid\"\n\"__proto__\"   -\u003e \"__proto__\"     \u003c-- unchanged\n\"constructor\" -\u003e \"constructor\"   \u003c-- unchanged\n```\n\nThe sanitizer is doing its job; the gap is that no layer treats the value as an *object key*.\n\n### Reachability\n\nThe cache write is guarded incidentally on three of four platform branches. These guards exist\nfor unrelated reasons and are not a deliberate defence:\n\n| Platform | Code path | Reachable with an arbitrary name? |\n| --- | --- | --- |\n| Linux / Android | `fs.existsSync(\u0027/sys/class/net/\u0027 + ifaceSanitized)` | **No** \u2014 a non-existent interface returns early |\n| macOS | requires `netstat` to emit a data row beyond the header | **No** \u2014 verified on macOS 27, `Object.prototype` stays clean |\n| Windows | `if (rx_bytes \u0026\u0026 tx_bytes)` \u2014 requires a real adapter match | **No** |\n| **FreeBSD / OpenBSD / NetBSD** | `if (!error) { \u2026; result = calcNetworkSpeed(ifaceSanitized, \u2026) }` | **Yes** \u2014 the call sits outside the parsing loop, so any successful `netstat` exit reaches it, and `netstat -ibndI \u003cunknown\u003e` prints only its header and exits `0` |\n\nThe important part is not that three platforms happen to be safe, but that nothing in the\ndesign prevents the write. Any future platform branch without such a guard reopens the issue,\nwhich is why the fix is applied at the cache rather than at the call sites.\n\n### Age\n\nThe pattern predates the v5 line \u2014 `git log -S \"_network[iface] = {}\"` traces it back to a\nrefactoring before `v3.42.5`. The v3 and v4 lines are end of life; the advisory covers v5.\n\n## Impact\n\nThe attacker controls which attributes appear on `Object.prototype` but not their values \u2014\nthose come from the interface statistics (`rx_bytes`, `ms`, `operstate` \u2026). The attribute\n*names* are fixed by the library, so this is not an arbitrary-key pollution primitive.\n\nThe consequences are therefore application specific and arise from name collisions:\n\n- Any application code that tests `if (obj.operstate)`, `if (obj.ms)` or similar on an object\n  that should not have those properties now takes the wrong branch.\n- `for\u2026in` loops over plain objects gain seven extra enumerable keys, which can corrupt\n  serialisation, configuration merging or validation logic.\n- Libraries that use `{}` as a lookup map and check membership with `in` or truthiness can\n  return values for keys that were never inserted.\n\nNo path to remote code execution is known, and the values cannot be chosen by the attacker.\n\n## Proof of concept\n\n### The underlying primitive (any platform)\n\n```js\nconst { calcNetworkSpeed } = require(\u0027systeminformation/lib/network.js\u0027); // internal\nconst cache = {};                       // the declaration used by the library\ncalcNetworkSpeed(\u0027__proto__\u0027, 1, 2, \u0027up\u0027, 0, 0, 0, 0);\n\nconsole.log({}.rx_bytes);               // 1\nconsole.log({}.operstate);              // \u0027up\u0027\nconsole.log(Object.prototype.hasOwnProperty(\u0027rx_bytes\u0027)); // true\n```\n\n### End to end through the public API (FreeBSD / OpenBSD / NetBSD)\n\n```js\nconst si = require(\u0027systeminformation\u0027);\n\n(async () =\u003e {\n  console.log(\u0027before:\u0027, {}.operstate);   // undefined\n  await si.networkStats(\u0027__proto__\u0027);     // an attacker supplied interface name\n  console.log(\u0027after :\u0027, {}.operstate);   // \u0027up\u0027  -\u003e Object.prototype is polluted\n})();\n```\n\nOn Linux, macOS and Windows the same call returns an empty result set and leaves\n`Object.prototype` untouched, for the reasons in the *Reachability* table.\n\n## Patch\n\n`lib/network.js` \u2014 give the cache a null prototype, so `__proto__` becomes an ordinary own\nproperty instead of a setter into the prototype chain:\n\n```diff\n-const _network = {};\n+const _network = Object.create(null);\n```\n\nThis is the smallest change that fixes the class of problem rather than one reachable path:\n\n- It is independent of the platform branches, so no guard has to be added or maintained.\n- It keeps behaviour identical for every legitimate interface name \u2014 `Object.keys()`,\n  member reads and writes all work unchanged on a null prototype object.\n- It matches the pattern already used elsewhere in the codebase\n  (`lib/filesystem.js:114-115`, `lib/graphics.js:1060`, `lib/graphics.js:1087`).\n- `Object.create` is ES5.1, well below the declared `engines.node \u003e= 10.0.0`.\n\nAfter the patch the hostile name is stored as a normal cache entry:\n\n```js\nconst cache = Object.create(null);\n// ... cache[\u0027__proto__\u0027] holds the stats object, Object.prototype is untouched\n```\n\n## Workarounds\n\nFor users who cannot upgrade immediately, either of these is sufficient:\n\n1. **Validate the interface name before calling** \u2014 accept only names returned by\n   `si.networkInterfaces()`, or reject the names `__proto__`, `constructor` and `prototype`.\n2. **Never pass untrusted input** as the `ifaces` argument. Passing `\u0027*\u0027` or omitting the\n   argument is unaffected, because those names come from the system rather than the caller.\n\nFreezing `Object.prototype` (`Object.freeze(Object.prototype)`) also prevents the write, but it\nhas wide-reaching side effects on other dependencies and is not recommended as a general\nmitigation.\n\n## Affected versions\n\nAll `5.x` releases up to and including `5.33.12`. Earlier major lines contain the same pattern\nbut are end of life.\n\n### What was verified, and what was not\n\nVerified on this machine (macOS 27, Node 24):\n\n- the pollution primitive, by calling the cache write with `iface = \u0027__proto__\u0027`;\n- that `util.sanitizeString(\u0027__proto__\u0027, true)` returns the string unchanged, while shell\n  metacharacters are stripped;\n- that unpatched v5 on macOS does **not** pollute through the public API;\n- that `netstat -bdnI \u003cunknown-interface\u003e` prints only its header and exits `0`;\n- that the patch stores the hostile key as an own property and leaves `Object.prototype` clean.\n\nNot verified, because no such host was available:\n\n- end to end exploitation on FreeBSD, OpenBSD or NetBSD. That conclusion is derived from\n  reading the BSD branch of `networkStatsSingle()` \u2014 where the `calcNetworkSpeed()` call sits\n  outside the row parsing loop and is reached whenever `netstat` exits successfully \u2014 combined\n  with the observed `netstat` exit behaviour above. Worth confirming on a BSD host before\n  publishing, since the affected-platform list depends on it.",
  "id": "GHSA-7648-jmwf-vw7j",
  "modified": "2026-10-28T21:13:32Z",
  "published": "2026-10-28T21:13:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-7648-jmwf-vw7j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116674"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/commit/6ff25a1ebc0b1fdc7a8aa3507e46f22007da2969"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sebhildebrandt/systeminformation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/releases/tag/v5.33.13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "systeminformation has prototype pollution in `networkStats()` via the interface name"
}

CVE-2026-116674 (GCVE-0-2026-116674)

Vulnerability from cvelistv5 – Published: 2026-10-27 16:40 – Updated: 2026-10-27 16:40

Title

systeminformation: Prototype pollution in `networkStats()` via the interface name

Summary

systeminformation is a System and OS information library for node.js. Prior to 5.33.13, networkStats(ifaces) in lib/network.js on FreeBSD, OpenBSD, and NetBSD stores per-interface data in the plain-object _network cache and indexes it with the sanitized caller-controlled interface name. Passing proto causes the inherited Object.prototype value to be used instead of creating an own cache entry, so calcNetworkSpeed() writes rx_bytes, tx_bytes, rx_sec, tx_sec, ms, last_ms, and operstate onto Object.prototype. The polluted property names are fixed and their values come from interface statistics, but inherited-name collisions and enumerable keys can corrupt application branching, serialization, configuration merging, validation, or lookup behavior. This issue is fixed in version 5.33.13.

Severity

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L

CWE

CWE-1321 - Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8035 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/sebhildebrandt/systeminformati…	x_refsource_CONFIRM
https://github.com/sebhildebrandt/systeminformati…	x_refsource_MISC
https://github.com/sebhildebrandt/systeminformati…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sebhildebrandt	systeminformation	Affected: < 5.33.13

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "systeminformation",
          "vendor": "sebhildebrandt",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 5.33.13"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "systeminformation is a System and OS information library for node.js. Prior to 5.33.13, networkStats(ifaces) in lib/network.js on FreeBSD, OpenBSD, and NetBSD stores per-interface data in the plain-object _network cache and indexes it with the sanitized caller-controlled interface name. Passing proto causes the inherited Object.prototype value to be used instead of creating an own cache entry, so calcNetworkSpeed() writes rx_bytes, tx_bytes, rx_sec, tx_sec, ms, last_ms, and operstate onto Object.prototype. The polluted property names are fixed and their values come from interface statistics, but inherited-name collisions and enumerable keys can corrupt application branching, serialization, configuration merging, validation, or lookup behavior. This issue is fixed in version 5.33.13."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-1321",
              "description": "CWE-1321: Improperly Controlled Modification of Object Prototype Attributes (\u0027Prototype Pollution\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-27T16:40:46.246Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-7648-jmwf-vw7j",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-7648-jmwf-vw7j"
        },
        {
          "name": "https://github.com/sebhildebrandt/systeminformation/commit/6ff25a1ebc0b1fdc7a8aa3507e46f22007da2969",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sebhildebrandt/systeminformation/commit/6ff25a1ebc0b1fdc7a8aa3507e46f22007da2969"
        },
        {
          "name": "https://github.com/sebhildebrandt/systeminformation/releases/tag/v5.33.13",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sebhildebrandt/systeminformation/releases/tag/v5.33.13"
        }
      ],
      "source": {
        "advisory": "GHSA-7648-jmwf-vw7j",
        "discovery": "UNKNOWN"
      },
      "title": "systeminformation: Prototype pollution in `networkStats()` via the interface name"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-116674",
    "datePublished": "2026-10-27T16:40:46.246Z",
    "dateReserved": "2026-10-26T20:00:59.829Z",
    "dateUpdated": "2026-10-27T16:40:46.246Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted

GHSA-7648-JMWF-VW7J

Summary

Details

The vulnerable code

Why the existing sanitizing does not help

Reachability

Age

Impact

Proof of concept

The underlying primitive (any platform)

End to end through the public API (FreeBSD / OpenBSD / NetBSD)

Patch

Workarounds

Affected versions

What was verified, and what was not

CVE-2026-116674 (GCVE-0-2026-116674)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour