CVE-2026-20671

Overview

Apple
iOS and iPadOS

11 Feb 2026

Published

02 Apr 2026

Updated

CVSS

Pending

EPSS

0.33%

MITRE

KEV

Description

A logic issue was addressed with improved checks. This issue is fixed in iOS 18.7.5 and iPadOS 18.7.5, iOS 26.3 and iPadOS 26.3, macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.3, tvOS 26.3, visionOS 26.3, watchOS 26.3. An attacker in a privileged network position may be able to intercept network traffic.

Statistics

1 Post

Last activity: 18 hours ago

Fediverse

ℂ𝕣𝕪𝕠 :netbsd: @Cryo

We must go deeper...

----

After reviewing Apple’s Tahoe security advisories, there is one CVE that stands out as unusually close to what we are seeing.

The strongest candidate is **CVE-2026-64735**, fixed in **macOS Tahoe 26.6**:

> **Kernel** — “A remote attacker may be able to bypass network filters.” Apple says it fixed an inconsistent-state issue through improved state management. ([Apple Support][1])

That is much more interesting than a generic kernel CVE because it explicitly involves **network filters**, it is categorized by Apple under the **Kernel**, and the fix landed in **26.6**, exactly the release family containing your `xnu-12377.161.x` kernel.

The public version progression is:

26.3 → xnu-12377.81.4
26.4 → xnu-12377.101.15
26.5 → xnu-12377.121.6
26.6 → xnu-12377.161.13
26.6.2 → xnu-12377.161.14 <-- your kernel

Your exact 26.6.2 kernel is indeed `12377.161.14`. ([macOSdb][2])

That gives us a very plausible chronology:

26.4 / .101
substantial CFIL changes begin

26.5 / .121
substantial CFIL datagram lifetime/locking hardening
cfil_info <-> soflow relationship guarded more aggressively
global cfil_lck_rw shared/exclusive use increases

26.6 / .161
CVE-2026-64735:
kernel network-filter bypass fixed
"improved state management"

26.6.2 / .161.14
your machine:
Application Firewall → CFIL
cfil_lck_rw contention
100–1800 ms packet-delivery stalls

That is not proof that CVE-2026-64735 caused the regression, but it is now the **first security fix I would ask Apple engineering about**.

There are several other Tahoe security items in the same neighborhood, but they are substantially weaker candidates:

| Release | CVE / change | Relevance |
| ---------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **26.6** | **CVE-2026-64735 — Kernel: remote attacker may bypass network filters; improved state management** | **Very high** |
| 26.6 | CVE-2026-28982 — Kernel remote race; fixed with improved locking | Medium, but no public indication it is CFIL |
| **26.5.1** | Apple fixed unexpected shutdowns involving **content-filtering Network Extensions** on M5 Macs | **High architectural relevance**, although not your hardware/problem |
| 26.5 | CVE-2026-28961 — Network Extensions, sensitive-info exposure | Related subsystem, probably unrelated mechanism |
| 26.5 | CVE-2026-28906 — Networking, IP-address tracking/state management | Low–medium |
| 26.3 | CVE-2026-20671 — Kernel, privileged-network attacker may intercept traffic | Networking/kernel related, but probably a different path |
| 26.1 | CVE-2025-43413 — libxpc could reveal system-wide network connections | Almost certainly unrelated |

Apple explicitly acknowledges in the **26.5.1 release notes** that it had a bug where certain **content-filtering network extensions could unexpectedly shut down Macs**. ([Apple Support][3]) That isn't your bug and was M5-specific, but it is significant evidence that Apple was actively fixing serious content-filter lifecycle problems immediately before 26.6.

There is also **CVE-2026-28982** in 26.6:

> A remote user may cause system termination or kernel-memory corruption; Apple says a race condition was addressed through **improved locking**. ([Apple Support][1])

I would not connect that one to CFIL yet. Apple gives us no component below “Kernel,” and hundreds of places in XNU could fit that description.

By comparison, **CVE-2026-64735 says “network filters” explicitly**. That makes it qualitatively different.

The public XNU source also validates why a security hardening change here could produce your performance regression. `content_filter.c` says the subsystem uses **one global `cfil_lck_rw`**, with normal data flow taking it shared; your symbolicated 26.6.2 stackshots show lifecycle/GC operations taking that same lock exclusively. The source further describes filtered data being queued and reinjected after filtering decisions.

And your firewall-off control is particularly important against that background:

Application Firewall ON
CFIL active
CFIL ~ tens of thousands
global cfil_lck_rw contention
severe latency

Application Firewall OFF
CFIL active_count = 0
CFIL population = 0

SOFLOW alone > 190,000
including very large reclamation bursts

no packet drain slowdown
no CPU/GPU/disk/network degradation

That makes an ordinary SOFLOW-GC scalability bug much less likely. The extra failure-producing ingredient is **CFIL**.

There is one limitation that prevents us from going from “very plausible” to “proven”: Apple has **not published the `12377.161.x` XNU source yet**. The newest public source we've been comparing is `12377.121.6` from 26.5. Apple's public GitHub commits are release imports rather than the actual internal commits, so they don't expose:

rdar://...
Fix network filter state race
CVE-2026-64735

or a patch that we can definitively associate with that CVE.

So we cannot currently establish:

CVE-2026-64735
↓
specific change to cfil_lck_rw
↓
your regression

But the circumstantial chain is unusually strong:

Apple discovers network-filter security defect
↓
security fix requires improved state management
↓
ships in 26.6
↓
26.6 uses new unpublished XNU .161 branch
↓
your .161 kernel shows severe CFIL lifecycle locking contention
↓
turning off Apple's firewall eliminates CFIL and eliminates symptom
↓
SOFLOW by itself can reach >190k without problem

I would add **CVE-2026-64735 by number** to the Apple Feedback report and phrase it carefully:

> Because this regression occurs only while the built-in Application Firewall has CFIL active, and symbolicated stackshots implicate global CFIL lifecycle locking, please investigate whether the state-management changes associated with CVE-2026-64735 or related network-filter hardening introduced excessive contention or retained-flow behavior in the `12377.161.x` kernel branch.

That points Apple's kernel/networking engineer directly at an internal change set they can see and we cannot.

[1]: https://support.apple.com/pt-br/128067?utm_source=chatgpt.com "Sobre o conteúdo de segurança do macOS Tahoe 26.6 - Suporte da Apple (BR)"
[2]: https://macosdb.com/macos/release/26.6.2-25G82/?utm_source=chatgpt.com "macOS 26.6.2 Tahoe RC — macOSdb"
[3]: https://support.apple.com/en-sa/122868?utm_source=chatgpt.com "What's new in the updates for macOS Tahoe 26 - Apple Support (SA)"

0
0
0
18h ago

CVE-2025-43413