Vulnerability-Lookup

GHSA-56X6-Q882-MF27

Vulnerability from github – Published: 2026-11-09 21:18 – Updated: 2026-11-09 21:18

Summary

Remark42: Rate limit bypass via unconditional trust of X-Forwarded-For/X-Real-IP headers in direct-internet deployment

Details

Summary

Remark42 applied chi's middleware.RealIP globally, trusting True-Client-IP / X-Real-IP / X-Forwarded-For headers without verifying the request came from a trusted proxy. The per-IP rate limiters key on the overwritten r.RemoteAddr, so any client can bypass every per-IP rate limiter by rotating spoofed IP headers. The same spoofed IP also drives other per-IP controls (stored comment IP, anonymous identity derivation, and --votes-ip vote de-duplication). This affects deployments reachable directly from the internet (Remark42's built-in HTTP, static TLS, and ACME modes are all documented and supported), as well as any proxied deployment where the proxy forwards an attacker-controlled recognised header.

Details

The router applies middleware.RealIP globally, ahead of the per-route limiters, without any check that the server is behind a trusted proxy (in v1.16.1, backend/app/rest/api/rest.go:207).

The rateLimiter function (v1.16.1, backend/app/rest/api/rest.go:769-779) builds a tollbooth limiter with IPLookup{Name: "RemoteAddr"}, which reads r.RemoteAddr. Since chi's middleware.RealIP (v1.16.1, backend/vendor/github.com/go-chi/chi/v5/middleware/realip.go:42-55) unconditionally overwrites r.RemoteAddr from True-Client-IP > X-Real-IP > first X-Forwarded-For (accepting any syntactically valid IP), any client can set its apparent IP to an arbitrary value.

This bypasses every per-IP rate limiter that runs after RealIP: /auth (2/s), avatars (100/s), the image proxy (10/s), open / protected / admin route groups (10/s), root routes (50/s), and /web/* (20/s). Comment and vote creation go through the update limiter, whose server default is UPDATE_LIMIT=0.5/s (burst 1), not 10/s. The global 1,000 concurrent-request throttle still applies, so this is a per-IP-limit bypass rather than truly unlimited throughput. chi's own documentation warns that middleware.RealIP should be used only behind a trusted proxy.

PoC

# Deploy Remark42 reachable directly from the internet (built-in HTTP / TLS / ACME, no proxy that overwrites the headers).
# Comment creation is limited to UPDATE_LIMIT (default 0.5/s, burst 1) per IP.

# Rotate X-Real-IP across many requests; each distinct value gets its own token bucket.
for i in $(seq 1 100); do
  curl -s -o /dev/null -w '%{http_code}\n' \
    -H "X-Real-IP: 192.0.2.$i" \
    -X POST 'https://remark42.example.com/api/v1/comment?site=site1' \
    -H 'Authorization: Bearer YOUR_JWT' \
    -H 'Content-Type: application/json' \
    -d '{"text":"spam","locator":{"site":"site1","url":"https://example.com/post"}}'
done | sort | uniq -c
# With rotating headers the responses stay 201; without them, requests beyond the burst return 429.

Impact

By rotating the spoofed client IP an attacker bypasses the per-IP token buckets on all rate-limited endpoints and defeats other per-IP controls, enabling: (a) spam comment creation beyond the configured per-IP limit, (b) confirmation-email / notification flooding to supplied addresses, (c) high-volume outbound image fetching and resource consumption via the image proxy (its transport still blocks private/reserved destinations and DNS rebinding, so this is amplification, not new SSRF reach), (d) authentication-endpoint abuse, (e) where --votes-ip is enabled, defeating per-IP vote de-duplication (ballot stuffing), and (f) minting fresh anonymous identities and poisoning the stored comment IP and request logs, since the anonymous user ID is derived from name + RemoteAddr. The global concurrency ceiling and per-request timeouts remain, so availability impact is limited.

Resolution

Mitigation support was added in v1.16.2 (umputun/remark42#2116, follow-up in #2118). Upgrading alone does not remediate the issue: --trusted-proxy must be configured.

The fix adds --trusted-proxy / TRUSTED_PROXY. When set, the forwarding headers (X-Real-IP, then CF-Connecting-IP, then the leftmost public X-Forwarded-For) are honoured only when the direct TCP peer falls inside a trusted-proxy network; for a request from any other peer those headers are dropped and the real socket IP is used. When it is unset, the previous trust-all behaviour is preserved for backward compatibility and a startup warning is logged, so an un-configured v1.16.2 remains exploitable. True-Client-IP is no longer recognised. TRUSTED_PROXY takes a comma-separated list; on the command line, repeat --trusted-proxy per entry.

Required configuration: - Reachable directly from the internet: set a value that no real client matches so the forwarding headers are always ignored, e.g. --trusted-proxy=127.0.0.1/32 (only when Remark42 is not actually reached over loopback). - Behind a reverse proxy: point --trusted-proxy at the proxy's network only, block direct access to Remark42, and make the proxy overwrite X-Real-IP with the real client and discard client-supplied forwarding headers. A proxy that merely appends to X-Forwarded-For, or that forwards a client-supplied X-Real-IP, still lets the client choose the reported IP. Note that the shipped nginx manual sets X-Real-IP but does not strip a client True-Client-IP. - Before v1.16.2: strip True-Client-IP, X-Real-IP, and X-Forwarded-For at the edge and set a known-safe client-IP header.

See the Trusted proxies and client IP docs.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/umputun/remark42/backend"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.16.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/umputun/remark42"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "last_affected": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77463"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-09T21:18:29Z",
    "nvd_published_at": "2026-11-05T21:18:53Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nRemark42 applied chi\u0027s `middleware.RealIP` globally, trusting `True-Client-IP` / `X-Real-IP` / `X-Forwarded-For` headers without verifying the request came from a trusted proxy. The per-IP rate limiters key on the overwritten `r.RemoteAddr`, so any client can bypass every per-IP rate limiter by rotating spoofed IP headers. The same spoofed IP also drives other per-IP controls (stored comment IP, anonymous identity derivation, and `--votes-ip` vote de-duplication). This affects deployments reachable directly from the internet (Remark42\u0027s built-in HTTP, static TLS, and ACME modes are all documented and supported), as well as any proxied deployment where the proxy forwards an attacker-controlled recognised header.\n\n### Details\nThe router applies `middleware.RealIP` globally, ahead of the per-route limiters, without any check that the server is behind a trusted proxy (in v1.16.1, `backend/app/rest/api/rest.go:207`).\n\nThe `rateLimiter` function (v1.16.1, `backend/app/rest/api/rest.go:769-779`) builds a tollbooth limiter with `IPLookup{Name: \"RemoteAddr\"}`, which reads `r.RemoteAddr`. Since chi\u0027s `middleware.RealIP` (v1.16.1, `backend/vendor/github.com/go-chi/chi/v5/middleware/realip.go:42-55`) unconditionally overwrites `r.RemoteAddr` from `True-Client-IP \u003e X-Real-IP \u003e first X-Forwarded-For` (accepting any syntactically valid IP), any client can set its apparent IP to an arbitrary value.\n\nThis bypasses every per-IP rate limiter that runs after `RealIP`: `/auth` (2/s), avatars (100/s), the image proxy (10/s), open / protected / admin route groups (10/s), root routes (50/s), and `/web/*` (20/s). Comment and vote creation go through the update limiter, whose server default is `UPDATE_LIMIT=0.5`/s (burst 1), not 10/s. The global 1,000 concurrent-request throttle still applies, so this is a per-IP-limit bypass rather than truly unlimited throughput. chi\u0027s own documentation warns that `middleware.RealIP` should be used only behind a trusted proxy.\n\n### PoC\n```bash\n# Deploy Remark42 reachable directly from the internet (built-in HTTP / TLS / ACME, no proxy that overwrites the headers).\n# Comment creation is limited to UPDATE_LIMIT (default 0.5/s, burst 1) per IP.\n\n# Rotate X-Real-IP across many requests; each distinct value gets its own token bucket.\nfor i in $(seq 1 100); do\n  curl -s -o /dev/null -w \u0027%{http_code}\\n\u0027 \\\n    -H \"X-Real-IP: 192.0.2.$i\" \\\n    -X POST \u0027https://remark42.example.com/api/v1/comment?site=site1\u0027 \\\n    -H \u0027Authorization: Bearer YOUR_JWT\u0027 \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"text\":\"spam\",\"locator\":{\"site\":\"site1\",\"url\":\"https://example.com/post\"}}\u0027\ndone | sort | uniq -c\n# With rotating headers the responses stay 201; without them, requests beyond the burst return 429.\n```\n\n### Impact\nBy rotating the spoofed client IP an attacker bypasses the per-IP token buckets on all rate-limited endpoints and defeats other per-IP controls, enabling: (a) spam comment creation beyond the configured per-IP limit, (b) confirmation-email / notification flooding to supplied addresses, (c) high-volume outbound image fetching and resource consumption via the image proxy (its transport still blocks private/reserved destinations and DNS rebinding, so this is amplification, not new SSRF reach), (d) authentication-endpoint abuse, (e) where `--votes-ip` is enabled, defeating per-IP vote de-duplication (ballot stuffing), and (f) minting fresh anonymous identities and poisoning the stored comment IP and request logs, since the anonymous user ID is derived from `name + RemoteAddr`. The global concurrency ceiling and per-request timeouts remain, so availability impact is limited.\n\n### Resolution\nMitigation support was added in v1.16.2 (umputun/remark42#2116, follow-up in #2118). **Upgrading alone does not remediate the issue: `--trusted-proxy` must be configured.**\n\nThe fix adds `--trusted-proxy` / `TRUSTED_PROXY`. When set, the forwarding headers (`X-Real-IP`, then `CF-Connecting-IP`, then the leftmost public `X-Forwarded-For`) are honoured only when the direct TCP peer falls inside a trusted-proxy network; for a request from any other peer those headers are dropped and the real socket IP is used. When it is **unset**, the previous trust-all behaviour is preserved for backward compatibility and a startup warning is logged, so an un-configured v1.16.2 remains exploitable. `True-Client-IP` is no longer recognised. `TRUSTED_PROXY` takes a comma-separated list; on the command line, repeat `--trusted-proxy` per entry.\n\n**Required configuration:**\n- **Reachable directly from the internet:** set a value that no real client matches so the forwarding headers are always ignored, e.g. `--trusted-proxy=127.0.0.1/32` (only when Remark42 is not actually reached over loopback).\n- **Behind a reverse proxy:** point `--trusted-proxy` at the proxy\u0027s network only, block direct access to Remark42, and make the proxy **overwrite** `X-Real-IP` with the real client and discard client-supplied forwarding headers. A proxy that merely appends to `X-Forwarded-For`, or that forwards a client-supplied `X-Real-IP`, still lets the client choose the reported IP. Note that the shipped nginx manual sets `X-Real-IP` but does not strip a client `True-Client-IP`.\n- **Before v1.16.2:** strip `True-Client-IP`, `X-Real-IP`, and `X-Forwarded-For` at the edge and set a known-safe client-IP header.\n\nSee the [Trusted proxies and client IP docs](https://remark42.com/docs/configuration/parameters/#trusted-proxies-and-client-ip).",
  "id": "GHSA-56x6-q882-mf27",
  "modified": "2026-11-09T21:18:29Z",
  "published": "2026-11-09T21:18:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/security/advisories/GHSA-56x6-q882-mf27"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77463"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/pull/2116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/pull/2118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/commit/b1502801facd7782a1c70fd51f8ad5c2eb650d39"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/commit/e62b3c830d81659cf5d2687b0c8261da7d42fdab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/umputun/remark42"
    },
    {
      "type": "WEB",
      "url": "https://github.com/umputun/remark42/releases/tag/backend/v1.16.2"
    },
    {
      "type": "WEB",
      "url": "https://remark42.com/docs/configuration/parameters/#trusted-proxies-and-client-ip"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Remark42: Rate limit bypass via unconditional trust of X-Forwarded-For/X-Real-IP headers in direct-internet deployment"
}

CVE-2026-77463 (GCVE-0-2026-77463)

Vulnerability from cvelistv5 – Published: 2026-11-05 20:54 – Updated: 2026-11-10 04:20

Title

Remark42: Rate limit bypass via unconditional trust of X-Forwarded-For/X-Real-IP headers in direct-internet deployment

Summary

Remark42 is a self-hosted comment engine for blogs, articles, or any other place where readers can add comments. From 1.0.0 until 1.16.2, Remark42 globally trusts True-Client-IP, X-Real-IP, and X-Forwarded-For without verifying that the direct peer is a trusted proxy, and middleware.RealIP overwrites r.RemoteAddr before per-IP controls run. In a directly reachable deployment, or a proxy that forwards attacker-controlled headers, a remote attacker can rotate spoofed forwarding headers to obtain fresh token buckets for rate-limited endpoints, bypass vote de-duplication when --votes-ip is enabled, mint anonymous identities, and poison stored comment IPs and request logs. The global concurrent-request throttle and per-request timeouts still limit availability impact. Mitigation support is available in version 1.16.2, but operators must configure --trusted-proxy for the deployment topology.

Severity

6.5 (Medium)


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

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-11-10 04:19 UTC

CWE

CWE-348 - Use of Less Trusted Source
CWE-807 - Reliance on Untrusted Inputs in a Security Decision

Assigner

GitHub_M CNA under the mitre root

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

References

7 references

URL	Tags
https://github.com/umputun/remark42/security/advi…	x_refsource_CONFIRM
https://github.com/umputun/remark42/pull/2116	x_refsource_MISC
https://github.com/umputun/remark42/pull/2118	x_refsource_MISC
https://github.com/umputun/remark42/commit/b15028…	x_refsource_MISC
https://github.com/umputun/remark42/commit/e62b3c…	x_refsource_MISC
https://github.com/umputun/remark42/releases/tag/…	x_refsource_MISC
https://remark42.com/docs/configuration/parameter…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
umputun	remark42	Affected: >= 1.0.0, < 1.16.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-77463",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-11-10T04:19:02.667896Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-11-10T04:20:00.888Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/umputun/remark42/security/advisories/GHSA-56x6-q882-mf27"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "remark42",
          "vendor": "umputun",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.0.0, \u003c 1.16.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Remark42 is a self-hosted comment engine for blogs, articles, or any other place where readers can add comments. From 1.0.0 until 1.16.2, Remark42 globally trusts True-Client-IP, X-Real-IP, and X-Forwarded-For without verifying that the direct peer is a trusted proxy, and middleware.RealIP overwrites r.RemoteAddr before per-IP controls run. In a directly reachable deployment, or a proxy that forwards attacker-controlled headers, a remote attacker can rotate spoofed forwarding headers to obtain fresh token buckets for rate-limited endpoints, bypass vote de-duplication when --votes-ip is enabled, mint anonymous identities, and poison stored comment IPs and request logs. The global concurrent-request throttle and per-request timeouts still limit availability impact. Mitigation support is available in version 1.16.2, but operators must configure --trusted-proxy for the deployment topology."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-348",
              "description": "CWE-348: Use of Less Trusted Source",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-807",
              "description": "CWE-807: Reliance on Untrusted Inputs in a Security Decision",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-05T20:54:09.798Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/umputun/remark42/security/advisories/GHSA-56x6-q882-mf27",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/umputun/remark42/security/advisories/GHSA-56x6-q882-mf27"
        },
        {
          "name": "https://github.com/umputun/remark42/pull/2116",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/umputun/remark42/pull/2116"
        },
        {
          "name": "https://github.com/umputun/remark42/pull/2118",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/umputun/remark42/pull/2118"
        },
        {
          "name": "https://github.com/umputun/remark42/commit/b1502801facd7782a1c70fd51f8ad5c2eb650d39",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/umputun/remark42/commit/b1502801facd7782a1c70fd51f8ad5c2eb650d39"
        },
        {
          "name": "https://github.com/umputun/remark42/commit/e62b3c830d81659cf5d2687b0c8261da7d42fdab",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/umputun/remark42/commit/e62b3c830d81659cf5d2687b0c8261da7d42fdab"
        },
        {
          "name": "https://github.com/umputun/remark42/releases/tag/backend/v1.16.2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/umputun/remark42/releases/tag/backend/v1.16.2"
        },
        {
          "name": "https://remark42.com/docs/configuration/parameters/#trusted-proxies-and-client-ip",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://remark42.com/docs/configuration/parameters/#trusted-proxies-and-client-ip"
        }
      ],
      "source": {
        "advisory": "GHSA-56x6-q882-mf27",
        "discovery": "UNKNOWN"
      },
      "title": "Remark42: Rate limit bypass via unconditional trust of X-Forwarded-For/X-Real-IP headers in direct-internet deployment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-77463",
    "datePublished": "2026-11-05T20:54:09.798Z",
    "dateReserved": "2026-08-20T20:07:49.962Z",
    "dateUpdated": "2026-11-10T04:20:00.888Z",
    "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-56X6-Q882-MF27

Summary

Details

PoC

Impact

Resolution

CVE-2026-77463 (GCVE-0-2026-77463)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour