TL;DR

The copy.fail vulnerability was unveiled on April 29th. Based on our analysis, we found no evidence that this vulnerability could have been used to affect the availability, integrity, or confidentiality of customer data or workloads. The emergency mitigation was fully rolled out on April 30th, 13:00.

What Happened?

On April 29th, 2026, the Xint team published a new major vulnerability named “Copy Fail” (CVE-2026-31431). This vulnerability affects all major Linux kernel versions, including those used on Scalingo hosts. It has been evaluated with a CVSS v3.1 base score of 7.8.

We validated the vulnerability on our platform and confirmed that it allows privilege escalation to root only within a container. We found no evidence of container escape or lateral movement, and no public exploit was available at that time to demonstrate such behavior.

While we found no way to exploit this vulnerability to escape Scalingo isolation layers, we decided, as a precaution, to roll out an emergency mitigation by disabling and denylisting the algif_aead module across the platform. This rollout started on April 30th at 11:30 and completed at 13:00.

Based on an initial assessment that this mitigation might be insufficient, we also ran an emergency restart of all hosting and builder nodes of both the osc-fr1 and osc-secnum-fr1 regions as an additional safeguard. These operations started at 12:30 and were intentionally stopped at 20:04 the same day once we confirmed the mitigation was sufficient.

Incident analysis

Disclosed publicly on April 29, 2026, the vulnerability affects the Linux kernel crypto path involving authencesn, AF_ALG, algif_aead, and splice().

Running a very simple exploit on an affected host allows an unprivileged local user to escalate privileges to root.

Exploiting this vulnerability requires local code execution on an affected host, which is possible on Scalingo application nodes and builders, but not on database and other nodes.

At the time of publication, while the vulnerability could impact a large scope, the only currently known exploit allowed an attacker to become root inside the affected container.

To our knowledge, any potential attacker remains constrained to the container environment allocated to them, and there is no known container escape path associated with the current exploit.

Based on the information available at the time of publication, we found no evidence that a successful attack could allow access to another customer’s data.

However, the vulnerability was still considered critical due to the potential for privilege escalation within a container, and a more advanced exploit could have led to a complete compromise of the underlying host.

What we did

Scalingo took the following actions after the public disclosure:

• Assessed Scalingo exposure to the vulnerability.
• Confirmed exploitability internally.
• Confirmed a mitigation for the vulnerable algif_aead path.
• Applied mitigation on application nodes and builders: disabling of the vulnerable module

All host kernels will be patched through Scalingo’s standard patching policy.

What you should do

No immediate action is required for Scalingo PaaS customers.

Customers using Scalingo DBaaS add-ons may review their configured maintenance windows if they want control over the timing of standard database maintenance.

What we will do in the future

Scalingo will:

• Patch all hosts through the standard patching policy.
• Update this bulletin if new relevant information becomes available.

Product Impacts

Scalingo PaaS

The mitigation was applied on all application runtime nodes and builders. This mitigation was effective on April 30th at 13:00.

Between 2026-04-30 16:15 and 18:15, we experienced a temporary service degradation. During node restarts, traffic shifted toward older nodes, and our load balancing did not redistribute it quickly enough, leading to increased load on those nodes.

Based on currently known exploitation techniques, a successful attack would result in root access within the attacker’s own container only.

We found no evidence that it could allow access to another customer’s data.

Scalingo DBaaS Add-ons

Scalingo does not allow customer-controlled code execution on managed database nodes. As a result, the known exploit path is not directly reachable by customers in that context.

The mitigation has already been applied to these nodes, and they will be updated through our standard database maintenance process.

Managed database services were not affected by the performance degradation that impacted the application runtime during node restarts.

Other Scalingo Add-ons and Services

Other Scalingo add-ons and services were affected by the vulnerability, but as no customer code can be executed on these components, they were not exploitable in practice. The mitigation was applied to them, and they continued to operate normally throughout.

Contact

If you have any questions or require further assistance, please contact our support team. We remain committed to ensuring the security of our platform and the protection of our users’ data.

Timeline

Changelog

2026-05-05: Initial publication of SSB-2026-001