Security incident BookMyName

Trust Center

Start your security review
View & download sensitive information
Ask for information
ControlK

Welcome to Scaleway's Trust Center. We strive to include security in each and every aspect of our business. You will find in this Trust Center information and documentation to attest our actions towards delivering a safe and secure Cloud service.

Bienvenue sur le Trust Center de Scaleway. Nous nous efforçons d'inclure la sécurité dans tous les aspects de notre activité. Vous trouverez dans ce Trust Center des informations et de la documentation qui attestent des actions entreprises pour garantir la sécurité de nos services.

GDPR Logo
GDPR
HDS Logo
HDS
ISO/IEC 27001 Logo
ISO/IEC 27001
ISO/IEC 27001 SoA Logo
ISO/IEC 27001 SoA

Documents

Featured Documents

COMPLIANCEHDS

Reports

We may provide security-related reports upon request.

Trust Center Updates

Security incident BookMyName

Copy link
Incidents

Security incident BookMyName

Incident start date: May 5th, 2026
Incident end date: May 6th, 2026
Affected Services: BookMyName


Summary

On Tuesday, May 5th at 08:55 CET, we detected a security incident involving changes to customer’s contact information on BookMyName.

After detecting the incident, we immediately took action to contain the issue, investigate the scope, and apply remediation measures. One of the containment measures taken was to shutdown the BookMyName website and reseller API.

Based on our investigation, the contact data of 1,868 accounts was updated by a malicious actor. Email address, first name, last name, password and country were overridden.

At this stage:

  • Customer contact data has been restored to its initial configuration (i.e., email address, first name, last name, password, and country).
  • BookMyName service has been resumed and all domain management operations can be carried out nominally, except for the password reset page which is under maintenance. The support must be contacted in order to perform a password reset.
  • We identified and fixed the incident root cause.
  • We are enhancing BookMyName monitoring to quickly detect any anomalous behaviour.

Impact

Based on our investigations, the impact on service was as follows:

AreaImpact
Customer accountsConfirmed modification of 1,868 accounts
Domains (ownership operations)No Impact
Payment / BillingNo Impact
Account passwordNo Impact
API KeysNo Impact
DNSNo Impact

Data Impact

The following data was temporarily accessed:

  • User ID (handle)
  • Email address

The following data may have been temporarily modified:

  • User ID (handle)
  • Password
  • Company name (for non-individual accounts)
  • First and last name
  • Email address
  • Phone number
  • Postal address

Timeline

All times are in UTC.

TimeEvent
2026-05-05 05:15:35First modified account
2026-05-05 07:42:40Last modified account
2026-05-05 07:50:00Incident acknowledgement and start of investigations
2026-05-05 08:21:11BookMyName shutdown
2026-05-05 08:36:00Incident open on the Scaleway status page
2026-05-05 12:46:05Maintenance page setup
2026-05-05 15:38:00Incident remediation and fix implementation started
2026-05-05 20:07:29Domain contact data restored and security patch applied. BookMyName web interface and API enabled again

How we responded

After detecting the issue, we took the following actions:

  1. Contained the incident
    • We disabled BookMyName website and APIs as a protective measure for our customers.
  2. Investigated for impact assessment and root cause identification
    • We reviewed logs, source code and network activities.
  3. Mitigated the issue
    • We disabled the affected page to restart the services.
  4. Remediated the issue
    • We fixed the incident root cause.
  5. Strengthened monitoring
    • We added new alerts, detection rules, and logging coverage.

Root cause

The incident was caused by faulty logic in the permission check of the contact edition endpoint. This flaw allowed a threat actor to update any contact-related field by targeting any account ID using HTTP query parameter manipulation. It was mainly a blind attack: no account was specifically targeted.


Security recommendations

  • Reset your password
  • Ensure your data is restored as of Tuesday, May 5th 05:15 (UTC)

As a security best practice, when available, you should always enable MFA to add an extra layer of protection to your accounts.

We sincerely apologize for the inconvenience caused and assure you that all Scaleway teams remain fully mobilized to guarantee the security and integrity of your services.

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

Vulnerabilities

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

Hello,

This is an information note regarding CVE-2026-31431, known as "Copy Fail". This vulnerability was reported on April 29, 2026.
It represents one of the most extensive Linux kernel vulnerabilities in recent years, 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, located in the kernel's cryptographic subsystem (via the AF_ALG interface), allows for 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.

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.

What has been done on the Scaleway side:

Immediately upon disclosure of this flaw, our teams took the necessary measures to secure environments and provide clean images:

On Kubernetes Kapsule: New OS images disabling the algif_aead module have been deployed:

  • Any new node created after April 30, 2026, at 2:20 PM CEST will automatically use a mitigated version. (You can check the version date used in the OS-IMAGE field returned by kubectl get node -o wide)

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.

Mitigation Measure (Workaround):

If an immediate reboot or update is not possible, you can apply a temporary mitigation directly to your affected nodes and servers to block the vulnerable interface.
Execute the following commands with administrator privileges (root or sudo):

# Create a rule to prevent automatic reloading
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

# Unload the vulnerable module from memory
rmmod algif_aead 2>/dev/null || true

For servers based on RedHat / CentOS / Fedora / AlmaLinux / RockyLinux:

# Create a rule to prevent automatic loading of the module at boot
grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init

# Reboot the system to apply the changes

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-algif-aead
  namespace: kube-system
  labels:
    app: disable-algif-aead
spec:
  selector:
    matchLabels:
      app: disable-algif-aead
  template:
    metadata:
      labels:
        app: disable-algif-aead
    spec:
      hostPID: true
      tolerations:
        - operator: Exists
          effect: NoSchedule
        - operator: Exists
          effect: NoExecute
      initContainers:
        - name: disable-algif-aead
          image: alpine:3.23
          securityContext:
            privileged: true
          command:
            - /bin/sh
            - -c
            - |
              echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
              rmmod algif_aead 2>/dev/null || true
          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

Disabling af_alg has no impact on the vast majority of standard applications. However, if some of your services specifically require the cryptographic acceleration provided by this subsystem (and you observe malfunctions), you can undo this mitigation at any time with these commands:

# Remove the block file
sudo rm /etc/modprobe.d/disable-algif.conf

# Manually reload the module into the kernel
sudo modprobe algif_aead

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

CrackArmor Vulnerabilities

Vulnerabilities

Security Advisory: CrackArmor (AppArmor Vulnerabilities)

1. Definition

CrackArmor is the collective name for a suite of nine vulnerabilities discovered in the Linux kernel’s AppArmor security module, disclosed in March 2026. These flaws represent a significant breakdown in the kernel's access control mechanisms, allowing an unprivileged local attacker to bypass security boundaries, trigger a Denial of Service (DoS), or achieve a full Local Privilege Escalation (LPE) to root.

2. How It Works

The core of the CrackArmor suite is a classic "confused deputy" vulnerability located within AppArmor’s interface for managing security profiles. AppArmor uses several pseudo-files (such as .load, .replace, and .remove) found within the securityfs filesystem (typically at /sys/kernel/security/apparmor/).

The vulnerability stems from two critical oversights:

  • Permissions Mismatch: These control files were mistakenly set to be world-writable. While the kernel eventually checks for root privileges when data is written, it fails to perform a rigorous check at the moment the file is initially opened.

  • The Exploit: An attacker can open one of these files and then "trick" a highly privileged program—the "deputy"—into writing to it. For example, by using sudo or su in a way that redirects output to the already-open file descriptor, an attacker can force the system to load a malicious security profile or delete existing protections, all without having the actual permissions to do so.

3. Impact

CrackArmor is particularly dangerous because it undermines the very tool (AppArmor) used to sandbox applications and containers. The impact is widespread, affecting millions of Linux deployments globally.

  • Local Privilege Escalation (LPE): By loading a "fail-open" profile, an attacker can exploit a known interaction with sudo to execute arbitrary commands as the root user.

  • System Instability (DoS): Attackers can load specifically crafted, deeply nested profiles that cause uncontrolled recursion in the kernel. This leads to stack exhaustion and a kernel panic, effectively crashing the host.

  • Container Breakout: Because AppArmor is a primary line of defense for container runtimes (like Docker or LXD), these flaws allow an attacker to escape a containerized environment and gain access to the underlying host system.

  • Information Leakage: Certain flaws allow for out-of-bounds reads of up to 64 KiB of kernel memory. This can be used to harvest sensitive data or bypass KASLR (Kernel Address Space Layout Randomization), facilitating more complex exploits.

4. Remediation

To mitigate the risk of CrackArmor, administrators must update their Linux kernel to the patched versions released in March 2026.

Furthermore, related userspace packages like sudo and util-linux must be updated to close known exploitation chains.

OS DistributionMinimum Patched Version (Kernel / Package)
Ubuntu 25.10 (Questing Quokka)Kernel 6.13+ / sudo 1.9.15p5-3ubuntu5+
Ubuntu 24.04 LTS (Noble Numbat)Kernel 6.8.0-55+ / sudo 1.9.15p5-3ubuntu2.2+
Ubuntu 22.04 LTS (Jammy Jellyfish)Kernel 5.15.0-131+ / sudo 1.9.9-1ubuntu2.4+
Ubuntu 20.04 LTS (Focal Fossa)Kernel 5.4.0-204+ / util-linux 2.34-0.1ubuntu9.6+
Debian 13 (Trixie)Kernel 6.12.74-2 or later
SUSE Linux Enterprise 15AppArmor Security Update (Released March 2026)

Note: A system reboot is required after the kernel update to ensure the fixes are active.

5. Conclusion

CrackArmor is a high-priority security risk. While it requires local access to the system, the ease with which it can be used to escalate privileges or crash infrastructure makes it a critical threat. Organizations are strongly advised to patch their fleets immediately, as Proof-of-Concept (PoC) code is circulating and active exploitation has been confirmed.

6. Documentation

  • Ubuntu Security: CrackArmor Vulnerability Overview

  • Qualys Security Blog: Technical Breakdown of CrackArmor

  • Canonical Blog: AppArmor security fixes available

Security Advisory: CVE-2025-14847 (MongoBleed)

Vulnerabilities

Security Advisory: CVE-2025-14847 (MongoBleed)

1. Definition

CVE-2025-14847 is a critical information disclosure vulnerability in the MongoDB Server network transport layer. It is a heap-based memory leak flaw that allows a remote, unauthenticated attacker to read fragments of the server's uninitialized memory.

2. How It Works

The vulnerability originates within the server's network transport layer, specifically during the handling of zlib-compressed messages. When a client initiates a connection, it can request that communication be compressed to save bandwidth. The flaw occurs because the MongoDB server's decompression routine fails to strictly validate the relationship between the size of the incoming compressed packet and the size of the memory buffer allocated to hold the resulting data.

An attacker exploits this by sending a specially crafted, malformed zlib packet that claims to be smaller than the space the server allocates for it. Because the server does not "zero out" or properly bound the returned data to the actual size of the decompressed payload, it mistakenly reads and transmits the contents of the adjacent uninitialized heap memory back to the attacker. This process allows the attacker to repeatedly "bleed" fragments of the server's RAM, which often contains sensitive data from previous operations or other users.

3. Impact

The severity of this vulnerability stems primarily from the fact that it can be triggered before any authentication takes place. This means that an anonymous attacker on the internet can probe a vulnerable MongoDB instance and begin extracting data without needing a username, password, or any valid session tokens. Because the memory "bled" by the server is uninitialized, it essentially serves as a random window into the server's active RAM.

This exposure is catastrophic for data privacy, as these memory fragments frequently contain highly sensitive information. Security researchers have confirmed that the leaked data can include plaintext database credentials, administrative API keys, environment variables, and fragments of actual BSON documents belonging to other users. MongoDB instances currently exposed to the public internet are at risk, the scale for potential exploitation is massive. Furthermore, since public Proof-of-Concept (PoC) code is already circulating and active exploitation has been confirmed, the window for remediation is closing rapidly for unprotected organizations.

4. Remediation

To mitigate this risk, administrators must update to the minimum patched version for their respective branch as listed below:

MongoDB BranchMinimum Patched Version
8.28.2.3
8.08.0.17
7.07.0.28
6.06.0.27
5.05.0.32
4.44.4.30

If immediate patching is not an option, you should immediately disable zlib compression by setting the --networkMessageCompressors configuration to none, snappy, or zstd.
Additionally, ensure that your firewall or Security Group rules restrict port 27017 to known, trusted IP addresses only.

5. Conclusion

CVE-2025-14847 is a high-priority risk, a patch for the MongoDB product has been deployed by Scaleway and has been deployed to its internal infrastructure.. Users are strongly advised to update as soon as possible because the vulnerability is being used in the wild.

6. Documentation

"React2Shell" Critical Remote Code Execution in React Server

Vulnerabilities

Definition

The vulnerability, identified as CVE-2025-55182 or "React2Shell" is a severe unauthenticated remote code execution (RCE) flaw in the React Server Components "Flight" protocol. Rated with a critical CVSS score of 10.0, this issue allows an attacker to execute arbitrary code on servers utilizing React 19 and associated frameworks like Next.js that implement React Server Components.

How it works

The React Server Components (RSC) system, which relies on the Flight protocol for data serialization between the browser and server, contains a critical vulnerability in specific versions. This flaw involves the unsafe deserialization of specially crafted requests.
Attackers can exploit this vulnerability to gain control over internal objects essential for module resolution and callbacks. In the default configurations of React 19 and Next.js applications utilizing the App Router, this attack vector is particularly critical. It allows unauthenticated attackers to access powerful Node.js primitives, ultimately leading to arbitrary command execution.

Impact

The vulnerability allows for full remote code execution on the React server, posing a severe risk. Exploitation enables attackers to steal sensitive information, move laterally to internal systems, and establish persistent access to the cloud environment through the deployment of cryptominers or backdoors. This flaw is currently being actively exploited, including by threat groups with state affiliations.

Fix

For React Server Components:
Update react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack from versions 19.0–19.2.0 to the patched versions:

  • 19.0.1
  • 19.1.2
  • 19.2.1

For Next.js App Router:
Upgrade to one of the following minimum versions:

  • 15.0.5
  • 15.1.9
  • 15.2.6
  • 15.3.6
  • 15.4.8
  • 15.5.7
  • 16.0.7

After upgrading, redeploy all affected services.

Conclusion

Immediate Action:

  • Inventory: List all React/Next.js workloads.
  • Patch: Apply patches to all React Server Components (RSC) services.
  • Contain: Restrict public access to vulnerable services if possible.
  • Security: Review logs for unauthorized execution, rotate exposed secrets, and increase monitoring on unpatched systems.

Documentation

  • React team advisory – Critical Security Vulnerability in React Server Components (React)
  • GitHub advisory – GHSA-fv66-9v8q-g76r (official package and patch details) (GitHub)
  • NIST - National Vulnerability Database (NIST)
If you need help using this Trust Center, please contact us.
Contact support