CVE-2026-74484

UNRATEDCVSS · not yet scoredTrending — 5 sources updated this week
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS v2: Exploit: 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:

binfmt_misc: don't let an 'F' entry pin its own instance

An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once the binfmt_misc superblock is shut down. If the interpreter lives on a mount that keeps that superblock alive the two pin each other:

binfmt_misc sb -> inode -> entry -> interp_file -> vfsmount -> binfmt_misc sb

TL;DR the file is never closed. Once the mount namespace is gone there is nothing left to unregister through either.

There are two ways to trigger this bug:

  • Point the interpreter at the instance itself. Its files are regular
files owned by the mounter and both bm_get_inode() and simple_fill_super() leave i_op at empty_iops. So notify_change() falls back to simple_setattr() and chmod +x works. We never set SB_I_NOEXEC and so open_exec() accepts it.
  • Use the instance as an overlayfs lower layer. The overlay superblock
holds a clone_private_mount() of every layer until it is destroyed and that clone is in no namespace. So umount_tree() never reaches it.

That's a DoS. And it isn't only the superblock that leaks. It pins the user namespace it was mounted in, so every iteration permanently eats one of the caller's user namespace charges.

So let's just do the sane thing. SB_I_NOEXEC makes open_exec() fail on the instance's own files and s_stack_depth makes overlayfs reject the layer before it ever takes a clone. That also covers the ecryptfs and fuse passthrough variants. What 'F' promises is unchanged.

The stable tag is narrower than the Fixes tags on purpose. Before sandboxed mounts this needed global root against the single instance everyone shares, and the change doesn't apply to those trees anyway.

Note that SB_I_NODEV is implicitly raised for userns mounts but raise it explicitly here as well.

CVSS v3
EchelonGraph score
Not yet assessedNo source has published severity data for this CVE yet — no CVSS score from NVD or a CNA, no GitHub advisory, and it is not in CISA KEV. This is not a rating of zero; we cannot assess it yet.
EG Score
EG Risk
EPSS PROB
0%
EPSS %ILE
7%
KEV
Not listed

Published

August 15, 2026

Last Modified

August 19, 2026

Vendor Advisories for CVE-2026-74484(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 19× in last 7d / 19× 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-20 22:56 UTCEPSS rescore
  2. 2026-08-19 17:04 UTCEPSS rescore
  3. 2026-08-19 07:20 UTCGHSA enrichment
  4. 2026-08-19 07:20 UTCNVD update
  5. 2026-08-19 07:14 UTCGHSA enrichment
  6. 2026-08-19 07:12 UTCMITRE cvelistV5
  7. 2026-08-18 13:49 UTCEPSS rescore
  8. 2026-08-18 13:49 UTCEPSS rescore
  9. 2026-08-17 13:47 UTCEPSS rescore
  10. 2026-08-17 06:24 UTCGHSA enrichment
  11. 2026-08-17 06:22 UTCNVD update
  12. 2026-08-17 05:40 UTCEG score recompute
  13. 2026-08-17 05:40 UTCGHSA enrichment
  14. 2026-08-17 05:39 UTCMITRE cvelistV5
  15. 2026-08-16 14:56 UTCEPSS rescore
  16. 2026-08-16 14:56 UTCEPSS rescore
  17. 2026-08-15 13:27 UTCNVD update
  18. 2026-08-15 12:40 UTCEG score recompute
  19. 2026-08-15 12:37 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-74484?
CVE-2026-74484 is a publicly disclosed vulnerability published on August 15, 2026. In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: don't let an 'F' entry pin its own instance An entry registered with 'F' opens its interpreter at registration time and holds that file until the entry is freed. Any entry nobody removes by hand only gets closed once…
When was CVE-2026-74484 disclosed?
CVE-2026-74484 was first published in the National Vulnerability Database on August 15, 2026, with the most recent update on August 19, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-74484 actively exploited?
CVE-2026-74484 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 93.5% of all scored CVEs.
How do I remediate CVE-2026-74484?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-74484, 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-74484

Explore →

Is Your Infrastructure Affected by CVE-2026-74484?

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