CVE-2026-99281

UNRATEDCVSS · not yet scoredTrending — 4 sources updated this week

Also known asEUVD-2026-119281 (ENISA EUVD) · GHSA-cfrf-w8r8-rf8x (GitHub Security Advisories)Source: ENISA EUVD

—
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • No CVSS published and no exploitation signals yet
CISA-KEV: Not listedEPSS PROB: —CVSS v2: —Exploit: None knownExposed services: Not assessed

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

The CVE record's CNA (kernel.org) lists Linux versions before 2.6.18 and 7.4-rc1 and later as unaffected. No release containing a fix is confirmed on record.

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

tun: Require CAP_NET_ADMIN to attach to an ownerless device

Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.")

The idea was to allow the permissions on /dev/net/tun to be relaxed to 0666 and thus allow owners of tun devices assigned with TUNSETOWNER to actually open it and get at their devices.

What we missed at the time was that persistent devices with *no* owner were already essentially world-consumable, and anyone who could open the device node could also attach to those.

Even then, using persistent devices with no explicitly set owner — on the (false) presumption that CAP_NET_ADMIN would be required to open them — wasn't an egregious userspace bug. There are cases where it does make sense to separate the creation/configuration of the netdevice, from the process which shovels packets into it.

Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e ("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message noted that if both uid and gid are set, both have to match (in itself a bizarre choice) — but still not that with *neither* set, no permission at all was required.

Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed new queues to be attached to a device from the moment of its creation, with no way for userspace to close the race between creation and a subsequent TUNSET{OWNER,GROUP}.

In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried to fix things to be saner: only require the user *or* the group to match, in line with standard POSIX permissions, and require CAP_NET_ADMIN if neither the user nor group authorised the access (although it put the CAP_NET_ADMIN check first, and would wrongly have reported the capability as having been used even when it was not).

That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group permission check") due to allegedly causing a regression in an selinux test suite which *expected* the attachment to succeed when authorised by none of user, group, nor CAP_NET_ADMIN: https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/

We should not break UAPI. But we don't have to consider an selinux test case which deliberately exercises a security flaw to be UAPI worth preserving either. To which end, I have fixed it in selinux-testsuite commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the relabel tests").

So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been assigned an owner or group, while leaving the weird tun ownership model as it was (user *and* group have to match, if both are set). If someone still wants to fix the latter (which wasn't actually the reason the previous attempt was reverted), they can do it under separate cover.

Permit attaching to an existing device only if an owner and/or group was set and the caller matches all that were set, or if the caller has CAP_NET_ADMIN. The only behavioural change is that a device with no owner or group now requires CAP_NET_ADMIN to attach — precisely the loophole we want to close.

And put the CAP_NET_ADMIN check in the right place this time.

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
—
EPSS %ILE
—
KEV
Not listed

What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)

EG Severity
Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
EG Likelihood
Unknown (no EPSS on record)Unknown, not low: FIRST has published no EPSS probability for this CVE.
Confirmed exploitation
None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
EG Priority
No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.

BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.

No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.

The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it

Published

November 7, 2026

Last Modified

November 7, 2026

References (3)

Vendor Advisories for CVE-2026-99281(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 4× in last 7d / 4× in last 30d)

Each row is a time one of our pipelines fetched, updated or re-scored this CVE. 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. An arrow marks a change the record states ("CVSS v3 → 9.1"); EPSS and GHSA rows show the values recorded at that time, not what changed (EPSS values are rounded; hover one for the exact figures). Most recent first.

  1. 2026-11-07 15:04 UTCENISA EUVD ID recordedEUVD-2026-119281 · Source: ENISA EUVD
  2. 2026-11-07 14:26 UTCNVD update
  3. 2026-11-07 14:16 UTCEG score recompute
  4. 2026-11-07 14:16 UTCMITRE cvelistV5first tracked

Frequently asked(3)

What is CVE-2026-99281?
CVE-2026-99281 is a vulnerability whose severity is not yet rated; its CVE record was published on November 7, 2026. In the Linux kernel, the following vulnerability has been resolved: tun: Require CAP_NET_ADMIN to attach to an ownerless device Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") The idea was to…
When was the CVE record for CVE-2026-99281 published?
The CVE record for CVE-2026-99281 was published on November 7, 2026. That is the record's publication date; the vulnerability itself may have been made public earlier. EchelonGraph's copy of the record carries a last-modified date of November 7, 2026; the record at its source may have been updated since.
How do I remediate CVE-2026-99281?
No fix for CVE-2026-99281 is confirmed yet. Until one is published, restrict network exposure of the affected system or apply the vendor's mitigation — for example, keep it off the internet or limit it to trusted networks — and watch the vendor's advisory for the fix. The CVE record's CNA (kernel.org) lists Linux versions before 2.6.18 and 7.4-rc1 and later as unaffected. No release containing a fix is confirmed on record. The vendor advisories EchelonGraph has for CVE-2026-99281 are linked in the Vendor Advisories panel on this page.

Dependency Blast Radius

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

Explore →

Is Your Infrastructure Affected by CVE-2026-99281?

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

Book a Demo →Browse All CVEs