Vulnerability-Lookup

GHSA-X8RM-F576-GQ67

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

Summary

graphql-scalars PhoneNumber scalar is vulnerable to regular expression denial of service

Details

Summary

The regular expression behind GraphQLPhoneNumber since 1.24.1 backtracks exponentially. A string made of a run of digits followed by one character that makes the match fail (for example "1".repeat(30) + "x") blocks the JavaScript thread for seconds, and every additional digit doubles the time.

graphql-js calls parseLiteral while validating a document and parseValue while coercing variables, so the regex runs for every request that merely contains such a value in a PhoneNumber position, before execution and before any authentication or authorization step of the server. One small unauthenticated request is enough to stall a server process.

Affected versions

graphql-scalars >= 1.24.1, <= 2.0.0 (2.0.0 is the current latest; the default branch still has the same pattern).
Not affected: 1.24.0 and the earlier versions I checked (1.22.4, 1.23.0), which use the linear /^\+[1-9]\d{6,14}$/.
Introduced by #2719 (c7f58da16, "PhoneNumber scalar is not fully compatible with E.164 format so updated regex to support phone number with extension"), released as 1.24.1 on 2025-01-29.

The payload was ran against 1.22.4, 1.23.0, 1.24.0, 1.24.1, 1.24.2, 1.25.0, 1.26.0 and 2.0.0: the first three reject it instantly, the other five show the exponential growth.

Root cause

src/scalars/PhoneNumber.ts:

const PHONE_NUMBER_REGEX = /^\+?\d{1,3}(\-|\x20)?\(?\d+\)?((\-|\x20)?\d+)+$/;

In \d+\)?((\-|\x20)?\d+)+$ the separator is optional, so a run of n digits can be split across the inner \d+ and the outer + iterations in a number of ways that is exponential in n. When the overall match fails, for instance on a trailing non-digit, the engine tries all of them.

Proof of concept

The scalar alone (npm i graphql graphql-scalars@2.0.0):

import { GraphQLPhoneNumber } from 'graphql-scalars';

for (const ok of ['+41791234567', '079 123 45 67', '+1 (123) 456-7890', 'nope']) {
  try { GraphQLPhoneNumber.parseValue(ok); } catch {}
}
for (const digits of [24, 26, 28, 30]) {
  const start = performance.now();
  try { GraphQLPhoneNumber.parseValue('1'.repeat(digits) + 'x'); } catch {}
  console.log(`${digits} digits: ${((performance.now() - start) / 1000).toFixed(2)} s`);
}

Measured warm, i.e. after ordinary inputs have been validated like in a running server:

digits	Node 22.19.0	Node 26.10.0
24	0.10 s	0.07 s
26	0.41 s	0.29 s
28	1.63 s	1.14 s
30	6.59 s	4.62 s

The time doubles with every digit. The first execution of the regex in a fresh process is about 5x slower because V8 interprets a regexp on its first run (Node 22.19.0, 28 digits: 7.8 s).

Through graphql-js, no server and no authentication: a schema with a single echo(phone: PhoneNumber) field, 26 digits + x, Node 22.19.0, warm:

	literal (`parseLiteral`, validation)	variable (`parseValue`, coercion)
graphql 16.14.2	0.41 s	0.43 s
graphql 17.0.2	0.41 s	0.83 s (evaluated twice)

Also reproduced end to end against a GraphQL Yoga server: an anonymous HTTP request with a 27-digit value plus one invalid character stalled the whole process (a concurrent trivial { __typename } request waited as long). A mutation that requires authentication was affected equally when called anonymously, because document validation runs before any authorization in resolvers or context.

Impact

Denial of service. Any GraphQL server that exposes PhoneNumber on an argument, an input object field or a variable can be stalled by a request of about 30 characters; roughly 40 characters would keep a process busy for hours (extrapolated from the doubling, not measured). serialize uses the same regex, so unvalidated stored values returned through a PhoneNumber field are affected too. The actual severity depends on the scalar being applied to untrusted input, which is the typical case.

Suggested fix

An equivalent pattern without ambiguous splits:

const PHONE_NUMBER_REGEX = /^\+?\d{1,3}[- ]?\(?\d(?:\d*\))?(?:[- ]?\d)+$/;

It accepts exactly the same strings as the current one, so there is no behaviour change: with N = (S?\d+)+ = (S?\d)+ a digit run is just repeated single-digit iterations, hence \d+\)?N = \d(\d*\))?N. Verification:

exhaustive comparison of old and new pattern on every string up to length 9 over 1 + - space ( ) x: 47,079,208 strings (1,832 accepted), 0 differences;
every sequence of up to 6 tokens from 1 11 111 1111 11111 + - space ( ) x: 1,948,717 strings (100,380 accepted), 0 differences;
adversarial inputs (digit runs plus a failing character, digit/space and digit/dash alternations, parenthesis variants) scale linearly: 1,000,000 characters take about 10 ms, where the current pattern needs 0.3 s for 26.

Optionally also reject values above a sane length before matching; the grammar currently has no upper bound and E.164 allows at most 15 digits. Above roughly 10 million characters V8 aborts the match with a RangeError (stack) after about 25 ms instead of returning false.

A regression test that fails with the current implementation: GraphQLPhoneNumber.parseValue('1'.repeat(40) + 'x') must throw its validation error immediately; with the current pattern it does not return in any reasonable time.

Workarounds for users until a fix is released

Replace the scalar in the schema with one that uses the pattern above.
Run Node with --enable-experimental-regexp-engine-on-excessive-backtracks, or call v8.setFlagsFromString('--enable-experimental-regexp-engine-on-excessive-backtracks') before the regex first runs. V8 then falls back to its linear-time engine after excessive backtracking; verified on Node 22.19, 24.15 and 26.10. The flag is not accepted in NODE_OPTIONS.
Pinning graphql-scalars to <= 1.24.0 restores a linear pattern but changes which values are accepted (only + prefixed E.164).

Coordination

We have not disclosed this publicly. We maintain Unchained Engine (@unchainedshop/api), a downstream project that exposes this scalar on public input fields and will need to ship a mitigation of its own, so we would like to coordinate the timing of any public disclosure with you. Please let us know your preferred timeline, and whether you would like us to prepare a pull request (we can work in a temporary private fork if you enable one).

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "graphql-scalars"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.24.1"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-115887"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1333"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:13:10Z",
    "nvd_published_at": "2026-10-23T22:16:58Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe regular expression behind `GraphQLPhoneNumber` since 1.24.1 backtracks exponentially. A string made of a run of digits followed by one character that makes the match fail (for example `\"1\".repeat(30) + \"x\"`) blocks the JavaScript thread for seconds, and every additional digit doubles the time.\n\ngraphql-js calls `parseLiteral` while *validating* a document and `parseValue` while coercing variables, so the regex runs for every request that merely contains such a value in a `PhoneNumber` position, before execution and before any authentication or authorization step of the server. One small unauthenticated request is enough to stall a server process.\n\n## Affected versions\n\n- `graphql-scalars` \u003e= 1.24.1, \u003c= 2.0.0 (2.0.0 is the current `latest`; the default branch still has the same pattern).\n- Not affected: 1.24.0 and the earlier versions I checked (1.22.4, 1.23.0), which use the linear `/^\\+[1-9]\\d{6,14}$/`.\n- Introduced by #2719 (c7f58da16, \"PhoneNumber scalar is not fully compatible with E.164 format so updated regex to support phone number with extension\"), released as 1.24.1 on 2025-01-29.\n\nThe payload was ran against 1.22.4, 1.23.0, 1.24.0, 1.24.1, 1.24.2, 1.25.0, 1.26.0 and 2.0.0: the first three reject it instantly, the other five show the exponential growth.\n\n## Root cause\n\n`src/scalars/PhoneNumber.ts`:\n\n```js\nconst PHONE_NUMBER_REGEX = /^\\+?\\d{1,3}(\\-|\\x20)?\\(?\\d+\\)?((\\-|\\x20)?\\d+)+$/;\n```\n\nIn `\\d+\\)?((\\-|\\x20)?\\d+)+$` the separator is optional, so a run of n digits can be split across the inner `\\d+` and the outer `+` iterations in a number of ways that is exponential in n. When the overall match fails, for instance on a trailing non-digit, the engine tries all of them.\n\n## Proof of concept\n\n1. The scalar alone (`npm i graphql graphql-scalars@2.0.0`):\n\n```js\nimport { GraphQLPhoneNumber } from \u0027graphql-scalars\u0027;\n\nfor (const ok of [\u0027+41791234567\u0027, \u0027079 123 45 67\u0027, \u0027+1 (123) 456-7890\u0027, \u0027nope\u0027]) {\n  try { GraphQLPhoneNumber.parseValue(ok); } catch {}\n}\nfor (const digits of [24, 26, 28, 30]) {\n  const start = performance.now();\n  try { GraphQLPhoneNumber.parseValue(\u00271\u0027.repeat(digits) + \u0027x\u0027); } catch {}\n  console.log(`${digits} digits: ${((performance.now() - start) / 1000).toFixed(2)} s`);\n}\n```\n\nMeasured warm, i.e. after ordinary inputs have been validated like in a running server:\n\n| digits | Node 22.19.0 | Node 26.10.0 |\n|-------:|-------------:|-------------:|\n| 24 | 0.10 s | 0.07 s |\n| 26 | 0.41 s | 0.29 s |\n| 28 | 1.63 s | 1.14 s |\n| 30 | 6.59 s | 4.62 s |\n\nThe time doubles with every digit. The first execution of the regex in a fresh process is about 5x slower because V8 interprets a regexp on its first run (Node 22.19.0, 28 digits: 7.8 s).\n\n2. Through graphql-js, no server and no authentication: a schema with a single `echo(phone: PhoneNumber)` field, 26 digits + `x`, Node 22.19.0, warm:\n\n| | literal (`parseLiteral`, validation) | variable (`parseValue`, coercion) |\n|---|---:|---:|\n| graphql 16.14.2 | 0.41 s | 0.43 s |\n| graphql 17.0.2 | 0.41 s | 0.83 s (evaluated twice) |\n\n3. Also reproduced end to end against a GraphQL Yoga server: an anonymous HTTP request with a 27-digit value plus one invalid character stalled the whole process (a concurrent trivial `{ __typename }` request waited as long). A mutation that requires authentication was affected equally when called anonymously, because document validation runs before any authorization in resolvers or context.\n\n## Impact\n\nDenial of service. Any GraphQL server that exposes `PhoneNumber` on an argument, an input object field or a variable can be stalled by a request of about 30 characters; roughly 40 characters would keep a process busy for hours (extrapolated from the doubling, not measured). `serialize` uses the same regex, so unvalidated stored values returned through a `PhoneNumber` field are affected too. The actual severity depends on the scalar being applied to untrusted input, which is the typical case.\n\n## Suggested fix\n\nAn equivalent pattern without ambiguous splits:\n\n```js\nconst PHONE_NUMBER_REGEX = /^\\+?\\d{1,3}[- ]?\\(?\\d(?:\\d*\\))?(?:[- ]?\\d)+$/;\n```\n\nIt accepts exactly the same strings as the current one, so there is no behaviour change: with `N = (S?\\d+)+ = (S?\\d)+` a digit run is just repeated single-digit iterations, hence `\\d+\\)?N = \\d(\\d*\\))?N`. Verification:\n\n- exhaustive comparison of old and new pattern on every string up to length 9 over `1 + - space ( ) x`: 47,079,208 strings (1,832 accepted), 0 differences;\n- every sequence of up to 6 tokens from `1 11 111 1111 11111 + - space ( ) x`: 1,948,717 strings (100,380 accepted), 0 differences;\n- adversarial inputs (digit runs plus a failing character, digit/space and digit/dash alternations, parenthesis variants) scale linearly: 1,000,000 characters take about 10 ms, where the current pattern needs 0.3 s for 26.\n\nOptionally also reject values above a sane length before matching; the grammar currently has no upper bound and E.164 allows at most 15 digits. Above roughly 10 million characters V8 aborts the match with a `RangeError` (stack) after about 25 ms instead of returning false.\n\nA regression test that fails with the current implementation: `GraphQLPhoneNumber.parseValue(\u00271\u0027.repeat(40) + \u0027x\u0027)` must throw its validation error immediately; with the current pattern it does not return in any reasonable time.\n\n## Workarounds for users until a fix is released\n\n- Replace the scalar in the schema with one that uses the pattern above.\n- Run Node with `--enable-experimental-regexp-engine-on-excessive-backtracks`, or call `v8.setFlagsFromString(\u0027--enable-experimental-regexp-engine-on-excessive-backtracks\u0027)` before the regex first runs. V8 then falls back to its linear-time engine after excessive backtracking; verified on Node 22.19, 24.15 and 26.10. The flag is not accepted in `NODE_OPTIONS`.\n- Pinning `graphql-scalars` to \u003c= 1.24.0 restores a linear pattern but changes which values are accepted (only `+` prefixed E.164).\n\n## Coordination\n\nWe have not disclosed this publicly. We maintain Unchained Engine (`@unchainedshop/api`), a downstream project that exposes this scalar on public input fields and will need to ship a mitigation of its own, so we would like to coordinate the timing of any public disclosure with you. Please let us know your preferred timeline, and whether you would like us to prepare a pull request (we can work in a temporary private fork if you enable one).",
  "id": "GHSA-x8rm-f576-gq67",
  "modified": "2026-10-30T15:36:51Z",
  "published": "2026-10-28T21:13:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/graphql-hive/graphql-scalars/security/advisories/GHSA-x8rm-f576-gq67"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115887"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-hive/graphql-scalars/pull/2719"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-hive/graphql-scalars/commit/210fd2485641afa2452800c00144245c74361701"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/graphql-hive/graphql-scalars"
    },
    {
      "type": "WEB",
      "url": "https://github.com/graphql-hive/graphql-scalars/releases/tag/v2.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "graphql-scalars PhoneNumber scalar is vulnerable to regular expression denial of service"
}

CVE-2026-115887 (GCVE-0-2026-115887)

Vulnerability from cvelistv5 – Published: 2026-10-23 21:19 – Updated: 2026-10-30 18:45

Title

graphql-scalars PhoneNumber scalar is vulnerable to regular expression denial of service

Summary

GraphQL Scalars is a library of custom GraphQL scalars for creating precise type-safe GraphQL schemas. From 1.24.1 until 2.0.1, GraphQLPhoneNumber in src/scalars/PhoneNumber.ts uses ambiguous nested digit quantifiers that backtrack exponentially when a PhoneNumber value contains a run of digits followed by a character that makes the match fail. GraphQL evaluates parseLiteral during document validation and parseValue during variable coercion before resolver authentication or authorization, so a small unauthenticated request can block the Node.js event loop and stall the server process. serialize is also affected when unvalidated stored values are returned through the scalar. This issue is fixed in version 2.0.1.

Severity

7.5 (High)


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

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-30 18:44 UTC

CWE

CWE-1333 - Inefficient Regular Expression Complexity

Assigner

GitHub_M CNA under the mitre root

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

References

4 references

URL	Tags
https://github.com/graphql-hive/graphql-scalars/s…	x_refsource_CONFIRM
https://github.com/graphql-hive/graphql-scalars/p…	x_refsource_MISC
https://github.com/graphql-hive/graphql-scalars/c…	x_refsource_MISC
https://github.com/graphql-hive/graphql-scalars/r…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
graphql-hive	graphql-scalars	Affected: >= 1.24.1, < 2.0.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-115887",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T18:44:57.113367Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-30T18:45:04.885Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/graphql-hive/graphql-scalars/security/advisories/GHSA-x8rm-f576-gq67"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "graphql-scalars",
          "vendor": "graphql-hive",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.24.1, \u003c 2.0.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "GraphQL Scalars is a library of custom GraphQL scalars for creating precise type-safe GraphQL schemas. From 1.24.1 until 2.0.1, GraphQLPhoneNumber in src/scalars/PhoneNumber.ts uses ambiguous nested digit quantifiers that backtrack exponentially when a PhoneNumber value contains a run of digits followed by a character that makes the match fail. GraphQL evaluates parseLiteral during document validation and parseValue during variable coercion before resolver authentication or authorization, so a small unauthenticated request can block the Node.js event loop and stall the server process. serialize is also affected when unvalidated stored values are returned through the scalar. This issue is fixed in version 2.0.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-1333",
              "description": "CWE-1333: Inefficient Regular Expression Complexity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-23T21:19:42.561Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/graphql-hive/graphql-scalars/security/advisories/GHSA-x8rm-f576-gq67",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/graphql-hive/graphql-scalars/security/advisories/GHSA-x8rm-f576-gq67"
        },
        {
          "name": "https://github.com/graphql-hive/graphql-scalars/pull/2719",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/graphql-hive/graphql-scalars/pull/2719"
        },
        {
          "name": "https://github.com/graphql-hive/graphql-scalars/commit/210fd2485641afa2452800c00144245c74361701",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/graphql-hive/graphql-scalars/commit/210fd2485641afa2452800c00144245c74361701"
        },
        {
          "name": "https://github.com/graphql-hive/graphql-scalars/releases/tag/v2.0.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/graphql-hive/graphql-scalars/releases/tag/v2.0.1"
        }
      ],
      "source": {
        "advisory": "GHSA-x8rm-f576-gq67",
        "discovery": "UNKNOWN"
      },
      "title": "graphql-scalars PhoneNumber scalar is vulnerable to regular expression denial of service"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-115887",
    "datePublished": "2026-10-23T21:19:42.561Z",
    "dateReserved": "2026-10-23T19:37:27.176Z",
    "dateUpdated": "2026-10-30T18:45:04.885Z",
    "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

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

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-X8RM-F576-GQ67

Summary

Affected versions

Root cause

Proof of concept

Impact

Suggested fix

Workarounds for users until a fix is released

Coordination

CVE-2026-115887 (GCVE-0-2026-115887)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour