Unvalidated user pointers in RTIO syscall verifiers allow a user-mode thread to write kernel memory

MonitorNot in CISA KEVCVE-2026-16511CWE-822CWE-787

Not confirmed exploited. No WAF vendor names it yet.

Edge rules

0/9

Our test

No exploit yet

CVSS

8.8

EPSS

—

Posts, 14d

Published

2026-11-04

What it is

Two RTIO syscall verifiers, in subsys/rtio/rtio_syscalls.c (subsys/rtio/rtio_handlers.c before v4.3.0), did not validate user-supplied pointers before the kernel wrote through them. z_vrfy_rtio_sqe_cancel() performed no validation at all. It passed the caller's struct rtio_sqe pointer straight to z_impl_rtio_sqe_cancel(), which converts it with CONTAINER_OF to a struct rtio_iodev_sqe, ORs RTIO_SQE_CANCELED (BIT(3)) into its 16-bit flags field in supervisor mode, then loads its next pointer and repeats until that pointer is NULL. The syscall takes no RTIO context argument, so it needs no object grant: any user-mode thread on a CONFIG_USERSPACE build can set that bit in a 16-bit word at an address of its choosing in kernel memory, and the kernel continues the write along whatever pointer chain it finds at the corresponding offset. Setting chosen bits in kernel data structures, such as object permission or thread state fields, can be used to escalate privilege from user mode. z_vrfy_rtio_sqe_copy_in_get_handles() validated its RTIO context and the input SQE array, but only NULL-checked the handle out-parameter before writing a kernel SQE pointer through it, with no K_SYSCALL_MEMORY_WRITE check. A user thread that holds a granted RTIO context can therefore make the kernel store a pointer value at an arbitrary address. The fixes validate the handle out-parameter as writable, bound the cancel handle to real submission-pool storage, and require permission on the RTIO context that owns the matching pool. Without that last check a bounded handle still let any user thread cancel submissions belonging to other contexts, silently aborting their I/O. Systems built without CONFIG_USERSPACE or without CONFIG_RTIO are unaffected.

Read the full descriptionShow less

From the CVE record · CVE-2026-16511 ↗

MonitorLast checked 2026-11-04

The risk

No edge WAF vendor names it in a changelog, so default managed rules may or may not catch it. Exploitation in the wild is not established by CISA KEV.

Who is affected

Teams running zephyrproject zephyr (3.4.0 to before 4.3.2; 4.4.0 to before 4.5.0).

Next steps

Apply the vendor's fix; the advisory lists the affected and fixed versions. Fix commit b1092a0aa7fb ↗
Do not rely on WAF defaults: no edge vendor names this CVE. Restrict access to the vulnerable component or add a custom rule until it is patched. Edge coverage
Check which WAF sits in front of your site and whether it covers this CVE. Check your domain

Edge coverage

Claimed by vendors

CloudflareNo public claimNot named AWSNo public claimNot named Microsoft AzureNo public claimNot named Google CloudNo public claimNot named FastlyNo public claimNot named VercelNo public claimNot named F5No public claimNot named AkamaiNo public sourceNo public changelog OWASP CRSNo public claimNot named

Attack traffic on Cloudflare

Cloudflare Radar

Broken Authentication14% of mitigated layer 7 attacks, 7 days
Rules for named CVEs5.6% of mitigated layer 7 attacks, 7 days

Radar groups Cloudflare's WAF managed rules by category; it does not publish counts per CVE. These shares show how much attack traffic targets this kind of flaw across Cloudflare's network (28-day trend). They are not compromised systems, and seeing few attempts on Cloudflare does not prove an absence elsewhere. Radar data as of 2026-11-04. Radar ↗

Check your exposure with an agent

Read-only

Copy this into an agent with access to your infrastructure. It asks for an evidence-based, read-only assessment: affected systems, exposure, compensating controls and what is still unknown. It does not scan or change anything by itself.

Prompt12 lines

Assess whether the infrastructure available to you is affected by CVE-2026-16511 (Unvalidated user pointers in RTIO syscall verifiers allow a user-mode thread to write kernel memory). Perform a read-only assessment within your authorized access. Do not send exploit traffic, scan third-party systems, change configuration or restart services.

1. Verify the CVE record at https://www.cve.org/CVERecord?id=CVE-2026-16511 and the vendor advisories (https://github.com/zephyrproject-rtos/zephyr/commit/b1092a0aa7fbe67118ca4b08d5b4e54b34709a6e, https://github.com/zephyrproject-rtos/zephyr/commit/95c355c425763fbe5e735b9ef54dacce2c4ce21f, https://github.com/zephyrproject-rtos/zephyr/commit/3f244c1709ec0be533ed83d34998e942fc4da399). Establish affected and fixed versions, including vendor backports. The record lists: zephyrproject zephyr: affected 3.4.0 to before 4.3.2; 4.4.0 to before 4.5.0. Cite sources and retrieval dates; flag anything you cannot verify.
2. Inventory deployments of zephyrproject zephyr: asset, environment, owner where known, installed version or build, and how you confirmed it (package metadata, a version endpoint, image tags). An image tag alone does not prove the running version.
3. Identify which deployments are reachable from the internet or untrusted networks, and through which paths (direct origin, load balancer, CDN or WAF).
4. Assess compensating controls separately from patch status. Current edge WAF coverage for this CVE: no edge WAF vendor names it. Live data: https://cve.vigilbase.com/api/v1/cves/CVE-2026-16511. Check whether the rule is enabled and in block mode on each path, and whether any path bypasses the WAF. A WAF rule is not a patch.
5. Check logs on exposed instances for requests matching the public exploit, if your access allows.

Return a short summary and a table: asset | version/build | assessment (affected, fixed, not applicable, unknown) | exposure | compensating control | evidence | next action. List what you could not assess and the access needed to resolve it. Do not infer absence of compromise from patch status or a lack of alerts.

Remediation guidance: Apply the vendor's fix; the advisory lists the affected and fixed versions. Do not rely on WAF defaults: no edge vendor names this CVE. Restrict access to the vulnerable component or add a custom rule until it is patched.
More: https://cve.vigilbase.com/cve/CVE-2026-16511

Sources

Cited

CVE record

CVSS 3.1 8.8 (high). Weakness: CWE-822, CWE-787, CWE-862.

CVE-2026-16511 ↗NVD ↗

Vendor advisory

Fixes and mitigations the CVE record links to. Check affected builds against the vendor, including backports.

Fix commit b1092a0aa7fb ↗Fix commit 95c355c42576 ↗Fix commit 3f244c1709ec ↗

Exploit evidence

No public exploit code found in Exploit-DB, Metasploit, nuclei-templates or GitHub. That does not mean none exists.

CISA KEV

Not in the KEV catalog (catalog 2026.11.03, checked 2026-11-04). Absence from KEV is not evidence that it cannot be exploited.

CISA KEV catalog ↗

WAF vendor statements

No edge vendor changelog names it.

Ask Vigil

AI · answers from this page

Ask about CVE-2026-16511: who's covered, what to patch first, how vendors compare. I cite sources and won't help with attacks.

Severity, decoded

CVSS 3.1

8.8High

High · 8.8 / 10

Exploitable with local access, with low privileges and no user interaction, leading to full loss of confidentiality, integrity and availability, and the impact can reach components beyond the vulnerable one.

Needs local accessAny user loginNo user actionWorks reliablySpreads beyond the appFull compromise

How the score is built8 metrics

Attack vectorAn attacker needs local access, or must trick a user into opening something on the machine.
Local
Attack complexityNo special conditions are needed; the attack works reliably.
Low
Privileges requiredThe attacker needs an ordinary user account.
Low
User interactionNo one has to click or open anything; the attack works on its own.
None
ScopeThe attack can spread beyond the vulnerable component to other parts of the system.
Changed
Confidentiality impactAn attacker can read all data the affected component holds, or the most sensitive parts of it.
High
Integrity impactAn attacker can change any data or files the affected component protects.
High
Availability impactAn attacker can take the component down completely or keep it from serving anyone.
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Public exploits

None found

0 Metasploit0 Exploit-DB0 Scanner template0 GitHub PoCs

No exploit in Exploit-DB or Metasploit, and no scanner template. That lowers, but doesn't remove, the chance of mass exploitation.

Timeline

2026-11-04
CVE published
CVE List
2026-11-04
First social mention we saw

Vendor statements

Quoted

CloudflareWAF Managed RulesNo public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Each row gives the rule ID and its default action. The feed starts in January 2025, so older rules are missing.

AWSAWS WAF Managed RulesNo public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. AWS often describes a vulnerability without naming its CVE (for example "Log4j"). We count only entries that name the CVE, so AWS coverage is understated.

Microsoft AzureFront Door and Application Gateway WAF (DRS)No public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. The rule tables name CVEs but carry no dates, so Azure is left out of every time-to-rule figure.

Google CloudCloud Armor preconfigured WAF rulesNo public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Google names few CVEs: the release notes start in May 2024 and the rules reference lists CVEs without dates. Its cve-canary rules are opt-in.

FastlyNext-Gen WAF virtual patchesNo public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. The feed holds only the latest 25 changes, so history builds up from the day we started reading it.

VercelVercel WAF (platform rules)No public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Vercel posts about the vulnerabilities it ships platform-wide rules for, on by default for every project, with no rule ids. When a post limits its claim to some advisories, we count only the ones it names. Projects not on Vercel get nothing from these rules.

F5Attack signatures (Distributed Cloud WAF)No public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. Each signature lists the CVEs it references, with its id and date. F5 does not state a default action; signatures enforce once staging ends in your policy.

AkamaiApp & API Protector (Adaptive Security Engine)No public source

This vendor publishes no machine-readable rule changelog we can check.

OWASP CRSCore Rule Set (open source, used inside many WAFs)No public claim

We found no public statement from this vendor naming this CVE. That is not proof of no protection: generic rules may still catch it. CRS rarely names CVEs: it relies on generic detections. Our own lab measures what it actually blocks.