Go Team Weighs Turning Off Default MPTCP After Linux Flaw
Security / news
Go Team Weighs Turning Off Default MPTCP After Linux Flaw
The Go Security Team called a default change premature on Oct. 29, while commenters on golang/go issue 82717 split over keeping multipath TCP on.
Go's maintainers have not decided whether to stop opening multipath TCP listeners by default, days after a proposal to do so followed the Linux kernel flaw CVE-2026-98432. The Go Security Team called a default change "premature" in its Oct. 29 announcement, and the GitHub issue was still open and unassigned as of its latest comments on Oct. 31.
Go has enabled multipath TCP (MPTCP, a protocol that spreads one connection across several network paths) on Linux listen sockets since Go 1.24, according to the Go Security Team's announcement, which Alan Coopersmith of Oracle forwarded to the oss-security list. Neal Patel posted the original to golang-announce on Oct. 29 under the subject "[security] Protecting against CVE-2026-98432".
Why the default is in question
Anthropic's Frontier Red Team published a remote root exploit on Oct. 27 that works against Linux servers with an MPTCP listener. The Linux flaw sits in IPv4 TCP handling, so Go programs that open MPTCP listeners without the author asking for them become candidates by default.
A GitHub user named Fangliding opened golang/go issue 82717, "proposal: net: Disable MPTCP by default", on Oct. 29. The proposal points at commit 3d4daa3, which added the default, and concedes: "It is currently unknown whether this vulnerability is strongly related to MPTCP."
Atlas Security reports that Anthropic has not said why the MPTCP listener matters to its exploit, and that the CVE record does not mention MPTCP at all.
What the Go team and commenters said
The Go Security Team's position is that the fix belongs in the kernel: "The best fix for this vulnerability is to upgrade to a patched kernel version." It also warned that per-program mitigation is fragile, since "Accidentally leaving a single MPTCP listener exposed will still leave a system vulnerable."
On the issue, the GitHub user neild said the root cause "is not MPTCP-specific" and that setting GODEBUG=multipathtcp=0 disables MPTCP without fixing the kernel bug. On Oct. 30 neild also asked what justified the current default, noting that no other major networking library enables MPTCP by default. By Oct. 31 neild added that nginx leaves it off.
Others pushed back. The user dlsniper wrote that the bug is third-party and already fixed upstream, and that "Disabling this now will open the door to other requests." The user ianlancetaylor wrote: "I don't see any reason that a security issue should lead us to disable it."
Commenter matttbe argued from the kernel side that default listeners give clients handover between networks and network aggregation with no effect on plain TCP peers, and that the exploit was shown only in a lab. matttbe also said Linux maintainers prefer applications to opt in to MPTCP, while Go's style is to choose safer defaults. The user database64128 replied that nginx is a weak comparison because Go's defaults are generally sounder.
Four ways to turn MPTCP off today
| Method | Scope | Overrides |
|---|---|---|
GODEBUG=multipathtcp=0 | One process, at runtime | Overridden by per-socket settings |
godebug multipathtcp=0 in go.mod | One module, at build time | Overridden by per-socket settings |
//go:debug directive | One program, in source | Overridden by per-socket settings |
net.ListenConfig.SetMultipathTCP | One listener | Overrides the GODEBUG setting |
The first two come from the Go Security Team's announcement. The directive form is from neild's comment on the issue, and the per-socket calls, including net.Dialer.SetMultipathTCP, are named in the announcement as taking precedence.
None of them closes the kernel hole. Linux 4.4 and later are affected until patched, and Atlas's status page lists upstream fixes in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. The Go team also said it is "possible that systems with no MPTCP listeners are vulnerable to similar attacks", per Atlas's summary.
The urgency is also tempered by exploitation status. Atlas says CVE-2026-98432 is not in CISA's exploited-vulnerabilities catalog, which listed GitLab's CVE-2026-97229 on Oct. 29 and two Ivanti Connect Secure flaws on Oct. 30, the product behind an earlier root chain. Seven public GitHub repositories include a race trigger or proof of concept, according to Atlas.
The Go team has said further discussion will happen on the issue. No release or date is attached to any change in the default.
Sources
More in Security
- 01Anthropic's Claude Exploit Chains Hit Five Targets, Each With LimitsThe Frontier Red Team's Oct. 27 post covers Chrome, Safari, Android, Windows and Linux, but only the Chrome and Linux results reach code execution.
- 02A Tampered Claude Code Extension Sat in Cursor's Marketplace for 11 Hours and Left an SSH Key BehindVersions 2.1.312 and 2.1.313 carried a 7,386-byte loader that plants an attacker key and a reverse tunnel. Uninstalling the extension does not remove either.
- 03Ivanti Connect Secure Zero-Day Chain Gave Root on a Patched VPN, and the Integrity Checker Misses ItVolexity dates exploitation to October 3, ten days before Ivanti's advisory; the root escalation step has no CVE and no fix in the sources reviewed.
- 04Alpine Logged GitLab CVE-2026-97229 Attacks Nine Days Before CISA Listed ItAlpine's incident report shows the CVSS 10.0 flaw was exploited against its own server on Oct. 20 and 21, and that two GitLab 19.3 builds it ran still carried the bug.