CVE-2026-74359

HIGHPre-NVD 7.87.8—
EchelonGraph scoreHIGH confidence

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

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
7.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 7.8Exploit: 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:

configfs_lookup(): don't leave ->s_dentry dangling on failure

Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all.

We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it.

However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry.

Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free...

This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...

CVSS v3
7.8
EG Score
7.8(high)
EG Risk
40(Track)
EG Risk 40/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
Severity78% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
3%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 17, 2026

Advisory Details (7)

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

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

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

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

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

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

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

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

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

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/57088b06109f3222963c639d8d743f42c2899b13
generic

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/3e83b2203aa59bd279e4f677ec793d49dc9d019e
generic

configfs_lookup(): don't leave ->s_dentry dangling on failure - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/10da12d352b7b2bb330a8609fdda9a58bf0e9856

Vendor Advisories for CVE-2026-74359(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 28× in last 7d / 28× 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:54 UTCEG score recompute
  2. 2026-08-21 06:54 UTCGHSA enrichment
  3. 2026-08-20 22:56 UTCEPSS rescore
  4. 2026-08-20 18:53 UTCGHSA enrichment
  5. 2026-08-20 06:54 UTCGHSA enrichment
  6. 2026-08-19 18:54 UTCEG score recompute
  7. 2026-08-19 18:54 UTCGHSA enrichment
  8. 2026-08-19 17:04 UTCEPSS rescore
  9. 2026-08-19 06:54 UTCGHSA enrichment
  10. 2026-08-18 18:56 UTCGHSA enrichment
  11. 2026-08-18 06:56 UTCGHSA enrichment
  12. 2026-08-17 18:57 UTCEG score recompute
  13. 2026-08-17 18:57 UTCGHSA enrichment
  14. 2026-08-17 13:47 UTCEPSS rescore
  15. 2026-08-17 06:26 UTCEG score recompute
  16. 2026-08-17 06:26 UTCGHSA enrichment
  17. 2026-08-17 05:56 UTCEG score recompute▲ 7.80
  18. 2026-08-17 05:56 UTCGHSA enrichment
  19. 2026-08-17 05:54 UTCMITRE cvelistV5CVSS v3 → 7.8 · severity → HIGH
  20. 2026-08-17 05:26 UTCEG score recompute
  21. 2026-08-17 05:26 UTCGHSA enrichment
  22. 2026-08-17 05:24 UTCMITRE cvelistV5
  23. 2026-08-16 14:56 UTCEPSS rescore
  24. 2026-08-16 14:56 UTCEPSS rescore
  25. 2026-08-16 02:15 UTCEPSS rescore
Show 3 more
  1. 2026-08-15 06:23 UTCNVD update
  2. 2026-08-15 06:15 UTCEG score recompute
  3. 2026-08-15 06:12 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-74359?
CVE-2026-74359 is a high vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: configfslookup(): don't leave ->sdentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the…
When was CVE-2026-74359 disclosed?
CVE-2026-74359 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-74359 actively exploited?
CVE-2026-74359 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 97.3% of all scored CVEs.
What is the CVSS score of CVE-2026-74359?
CVE-2026-74359 has a CVSS v3 base score of 7.8 (NVD).
How do I remediate CVE-2026-74359?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-74359, 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-74359

Explore →

Is Your Infrastructure Affected by CVE-2026-74359?

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

Start Free Scan →Browse All CVEs