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.

Security Advisory - CVE-2026-43284: Analysis, Scope, and Remediation Plan

Hello,

This is an information note regarding CVE-2026-43284, known as "Dirty Frag". This vulnerability was reported on May 07, 2026.
It represents with CopyFail (cf a previous post), another local privilege escalation vulnerability in the Linux kernel, with a potential impact on the entire global Linux fleet.
Our security team became aware of this disclosure the same day it was published and immediately initiated the necessary investigations.

This flaw is a sequel of CopyFail that allows a malicious user to perform a Local Privilege Escalation (LPE).

• On a standard server, it allows a standard user to become root (administrator).
• In a containerized environment (such as Docker or Kubernetes), it allows for a container escape to take control of the host node.

The impacted kernel modules is ESP which is used by the protocol IP-SEC and RxRPC which is used by the AFS (Andrew File System), a distributed file system.

This vulnerability has a public exploit in the wild and must be mitigated or patched as soon as possible.
While the vulnerability has been identified, OS vendors (such as Ubuntu and Red Hat) have not yet released a finalized security patch for the Linux kernel.

As the security of your infrastructure is our priority, here are the details regarding the impact of this vulnerability on your Scaleway services and the recommendations to follow to mitigate it during a patch is offered by OS vendors:

---

What has been done on the Scaleway side:

Because most OS vendors haven't put out a patch for the kernel yet and the possible fixes could stop IPSEC VPN communication, which could be critical for some of our customers, no mitigation actions were pushed into our distributed images.

Therefore, until a kernel patch is available that prevents the deactivation of some keys features as fixes, it is your decision as a customer to apply mitigation actions or not.

Debian and AlmaLinux have already released a kernel patch that has been merged into our distributed images but nothing else for the other OS vendors.

Update: 05/12/2026
We have updated our distributed OS images to protect your new instances. Official patches are already merged for Debian and AlmaLinux, and we have now deployed mitigated images for Ubuntu (Focal, Jammy, Noble, & Resolute).

---

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 flaw to gain full control of the server (root access) and compromise the data 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. We invite you to regularly check for the availability of the patch for your specific OS.

• Debian has released a kernel update to patch the vulnerability.
• AlmaLinux has released a kernel update to patch the vulnerability.
• Ubuntu hasn't released a patch yet but it can be checked in their security advistory.
• RedHat hasn't released a patch yet but it can be tracked in their security advisory.

---

Mitigation Measure (Workaround):

Because some OS vendors haven't released a patch yet, a mitigation can be installed on the system side. The mitigations disable the kernel modules that are used for IPsec ESP and RxRPC, respectively. The mitigations will affect functionality if these are in use by either:

• IPsec deployments. These are common with VPN implementations Site-by-Site.
• AFS (Andrew File System) or another application of RxRPC.

If you don't use these modules, you can execute the following commands with administrator privileges (root or sudo) to disable the modules:

# block the kernel module (a reboot will be necessary)
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

# Regenerate the initramfs images, to prevent the modules from being loaded during early boot:
sudo update-initramfs -u -k all

# Unload the module if they're already loaded in the kernel space
sudo rmmod esp4 esp6 rxrpc 2>/dev/null

# check if the module aren't loaded anymore:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"

# if the module can't be unload, there are used by software and a reboot might be required to unload them.
# this means it will probably break some used softwares/component and test must be performed !!!
sudo reboot

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-ipsecesp-rxrpc
  namespace: kube-system
  labels:
    app: disable-ipsecesp-rxrpc
spec:
  selector:
    matchLabels:
      app: disable-ipsecesp-rxrpc
  template:
    metadata:
      labels:
        app: disable-ipsecesp-rxrpc
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: disable-ipsecesp-rxrpc
          image: debian:stable-slim
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              # install sudo & update-initramfs
              apt-get update && DEBIAN_FRONTEND=noninteractive && apt-get install -y --no-install-recommends sudo initramfs-tools

              # block the kernel module (a reboot will be necessary)
              echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
              echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
              echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

              # Regenerate the initramfs images, to prevent the modules from being loaded during early boot:
              sudo update-initramfs -u -k all
              # Unload the module if they're already loaded in the kernel space
              sudo rmmod esp4 esp6 rxrpc 2>/dev/null

              # check if the modules aren't loaded anymore:
              grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
          volumeMounts:
            - name: modprobe-d
              mountPath: /etc/modprobe.d
      containers:
        - name: pause
          image: registry.k8s.io/pause:3.10
          resources:
            limits:
              cpu: 1m
              memory: 8Mi
      volumes:
        - name: modprobe-d
          hostPath:
            path: /etc/modprobe.d

---

Rollback: Reactivation Commands

If some of your services specifically require these modules (and you observe malfunctions), you can undo this mitigation at any time with these commands:

# Remove the block file
sudo rm /etc/modprobe.d/dirty-frag.conf

# Regenerate the initramfs images, to reactivate the modules during early boot:
sudo update-initramfs -u -k all

# Manually reload the module into the kernel
sudo modprobe esp4 esp6 rxrpc

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