Security Advisory: CVE-2026-98432 race condition in the Linux kernel's IPv4 TCP stack

Description

On October 29, 2026, TheHackerNews published an article about CVE-2026-98432 which is a use-after-free caused by a race condition in the Linux kernel's IPv4 TCP connection-handling path.
The defect was introduced in Linux 4.4 and is therefore present in the large majority of kernels in production today.

According to public research reporting by Anthropic, a working unauthenticated remote exploit has been demonstrated, yielding root-level code execution.
The reported exploit was made through the target host that exposed a Multipath TCP (MPTCP) listener.

A key amplifying factor: applications built with Go 1.24 or later create MPTCP-enabled listeners by default on Linux.
Per the official Go 1.24 release notes, "ListenConfig now uses MPTCP by default on systems where it is supported (currently on Linux only)."
Consequently, a Go-based service can expose an MPTCP listener and therefore the precondition this exploit targets without any explicit configuration or awareness by its operators, simply as a result of being compiled with Go 1.24. (Outbound Go dialers are not affected; this concerns inbound listeners only.)

Risk & Impact

• Attack vector: Network (remote), no authentication, no user interaction required (per public reporting).
• Precondition: A reachable MPTCP listener on a vulnerable kernel.
• Impact: Full host compromise arbitrary code execution as root, with total loss of confidentiality, integrity, and availability.
• Amplified exposure: Any Linux service (re)built with Go 1.24+ is MPTCP-exposed by default, so the population of at-risk hosts is likely larger than teams that never explicitly enabled MPTCP would expect.

Detection

# Identify MPTCP-capable listeners (requires recent iproute2 'ss' with MPTCP support)
ss -tlm
ip mptcp endpoint show

# Identify Go binaries built with 1.24+ (to flag implicit MPTCP listeners)
go version /path/to/binary

# Confirm kernel version before and after patching
uname -r

Mitigation

Use one of these to reduce exposure until a fixed kernel is installed.
They are compensating controls, not a substitute for patching. Where MPTCP is not an operational requirement, disabling it reduces the exploit precondition.

Disable MPTCP in Go applications (Go 1.24+)

MPTCP can be disabled in several ways in Golang:

# Option 1 runtime, no rebuild: set GODEBUG for the service process
GODEBUG=multipathtcp=0 ./your-service

// Option 2 in code: force MPTCP off on the listener
lc := net.ListenConfig{}
lc.SetMultipathTCP(false)
ln, err := lc.Listen(ctx, "tcp", addr)

// Option 3 build-time default via go.mod
godebug multipathtcp=0

Applies to newly started processes only. Changing GODEBUG, go.mod, or the binary does not affect an already-running service.
Restart the application so its listeners are recreated as plain TCP.

Disable MPTCP at the kernel level

Removes MPTCP system-wide (affects all applications, Go or otherwise):

# Inspect current state
sysctl net.mptcp.enabled

# Disable at runtime
sudo sysctl net.mptcp.enabled=0

# Persist across reboots
echo 'net.mptcp.enabled=0' | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
sudo sysctl --system

Applies to newly created sockets only: The net.mptcp.enabled flag is read when a socket is created so setting it to 0 prevents new MPTCP sockets from being opened.
It does not convert or close sockets that are already open: any MPTCP listener or connection established before the change keeps using MPTCP until its process ends.
Restart the affected application(s) (or reboot the host) so their listeners are recreated as plain TCP. After restarting, confirm no MPTCP listeners remain with ss -tlm / ip mptcp endpoint show.

Drop MPTCP packets at the firewall

MPTCP negotiation uses TCP option kind 30 (the MP_CAPABLE option is carried in the initial SYN) Dropping SYNs that carry it prevents MPTCP sessions from being established. nftables can match this natively:

sudo nft add table inet mptcp_block
sudo nft add chain inet mptcp_block input '{ type filter hook input priority filter ; policy accept ; }'
# Drop inbound TCP SYNs advertising MPTCP (MP_CAPABLE)
sudo nft add rule inet mptcp_block input tcp flags syn tcp option mptcp exists counter drop

Remediation (per OS)

The definitive fix is a patched kernel install it and reboot. The table below was verified against vendor security trackers on 2026-10-30 (Ubuntu, Debian, Red Hat, SUSE fetched live; Oracle Linux and Amazon Linux from secondary reporting).
Status changes rapidly re-confirm against the vendor tracker before acting.

OS / Distribution	Status	Fixed version / advisory
Upstream stable kernels	Fixed	5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3
Debian	Fixed	bookworm: 6.1.190-1 (DLA-4841-1) + 6.12 backport 6.12.113-1~deb12u1 (DLA-4850-1) · trixie: 6.12.113-1 (DSA-6568-1) · sid/forky: fixed
Ubuntu (all supported: 26.10 → 16.04)	No fix work in progress	None yet use mitigations. (14.04 trusty: not affected)
RHEL 8 / 9 / 10	Affected no erratum yet	No RHSA released; Red Hat: Important (8.1); use mitigations
RHEL kernel-rt (8 / 9)	Affected no erratum yet	Same status as the standard kernel
Rocky Linux / AlmaLinux	Pending RHEL	Rebuilt from RHEL; no upstream erratum to rebuild yet

Verify whether your running kernel already carries the fix

# Debian / Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

# RHEL / CentOS / Rocky / Alma / Oracle / Amazon
rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-98432

# Confirm the running kernel version (before and after patching + reboot)
uname -r

Recommended remediation sequence

1. If a fixed kernel exists for your OS: update and reboot; then verify with the commands above.
2. If no fixed kernel yet (Ubuntu, RHEL/Rocky/Alma, SLES 15 SP7): apply mitigations (disable MPTCP in Go apps and/or at the kernel level, and/or drop MPTCP at the firewall), restart affected services, restrict network exposure of affected listeners, and subscribe to the vendor's advisory for the pending kernel.
3. Revalidate once the vendor ships a fixed kernel, then remove compensating controls only if MPTCP is operationally required.

References

• Anthropic article: https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
• TheHackerNews publication: https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html
• Go 1.24 release notes (MPTCP listener default): https://go.dev/doc/go1.24
• Go net package documentation (ListenConfig): https://pkg.go.dev/net#ListenConfig
• Golang issue: https://github.com/golang/go/issues/82717
• Ubuntu CVE tracker: https://ubuntu.com/security/CVE-2026-98432
• Debian security tracker: https://security-tracker.debian.org/tracker/CVE-2026-98432
• Red Hat CVE page: https://access.redhat.com/security/cve/CVE-2026-98432
• Red Hat security-data API (JSON): https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-98432.

If you have any questions, please contact our support team via the Scaleway console.
The Scaleway Team

On October 21, 2026, the PHP security team released patches for two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, dubbed "PHP2shell" (CVSS v4.0 score: 9.2). They allow an unauthenticated attacker to execute remote code on a web server running PHP via a simple HTTP request. Exploitation attempts were observed on the Internet as soon as the advisory was published, and even a few days prior.
As the security of your infrastructure is our top priority, our teams mobilized upon receiving the initial reports to safeguard our services and apply the necessary patches.

In Brief

• Our managed services relying on PHP have been updated. Web hosting customers running End-of-Life (EOL) PHP versions have been contacted individually where action on their part is required.
• If you manage PHP yourself (Instances, Elastic Metal, Dedibox servers, Kubernetes Kapsule, container images, etc.), you must update PHP as soon as possible.
• End-of-Life PHP versions (8.1 and earlier) will not receive an official patch: we recommend migrating to a supported version.

Description of Vulnerabilities

• CVE-2026-109618: When memory is exhausted during initial request processing, PHP may terminate before initializing certain internal data structures, which the cleanup phase later processes as if they were valid.
• CVE-2026-109619: After a fatal error, references to freed memory areas may persist and be reused by a subsequent request handled by the same PHP process. Session upload progress tracking (session.upload_progress), enabled by default, is one known method to trigger this flaw.

These flaws reside in the core PHP engine itself: updating your application, CMS (WordPress, Drupal, etc.), or plugins is not sufficient. All web execution modes are affected (PHP-FPM, mod_php, php-cgi, LiteSpeed, FrankenPHP).

• Affected Versions: PHP 5.4 through 8.5.11.
• Patched Versions: 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
• Versions Without Official Patches: PHP 8.1 and earlier (End-of-Life).

Impact on Scaleway Services

Upon the release of the patches, we updated all of our managed services that utilize PHP. Out of an abundance of caution, certain services were temporarily placed under maintenance while patches were applied; all services are now fully restored.

For End-of-Life PHP versions still offered across our web hosting products, we deployed backported patches.
In addition, we have:

• Analyzed our logs starting from October 17, 2026, the date of the earliest known exploitation attempts;
• Verified the effectiveness of the patches through penetration testing.

Required Actions

You Use a Scaleway Managed Service (Web Hosting, Serverless…)

Our teams have implemented the necessary security measures. Customers required to perform any specific action have been notified individually. In all cases, we recommend upgrading to a actively supported PHP version (8.4 or newer).

You Manage PHP Yourself (Instances, Elastic Metal, Dedibox, Kapsule, Containers)

1. Identify your PHP installations and their active versions. Note: the version reported by the command line (php -v) may differ from the version used by your web server.
2. Update PHP to a patched version (8.5.12, 8.4.27, 8.3.36, or 8.2.35) or apply your distribution's latest updates. Some distributions backport security fixes without changing the main version number: check your package's changelog.
3. Restart PHP-FPM or your web server, then verify the active version being served. For containers, rebuild your images from a patched base image and redeploy them.
4. If you are running an End-of-Life version, plan a migration path to a supported version.

Command examples:

• Debian / Ubuntu: sudo apt update && sudo apt upgrade, then sudo systemctl restart php8.X-fpm (adjust for your service name).
• AlmaLinux / Rocky Linux / RHEL: sudo dnf upgrade, then sudo systemctl restart php-fpm.

If You Cannot Update Immediately

The following mitigations reduce risk, but do not replace upgrading, as they do not fully address both vulnerabilities:

• Disable upload progress tracking in php.ini or in your PHP-FPM pool configuration (session.upload_progress.enabled = 0), then restart PHP. This setting cannot be changed dynamically via ini_set().
• Block multipart/form-data POST requests at the reverse proxy or WAF level for applications that do not require file uploads, and restrict request size limits.
• Restrict access to non-public PHP applications (via VPN or IP whitelisting).

Checking for Indicators of Compromise

Given that exploitation attempts occurred prior to patch availability, we recommend auditing your servers for activity starting from October 17, 2026:

• PHP processes (php-fpm, php-cgi, apache2, httpd) spawning shell sessions or utilities such as curl, wget, or nc;
• New .php files created in web root or upload directories, unexpected cron jobs, or new user accounts;
• Multipart POST requests containing PHP_SESSION_UPLOAD_PROGRESS, out-of-memory errors, or unusual bursts of HTTP 500 status codes in your web logs;
• Unusual outbound network connections originated by web servers.
  If compromise is suspected, isolate the server, preserve logs, and contact our support team.

Timeline

• October 20, 2026: Leak of vulnerability details before the end of the embargo.
• October 21, 2026: Official release of patches by the PHP security team and initiation of deployment across our infrastructure.
• October 26, 2026: Remediation complete across all Scaleway managed services.

References

• CVE-2026-109618: https://www.cve.org/CVERecord?id=CVE-2026-109618
• CVE-2026-109619: https://www.cve.org/CVERecord?id=CVE-2026-109619
• Supported PHP Versions: https://www.php.net/supported-versions.php
• CERT FR: https://www.cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-014/

If you have any questions, please contact our support team via the Scaleway console.
The Scaleway Team

UPDATE: Patched Kubernetes Node Images Available for Linux Kernel Vulnerabilities

Following up on our previous security advisory regarding critical Linux kernel vulnerabilities, we are writing to inform you that fully patched node images are now available for your Kapsule pools.

What is changing?

We have released updated node images featuring Linux kernel version 6.8.0-124-generic. This new kernel provides a comprehensive, permanent resolution for the three major vulnerabilities disclosed recently:

• CopyFail (CVE-2026-31431): A logic flaw in the cryptographic template allowing local privilege escalation via unauthorized page cache writes.
• Dirty Frag (CVE-2026-43284): A local privilege escalation flaw in the kernel's xfrm network subsystem.
• ssh-keysign-pwn (CVE-2026-46333): A process management flaw allowing unprivileged users to read root-only host files, including SSH private keys.

Required Actions

To secure your infrastructure and transition away from temporary workarounds, please complete the following steps:

1. Replace Your Cluster Nodes Because these security fixes are applied at the kernel level, simply restarting pods or updating the control plane is not sufficient. You must replace your existing nodes to pull the new 6.8.0-124-generic image. You can achieve this by performing a rolling update of your node pools (recreating the nodes or scaling up new nodes and deleting the old ones).
2. Remove the Mitigation DaemonSet If you previously deployed any temporary mitigation DaemonSet provided in our previous communications, you must remove them once your nodes have been successfully replaced with the new image.

⚠️ Reminder for Kosmos Users: As external Kosmos pools are managed on your side, please ensure you manually update your external instances to kernel version 6.8.0-124-generic or recreate them using an updated distribution image containing these fixes.

If you have any questions or require technical assistance during this node replacement process, please do not hesitate to open a support ticket via the Scaleway console.

Best regards,
The Scaleway Team

Trust Center Update: Scaleway Achieves CSA STAR Level 1 Certification

At Scaleway, trust and transparency are the cornerstones of our commitment to our ecosystem. We are proud to announce that we have officially achieved the CSA STAR Level 1 Certification (Security, Trust, Assurance, and Risk), awarded by the Cloud Security Alliance (CSA).

This milestone reinforces our continuous efforts to deliver a secure, sovereign, and fully compliant cloud environment for your workloads.

---

What is the CSA STAR Level 1?

The Cloud Security Alliance (CSA) is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment.

The STAR Level 1 designation involves a rigorous self-assessment based on the CSA’s Cloud Controls Matrix (CCM). By completing this evaluation, Scaleway demonstrates total transparency regarding our security posture, validating the fundamental security controls implemented across our infrastructure and services.

---

Driving European Compliance and Trust

The CSA Cloud Controls Matrix is a global benchmark so robust that its framework directly aligns with and inspires major European cybersecurity standards. This achievement directly supports our customers' compliance roadmaps across Europe, for example:

• Germany (BSI C5): The latest cloud security requirements from the German Federal Office for Information Security (C5:2026) explicitly integrate version 4 of the CSA CCM controls.
• Italy (ACN): The National Cybersecurity Agency recognizes the CSA STAR framework as a trusted path for cloud service qualification, aligning closely with ISO/IEC 27001 extensions (27017/27018).
• Spain (ENS): A complete, official mapping exists between the Spanish National Security Framework (Esquema Nacional de Seguridad) and the CSA controls, streamlining compliance for Iberian deployments.

---

Access the Documentation

Our completed Consensus Assessments Initiative Questionnaire (CAIQ) is now available. You can download the report directly from our Trust Center repository to review our detailed security responses.

Thank you for your continued trust in Scaleway.

The Scaleway Team

Security Advisory - CVE-2026-46333 - ssh-keysign-pwn: Analysis, Scope, Remediation Plan

This is an information note regarding CVE-2026-46333. This vulnerability was reported on May 14, 2026.

It represents a critical logical flaw within the Linux kernel’s process management and access control tracking logic, affecting a massive portion of deployed Linux systems globally. Functional public exploits are currently available online, making immediate verification and remediation critical for exposed systems.

This flaw, located in the kernel's exit path (do_exit) and tracked within ptrace access checks, allows for Local Privilege Escalation (LPE) and severe Information Disclosure.

• On a standard server: It allows a standard local unprivileged user to exploit a process race condition via pidfd_getfd(2). By utilizing the public exploit code, an attacker can clone open file descriptors out of exiting privileged SUID binaries (such as ssh-keysign or chage) to read highly sensitive host secrets.

• In a containerized environment (such as Kubernetes): If containers are configured with shared namespaces (specifically --pid=host), an attacker within a pod can run the public exploit against host processes to extract host-level secrets, leading directly to a full host compromise and container escape.

As the security of your infrastructure is our priority, here are the details regarding the impact of this vulnerability on your services, current operating system patch availability, and the recommendations to follow.

---

Current Operating System Patch Status

The availability of stable security updates varies across upstream Linux distributions. Please review the status of your specific OS platform to determine whether to update immediately or apply temporary mitigations:

• Debian: Patches have been officially released for Debian 12 (Bookworm) and Debian 13 (Trixie). You can track official package versions and updates via the Debian Security Tracker.

• AlmaLinux: Official patched kernels have been built, validated, and promoted directly to production repositories. Full details can be reviewed in the AlmaLinux Security Advisory.

• CloudLinux: Patched kernels are available in production for CloudLinux 9 and 10, and are currently in the beta channel for CloudLinux 7h and 8. Detailed upgrade and CageFS configuration instructions can be found in the CloudLinux Update Guide.

• Ubuntu: No patch is available at this time. Canonical is actively working on backporting the fix. If you are running Ubuntu workloads, you must apply the temporary mitigation detailed below immediately. Ubuntu Security Advisory

---

Risk Assessment: Multi-tenant vs. Isolated Environment

The urgency of applying patches depends heavily on your usage patterns and service architecture:

• Multi-tenant / Shared Environment (High Criticality): If your machines or Kapsule clusters host applications from different clients, provide shell access to multiple users, or execute unverified third-party code, this vulnerability is critical. An attacker with limited access (standard user or access within a pod) can exploit this race condition using the publicly available exploit to siphon root-owned files and compromise the data or access credentials of other system tenants.

• Single-tenant / Isolated Environment (Moderate Criticality): If your servers or clusters are strictly dedicated to your use and only run trusted applications whose code you control (without local access or arbitrary execution possible by third parties), the risk is significantly lower. The vulnerability requires prior local code execution to be exploited.

---

Required Actions and Temporary Mitigation:

The permanent solution consists of updating your systems' kernel once a version including the patch becomes available from your OS vendor. We invite you to regularly check for the availability of the patch for your specific OS.

Mitigation Measure (Workaround):

If an immediate reboot or update is not possible (or if you are running an unpatched distribution like Ubuntu), you can apply a temporary mitigation directly to your affected nodes and servers by tightening Yama's ptrace_scope system-wide. This blocks unprivileged users from initiating the ptrace access paths required to trigger the vulnerability.

Execute the following commands with administrator privileges (root or sudo):

# Apply runtime mitigation to block unprivileged ptrace access immediately
sudo sysctl -w kernel.yama.ptrace_scope=3

# Persist the rule across system reboots
echo "kernel.yama.ptrace_scope = 3" | sudo tee /etc/sysctl.d/99-sysctl-ptrace.conf
sudo sysctl --system

For Kubernetes Kapsule, this operation must be performed on the worker nodes, for example via SSH access or by deploying a privileged DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: disable-unprivileged-ptrace
  namespace: kube-system
  labels:
    app: disable-unprivileged-ptrace
spec:
  selector:
    matchLabels:
      app: disable-unprivileged-ptrace
  template:
    metadata:
      labels:
        app: disable-unprivileged-ptrace
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: configure-sysctl
          image: alpine:3.23
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              # Apply runtime mitigation to the host kernel via nsenter
              nsenter -t 1 -m -u -i -n -p sysctl -w kernel.yama.ptrace_scope=3
              # Persist across reboots by writing to the host filesystem mount
              echo "kernel.yama.ptrace_scope = 3" > /etc/sysctl.d/99-sysctl-ptrace.conf
          volumeMounts:
            - name: sysctl-d
              mountPath: /etc/sysctl.d
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.10
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
      volumes:
        - name: sysctl-d
          hostPath:
            path: /etc/sysctl.d

---

Rollback: Reactivation Commands

Restricting ptrace_scope to 3 completely disables unprivileged process tracing. This has no impact on the vast majority of production applications. However, if some of your localized development or monitoring systems specifically require debugging capabilities (e.g., running unprivileged strace, gdb, or certain profiling tools), you can undo this mitigation at any time with these commands:

# Remove the persistence file
sudo rm /etc/sysctl.d/99-sysctl-ptrace.conf

# Reset Yama ptrace_scope back to standard restricted mode (default on most distributions)
sudo sysctl -w kernel.yama.ptrace_scope=1

We remain at your full disposal for any further information or technical assistance via the console.
The Scaleway Team.