CVE-2026-74619

UNRATEDCVSS · not yet scoredTrending — 3 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:

ovl: don't warn when the mount is completed from another user namespace

fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIG_CMD_CREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket.

Completing a context from another user namespace is allowed on purpose. vfs_cmd_create() authorizes the create with mount_capable(), which for FS_USERNS_MOUNT checks ns_capable(fc->user_ns, CAP_SYS_ADMIN), and that succeeds for a task holding CAP_SYS_ADMIN in an ancestor of fc->user_ns. So an unprivileged task can reach the WARN_ON() in ovl_fill_super(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIG_CMD_CREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:

WARNING: fs/overlayfs/super.c:1551 at ovl_fill_super+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: get_tree_nodev+0x71/0xa0 ovl_get_tree+0x15/0x20 [overlay] vfs_get_tree+0x2a/0x100 vfs_cmd_create+0x60/0xf0 __do_sys_fsconfig+0x4b2/0x500

The child needs the mount namespace because fsopen() itself gates on may_mount(), which asks for CAP_SYS_ADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check.

It is a WARN_ON() and not a WARN_ON_ONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with panic_on_warn.

Keep refusing the mount and stop warning about it. ovl_parse_param() already spells a user namespace check this way for Opt_override_creds.

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
6%
KEV
Not listed

Published

August 22, 2026

Last Modified

August 22, 2026

References (5)

Vendor Advisories for CVE-2026-74619(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 9× in last 7d / 12× 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-30 01:22 UTCEPSS rescore
  2. 2026-08-29 06:49 UTCGHSA enrichment
  3. 2026-08-28 21:42 UTCEPSS rescore
  4. 2026-08-27 14:25 UTCEPSS rescore
  5. 2026-08-26 14:47 UTCEPSS rescore
  6. 2026-08-25 23:37 UTCEG score recompute
  7. 2026-08-25 23:37 UTCGHSA enrichment
  8. 2026-08-25 13:49 UTCEPSS rescore
  9. 2026-08-24 14:18 UTCEPSS rescore
  10. 2026-08-22 16:24 UTCNVD update
  11. 2026-08-22 15:42 UTCEG score recompute
  12. 2026-08-22 15:35 UTCMITRE cvelistV5first tracked

Frequently asked(4)

What is CVE-2026-74619?
CVE-2026-74619 is a publicly disclosed vulnerability published on August 22, 2026. In the Linux kernel, the following vulnerability has been resolved: ovl: don't warn when the mount is completed from another user namespace fsopen() records the caller's user namespace in fc->user_ns and hands back an ordinary file descriptor. Nothing ties the task that calls…
When was CVE-2026-74619 disclosed?
CVE-2026-74619 was first published in the National Vulnerability Database on August 22, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-74619 actively exploited?
CVE-2026-74619 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.7% of all scored CVEs.
How do I remediate CVE-2026-74619?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-74619, 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-74619

Explore →

Is Your Infrastructure Affected by CVE-2026-74619?

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

Start Free Scan →Browse All CVEs