CVE-2026-72021

HIGHPre-NVD 8.28.2
EchelonGraph scoreHIGH confidence

Score 8.2 from GitHub Security Advisory (severity: HIGH) published 2026-08-15. a secondary CVSS source baseline 8.2; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
8.2EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 1%CVSS: 8.2Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

In the Linux kernel, the following vulnerability has been resolved:

ipvs: use parsed transport offset in SCTP state lookup

set_sctp_state() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ip_vs_fill_iph_skb(), where ipv6_find_hdr() has already skipped extension headers and found the real transport header.

This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctp_conn_schedule(), but set_sctp_state() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.

Use the parsed transport offset passed down from ip_vs_set_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.

CVSS v3
8.2
EG Score
8.2(high)
EG Risk
42(Track)
EG Risk 42/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity82% × 45%
Exploitation1% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
1%
EPSS %ILE
45%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (8)

Auto-updated Aug 17, 2026
No patch confirmed yet.
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/e5d0bb8871668f20de8f3c94b5ae3f372346bc6e
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/d2b8b1557ec07ea1bb5dddbceaf4dfe63d388e27
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/a4a2d2e483d79cc2ad3a170674cf159644acf22b
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/9f94573ab962a9e81954b755da016fa3cd2f5039
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/9cb5ac594ca76d3a71803b23b74c835b0721e628
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/2f75c0faa3361b28e36cc0512b3299e163e25789
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/290e9e8389b556efc603522e28bd1543846aa336
generic

ipvs: use parsed transport offset in SCTP state lookup - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/247d055504dcc852e539b9f7f30d19f9741474bf

Vendor Advisories for CVE-2026-72021(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 32× in last 7d / 32× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-21 06:05 UTCEG score recompute
  2. 2026-08-21 06:05 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 18:14 UTCGHSA enrichment
  5. 2026-08-20 06:23 UTCGHSA enrichment
  6. 2026-08-19 18:32 UTCEG score recompute
  7. 2026-08-19 18:31 UTCGHSA enrichment
  8. 2026-08-19 17:04 UTCEPSS rescore
  9. 2026-08-19 06:40 UTCGHSA enrichment
  10. 2026-08-18 18:46 UTCEG score recompute
  11. 2026-08-18 18:46 UTCGHSA enrichment
  12. 2026-08-18 13:49 UTCEPSS rescore
  13. 2026-08-18 13:49 UTCEPSS rescore
  14. 2026-08-18 06:54 UTCGHSA enrichment
  15. 2026-08-17 19:03 UTCEG score recompute
  16. 2026-08-17 19:02 UTCGHSA enrichment
  17. 2026-08-17 13:47 UTCEPSS rescore
  18. 2026-08-17 06:30 UTCEG score recompute
  19. 2026-08-17 06:30 UTCGHSA enrichment
  20. 2026-08-17 06:01 UTCEG score recompute 8.20
  21. 2026-08-17 06:01 UTCGHSA enrichment
  22. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 8.2 · severity → HIGH
  23. 2026-08-17 05:34 UTCEG score recompute
  24. 2026-08-17 05:34 UTCGHSA enrichment
  25. 2026-08-17 05:24 UTCMITRE cvelistV5
Show 7 more
  1. 2026-08-16 14:56 UTCEPSS rescore
  2. 2026-08-16 14:56 UTCEPSS rescore
  3. 2026-08-16 02:15 UTCEPSS rescore
  4. 2026-08-15 06:46 UTCGHSA enrichment
  5. 2026-08-15 06:23 UTCNVD update
  6. 2026-08-15 06:19 UTCEG score recompute
  7. 2026-08-15 06:02 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-72021?
CVE-2026-72021 is a high vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: ipvs: use parsed transport offset in SCTP state lookup setsctpstate() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding…
When was CVE-2026-72021 disclosed?
CVE-2026-72021 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-72021 actively exploited?
CVE-2026-72021 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 1% probability of exploitation in the next 30 days, which ranks it in the top 54.8% of all scored CVEs.
What is the CVSS score of CVE-2026-72021?
CVE-2026-72021 has a CVSS v3 base score of 8.2 (NVD).
How do I remediate CVE-2026-72021?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-72021, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-72021

Explore →

Is Your Infrastructure Affected by CVE-2026-72021?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.