On 15 October 2026 the Linux kernel's own CVE Numbering Authority scored a new flaw, CVE-2026-98432, at 9.8, Critical [1]. By 4 November, three vendors, SUSE, Oracle Linux, and Amazon Linux, had each independently scored the identical upstream patch. Each landed at 8.1, Important, on their own pages [2][3][4]. The National Vulnerability Database is the register most dashboards treat as neutral. It has not scored this flaw at all. Its own application programming interface still returns a status of "Received," and the one metric sitting in its record is borrowed, unscored, from the kernel's own number [5].
Nobody disputes what the flaw does. A race condition in the way the kernel frees memory during an ordinary IPv4 TCP handshake lets an unauthenticated attacker crash a server or corrupt its memory. No special configuration is required. The entire 1.7 point gap between 9.8 and 8.1 sits inside one sub-score of the Common Vulnerability Scoring System: Attack Complexity. Call the race easy to win and the flaw is 9.8; call it hard and it is 8.1.
An enterprise architect writing a patching service level agreement does not get a vote on which of those two numbers is correct. What the architect does control, usually without realising it, is which field the SLA actually reads.
What the Database Actually Says
CVE-2026-98432 lives in a narrow corner of the kernel: the handling of IP options attached to a connection request, ireq_opt, during a TCP handshake. A retransmitted connection request can free that memory while another code path is still using it, a use-after-free. The kernel's own fix was committed by Eric Dumazet and applied by Jakub Kicinski. It defers the memory's release past a grace period, so nothing can touch it while it remains live [6].
The confusion starts with the words "NVD hasn't scored it." In one sense, it has. The single Common Vulnerability Scoring System metric sitting in the National Vulnerability Database's own record is marked "Secondary," and its source is not a database analyst but kernel.org itself [5]. The 9.8 a dashboard reads off that database is the kernel maintainers' own figure. It is routed through a field built for somebody else's analysis, and left there because nobody at the database has reviewed it. Red Hat's own page makes the same point from the other direction, listing the National Vulnerability Database's score as "N/A" [7].
Red Hat's page agrees with the kernel's 9.8 [7]. SUSE, Oracle Linux, and Amazon Linux all score the same upstream commit 8.1 on their own pages, each independently, each landing on the lower Attack Complexity reading of the identical race condition [2][3][4]. SUSE separately publishes the newer Common Vulnerability Scoring System version 4.0 figure as 9.2, a different scale again [2].
None of this is a vendor conspiracy or a database failure. It is four reasonable technical judgements about how hard one race condition is to win in practice, recorded in four different fields, each of which some automation somewhere treats as the only field that matters.
When the Same Company Disagrees With Itself
The clearest evidence that a CVE score and a vendor advisory are not interchangeable fields needs no second vendor at all. On 1 November 2026 Red Hat published three separate fix advisories for this flaw, alongside its own CVE page. The Red Hat Enterprise Linux 8 advisory, RHSA-2026:93414, carries the severity Critical, matching the CVE page. The Red Hat Enterprise Linux 9 and 10 advisories, bundling this fix with seventeen and fifteen other kernel fixes respectively, both carry the severity Important [8].
One company, one day, one underlying commit, two different severity labels depending on which document an automated system reads. The advisory that matches the CVE page's Critical rating is also the only one of the three that fixes this flaw alone, rather than bundled with over a dozen others; a patching tool that gates on advisory severity and a patching tool that gates on CVE severity will read a different urgency from the same vendor's own paperwork about the same code, on the same afternoon.
A severity label is not the only field in dispute. The dates a fix actually became available moved almost as widely. Debian shipped its fix eleven days after the upstream commit [9]. Red Hat's three advisories landed twenty-seven days after. AlmaLinux's patched kernels reached its production repositories twenty-five to twenty-eight days after, and AlmaLinux's own technical steering committee, ALESCo, published its reasoning in public: with no fixed Red Hat Enterprise Linux kernel yet available, the committee decided to ship ahead of the vendor it rebuilds [10]. Among the vendors that have shipped a fix, the spread from fastest to slowest is seventeen days.
Ubuntu sits outside even that range. Four of its currently supported releases still carry the status "Vulnerable, work in progress" at the time of writing, thirty days after the upstream fix and with no Ubuntu Security Notice issued [11]. That is not the slow end of a seventeen day spread; it is a separate, open case.
What Remote Root Actually Requires
One further distinction belongs in any SLA that keys to exploit severity rather than exploit existence. Red Hat's own security bulletin for this flaw states plainly that the vulnerable code path does not require the Multipath TCP extension to be enabled; the general outcome, for almost every affected system, is a crash or corrupted kernel memory, not remote code execution [12].
The demonstration that made this flaw well known this fortnight needed Multipath TCP specifically. Anthropic published an account of an unreleased Claude research model building a working remote-root exploit against a Multipath TCP listener in roughly fifty-three minutes, a kernel pointer leak in the first forty-eight minutes and a shell five minutes later. Anthropic states plainly that the exploit code itself was not released [13].
That is a demonstrated capability, not a demonstrated attack. CVE-2026-98432 does not appear in the United States Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalogue, and no credible report places it in active use against a live target. A private proof of concept existing is a different claim from a flaw being exploited at internet scale, and an SLA that cannot tell the two apart will eventually treat every published research paper as an emergency.
That difference is exactly where New Zealand's own patching instruments get interesting.
The Clock New Zealand Already Keeps
The New Zealand Information Security Manual's control 12.4.4.C.01 requires agencies to apply critical security patches "as soon as possible and preferably within two (2) days" of a patch becoming available [14]. The primary document could not be read directly with the tools available while preparing this piece, and search results disagree on which classification levels the control covers, so its exact wording and scope are offered here with that caveat rather than as settled fact.
The National Cyber Security Centre's own Patching Minimum Standard is useful precisely because it can be read directly, and because it does not key its fast clock to severity alone. It requires critical patches on externally facing systems "within two days (whether working days or not)... or where working exploits exist," and within two weeks on internal systems [15].
Read that clause against CVE-2026-98432 and the standard lands in a genuinely unresolved spot: a working exploit demonstrably exists, built by a research model in under an hour, but it has not been released and nothing places it in active use. The standard's own text does not say whether a private, disclosed proof of concept is enough to trigger "where working exploits exist," or whether that clause is reserved for exploitation already seen in the wild. Even an instrument built to key its clock to something closer to a fact than a severity label still arrives at a judgement call at its own gate, and this week supplies a live, unresolved instance of exactly that call.
One instrument conspicuously does not help here. The Government Procurement Rules' guidance on managing national security risk, Rule 26, covers supplier vetting, foreign ownership, and supply chain risk in procurement decisions; it contains no patching timeframe or vulnerability remediation obligation of any kind. It is the wrong document for this question, not a silent one [16].
An Ocean Away, the Same Shape of Question
A structurally similar gap opened this fortnight on the question of identity rather than severity. On 2 November 2026 the Hong Kong Monetary Authority launched Project SAGE, a discussion paper on verifying artificial intelligence agents' identity in finance, with a Know Your Agent proposal and a feedback window that runs to 1 February 2027 [17]. Weeks earlier, Australia's Australian Signals Directorate had already written seven named artificial intelligence agent identity controls into its government Information Security Manual, as controls rather than open questions [18].
Neither instrument is the full answer, and the two are not strictly comparable: one is a prudential financial regulator's consultation, the other a government security baseline. But both answer the same underlying question, who or what establishes an agent's identity and delegated authority, from opposite ends. One jurisdiction is still asking; the other has already written the controls down. An architect can build against seven named controls today. A discussion paper with a three month comment window is not yet a usable input, whatever its eventual authority.
Which Field Should Your SLA Actually Read
None of the four severity fields in this week's matrix is wrong. Each one is somebody's honest technical judgement, recorded faithfully in the field that judgement belongs in. The error sits one layer up, in automation that treats any one of those fields as the single trigger for every downstream action.
Three changes are available to any architecture team running a patching programme today.
First, key the clock to a fact, not a judgement. The date a fix became available upstream, and the date your own vendor shipped it, are both facts anyone can check against a changelog or an advisory. A Common Vulnerability Scoring System sub-score is somebody's estimate of how hard a race condition is to win.
Second, treat severity as a secondary signal for prioritisation inside a fixed clock, not as the clock itself. A 9.8 and an 8.1 on the identical flaw should change how much attention a fix gets, not whether a two day or a thirty day remediation window applies.
Third, build a separate check for the National Cyber Security Centre's own second trigger, exploit existence, and write down in advance what counts as evidence: a vendor's own disclosure, a published proof of concept, or confirmed use in the wild. Decide that threshold before the week you need it, not during it.
The same discipline applies to the second thread running through this fortnight's research. An agent identity register that already names its controls, the way the Australian Signals Directorate's seven do, is something a security architecture team can adopt today. A discussion paper still collecting submissions is not, however promising its eventual shape. Build against what already answers the question, and treat what is still open as a watch item, not a dependency.
Back to the Four Numbers
Nine point eight. Eight point one. No primary score at all. Critical on one document and Important on two others from the same vendor, on the same day. None of those numbers is lying. They are four honest answers to a question an architect was never going to be asked to settle, how hard is this particular race condition to win, recorded in four different places because nobody agreed in advance which place mattered.
The field an SLA reads is a design decision, made once, usually by whoever configured the dashboard and never revisited since. CVE-2026-98432 is a useful prompt to go and look at which field that actually is, in your own tooling, this week, while the flaw is still open on several current operating systems.
The open-source dimension here is the whole disclosure chain. CVE-2026-98432 is a public record because Linux is its own CVE Numbering Authority: the kernel assigns and scores its own vulnerabilities in the open, rather than waiting for a vendor to decide what the public may know. That same open structure let AlmaLinux's technical steering committee, ALESCo, publish its own reasoning for shipping a fix ahead of Red Hat's own upstream, a public decision on a stated basis rather than a silent one. As I wrote in Free as in Theft, "The sovereignty pivot was deliberate." Red Hat's 2023 restriction of RHEL's source access produced exactly this response: SUSE, Oracle, and CIQ founded the Open Enterprise Linux Association to keep a shared source base alive. AlmaLinux's decision this fortnight is the same pattern, restated in miniature.
The same question, which fact triggers action, sits underneath allied critical infrastructure protection too. The United States Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalogue and its Binding Operational Directive 22-01 bind federal civilian agencies to a remediation deadline once a flaw is confirmed exploited, not when a vendor assigns it a severity label; that is the same structural choice the National Cyber Security Centre's own Patching Minimum Standard makes, on a smaller scale, for New Zealand's regulated agencies. The European Union's NIS2 Directive imposes a parallel obligation on operators of essential services to act on known, exploited weaknesses rather than a vendor's rating of them. None of this resolves whether CVE-2026-98432's privately demonstrated exploit meets that bar. What they share is a discipline worth copying: key a mandate to a condition that can be checked, not to a number four vendors cannot agree on.
Which field does your own patching SLA actually read, and would you choose that field again if you sat down and looked at it this week?
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. I write as director of Te Pono Limited; the views are personal and do not represent the position of any client, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Enterprise Architecture in Practice: A Field Guide to Applying the TOGAF® Standard is out now; Assume Breach, built from the EA Thursday chapters, follows on 9 January 2027. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research, drafting and images pass through a pipeline I built and govern: automated gates for source verification, forbidden language and political neutrality, and my own review before anything is published. The tools include Claude, Gemini and Openart. The frameworks, arguments and editorial judgements are mine and are the same discipline I apply to the AI systems I audit for clients. AI accelerated the work; the thinking, and the responsibility for it, are mine.
[1] Linux kernel CVE Numbering Authority. "CVE-2026-98432." CVE Record, 15 October 2026. https://cveawg.mitre.org/api/cve/CVE-2026-98432
[2] SUSE. "CVE-2026-98432." SUSE CVE Database, accessed 4 November 2026. https://www.suse.com/security/cve/CVE-2026-98432.html
[3] Oracle. "CVE-2026-98432." Oracle Linux CVE Database, accessed 4 November 2026. https://linux.oracle.com/cve/CVE-2026-98432.html
[4] Amazon Web Services. "CVE-2026-98432." Amazon Linux Security Center, accessed 4 November 2026. https://explore.alas.aws.amazon.com/CVE-2026-98432.html
[5] National Institute of Standards and Technology. "CVE-2026-98432 Detail." National Vulnerability Database, accessed 4 November 2026. https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-98432
[6] Dumazet, Eric, and Jakub Kicinski. "ipv4: free inet_opt and ireq_opt after an RCU grace period." Linux kernel Git repository, October 2026. https://github.com/torvalds/linux/commit/e3f33b0a1d89d738e2b913dab519226eaf76e15b
[7] Red Hat. "CVE-2026-98432." Red Hat Customer Portal, accessed 4 November 2026. https://access.redhat.com/security/cve/CVE-2026-98432
[8] Red Hat. "RHSA-2026:93414, RHSA-2026:93412 and RHSA-2026:93413, kernel security updates." Red Hat Errata, 1 November 2026. https://access.redhat.com/errata/RHSA-2026:93414
[9] Debian Security Team. "DSA-6568-1 linux." Debian Security Tracker, 16 October 2026. https://security-tracker.debian.org/tracker/CVE-2026-98432
[10] AlmaLinux OS Foundation. "CVE-2026-98432: shipping ahead of upstream." AlmaLinux Blog, 30 October 2026. https://almalinux.org/blog/2026-10-30-cve-2026-98432/
[11] Canonical. "CVE-2026-98432." Ubuntu Security, accessed 4 November 2026. https://ubuntu.com/security/CVE-2026-98432
[12] Red Hat. "RHSB-2026-016: CVE-2026-98432 kernel security bulletin." Red Hat Security Bulletin, accessed 4 November 2026. https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
[13] Anthropic. "Discovering vulnerabilities with Claude." Anthropic Research, 27 October 2026. https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
[14] Government Communications Security Bureau. "New Zealand Information Security Manual, Control 12.4.4.C.01."
[15] National Cyber Security Centre New Zealand. "Patching Minimum Standards." NCSC NZ, accessed 4 November 2026. https://www.ncsc.govt.nz/protect-your-organisation/patching-minimum-standards/
[16] New Zealand Government Procurement. "Managing National Security Risks." Government Procurement Rules, accessed 4 November 2026. https://www.procurement.govt.nz/government-procurement-framework/government-procurement-rules/approaching-the-market/managing-national-security-risks/
[17] Hong Kong Monetary Authority. "HKMA Launches Project SAGE." Press Release, 2 November 2026. https://www.hkma.gov.hk/eng/news-and-media/press-releases/2026/11/20261102-3/
[18] Australian Signals Directorate. "Information Security Manual, September 2026 Changes." Australian Cyber Security Centre, September 2026. https://www.cyber.gov.au/sites/default/files/2026-08/ISM%20September%202026%20changes%20(September%202026).pdf