Mitigating CVE-2026-31431 (“Copy Fail”) in Docker Engine

Mitigating CVE-2026-31431 ("Copy Fail") in Docker Engine

Skip to content

Insights on the state of AI agents from 800+ builders and leaders. Download your copy

✕

[](https://www.docker.com/)

• Products

AI and Agents

• Docker Sandboxes New Isolated environments for coding agents
• AI Governance New Govern agents and Claws across every team
• Gordon New Your AI Agent across Docker
• Docker Model Runner Local-first LLM inference made easy
• Docker MCP Catalog and Toolkit Connect and manage MCP tools

Application Security

• Docker Hardened Images Ship with secure, enterprise-ready images
• Docker Scout Simplify the software supply chain

Application Development

• Docker Desktop Containerize your applications
• Docker Hub Discover and share container images
• Docker Offload Break free of local constraints
• Docker Build Cloud Speed up your image builds
• Testcontainers Desktop Local testing with real dependencies

• Support

Developers

• Documentation Find guides for Docker products
• Getting Started Learn the Docker basics
• Resources Search a library of helpful materials
• Training Skill up your Docker knowledge
• Extensions SDK Create and share your own extensions
• Community Connect with other Docker developers
• Open Source Explore open source projects
• Preview Program Help shape the future of Docker
• Customer Stories Get inspired with customer stories

Get the latest Docker news

• Pricing- [x] Yearly Monthly ## Docker Personal ### $0 ### $0 For individual developers who need the essential tools to build and deploy containers. Get started Get started #### Includes: #### Docker Desktop #### Docker Engine + Kubernetes #### Docker Hub #### Docker Scout #### Docker Debug #### Included usage: #### 1 user #### 1 Docker Scout-enabled repo* #### 100 Docker Hub pulls/hr* #### 1 private Docker Hub repo #### Docker Build Cloud and Testcontainers Cloud free trial ## Docker Pro ### $11 ### $9 per user/month For individual professionals who require more advanced features and additional resources. Buy now Buy now #### Includes: #### Docker Build Cloud #### Testcontainers Cloud #### Synchronized File Shares #### Visibility into Docker Scout health scores #### 5 business day support response #### Included usage: #### 1 user #### 2 Docker Scout-enabled repos #### Unlimited Docker Hub pull rate #### 200 Docker Build Cloud build minutes #### 100 Testcontainers Cloud runtime minutes MOST POPULAR ## Docker Team ### $16 ### $15 per user/month For small teams that need collaborative tools to make working together more efficient. Buy now Buy now #### Includes: #### Add users in bulk #### Audit logs #### Docker Hub role-based access control #### 2 business day support response #### Included usage: #### Up to 100 users #### Unlimited Docker Scout-enabled repos #### Unlimited Docker Hub pull rate #### Unlimited private Docker Hub repos #### 500 Docker Build Cloud build minutes #### 500 Testcontainers Cloud runtime minutes #### 10 Organization access tokens #### 1 Docker Hub organization ## Docker Business ### $24 ### $24 per user/month For enterprises desiring robust security, control, and compliance features. Buy now Buy now Contact sales Contact sales #### Includes: #### Hardened Docker Desktop #### Single Sign-On (SSO) #### SCIM user provisioning #### Image and Registry Access Management #### Desktop Insights Dashboard #### Enhanced container Isolation (ECI) #### Purchase via invoice #### 1 business day support response #### Included usage: #### No user cap #### Unlimited Docker Scout-enabled repos #### Unlimited Docker Hub pull rate #### Unlimited private Docker Hub repos #### 1,500 Docker Build Cloud build minutes #### 1,500 Testcontainers Cloud runtime minutes #### 100 Organization access tokens #### Unlimited Docker Hub organizations*** ## Docker Hardened Images (DHI)

Secure, minimal container images for every team, free with enterprise features, if needed. Start Free Trial

• Blog
• Docs

Search

Sign InGet Started

Toggle menu

Mitigating CVE-2026-31431 (“Copy Fail”) in Docker Engine

Posted May 27, 2026

CVE-2026-31431 is a Linux kernel vulnerability that was recently disclosed. This CVE does not compromise Docker infrastructure.

That said, Docker Engine’s default profiles prior to v29.4.3 allowed containers to create AF_ALG sockets, which is the syscall surface the exploit uses. You are not exposed if you are running Docker Engine v29.4.3 or later, OR a patched host kernel. If either of those is missing, you have exposure on that host, and you should read the rest of this post.

As of writing, the kernel patch is available on Debian (CVE-2026-31431) and RHEL 9 (RHSB-2026-002) butnot yet on Ubuntu. For users on distros that haven’t shipped a kernel fix, upgrading Docker Engine is the mitigation you can apply today.

**Why you should read about Copy-Fail**

This CVE drew a lot of attention because the exploit became public before many Linux distributions had kernel patches available. As a result, most distros were still vulnerable and had no ready fix at the time of disclosure. It was especially notable because the bug affected Linux kernels going back to around 2017, making the potential impact unusually broad.

On the Docker Engine team, I started investigating what we could do from our end to protect users on vulnerable hosts. It turned out the mitigation was more involved than it first looked, and the first attempt broke 32-bit binaries. This post is what we shipped, what broke, what we learned, and where things stand now.

**What Copy Fail is**

On April 29, researchers disclosed CVE-2026-31431, dubbed “Copy Fail,” a privilege escalation vulnerability in the Linux kernel’s AF_ALG crypto subsystem.

The flaw is in the algif_aead module. It allows any unprivileged user with access to an AF_ALG socket to perform controlled writes to the page cache. Since the page cache backs file reads across the entire system, an attacker can temporarily modify the contents of any readable file as seen by every process on the host. Corrupting a setuid binary is the most direct path to local root, but the primitive itself is more general.

The exploit is trivial and works on every unpatched Linux kernel shipped since 2017.

The correct fix is a kernel update. The mitigations described below reduce exposure for containers running on unpatched kernels, but they do not fix the underlying vulnerability. If your kernel vendor has released a patch, apply it.

What does this mean for containers?

Inside a container running with default security profiles, an attacker with code execution can use Copy Fail to corrupt pages in the page cache. One possible outcome is escalating to root inside the container by corrupting setuid binaries.

But the page cache is shared across the host, so the impact is not confined to the attacker’s container. Modified pages are visible to the host and to every other container that maps the same file, including shared image layers. Other workloads on the same node can be affected.

The attack does not require any special capabilities or privileges beyond what a default container provides. The only requirement is the ability to create an AF_ALG socket, which was previously allowed by Docker’s default security profiles.

**First attempt: seccomp (v29.4.2)**

We updated Docker Engine’s default seccomp profile to block AF_ALG sockets. The seccomp filter inspects the first argument to socket(2) and denies address families AF_ALG and AF_VSOCK (which was already blocked).

Blocking socket(2) is not enough on its own. There is another way to create sockets on x86_64 Linux: socketcall(2), an older multiplexed syscall that wraps socket, bind, connect, and other socket operations behind a single syscall number.

There is another way to create sockets on Linux: `socketcall(2)`, an older multiplexed syscall that wraps socket, bind, connect, and other socket operations behind a single syscall number.

The problem for seccomp is that socketcall packs the real arguments (including the address family) into a userspace array and passes a pointer, which BPF cannot dereference and inspect. There is no way to selectively block AF_ALG through socketcall with seccomp.

Linux 4.3 already added direct socket syscalls for i386 and s390, so we assumed most modern binaries would already use the new socket syscall and that socketcall would only matter for old binaries. So we blocked it entirely and shipped Docker Engine v29.4.2 (release notes).

What broke

The socketcall deny turned out to be too broad.

Older versions of glibc on i386 route all socket operations through socketcall, the Go runtime uses it unconditionally for GOARCH=386 (independent of glibc), and many legacy and gaming workloads (SteamCMD, Wine) depend on it.

Blocking socketcall broke networking for a lot of 32-bit binaries running inside a container (moby/moby#52506).

And this is not just an i386 problem. On amd64, any process can switch into ia32 compatibility mode with int $0x80 and invoke socketcall directly, bypassing the socket(2) arg filter entirely. You do not need a 32-bit container or a 32-bit binary to reach that path.

Affected containers could work around this by using a custom seccomp profile that re-enables socketcall while keeping AF_ALG blocked for the direct socket(2) path.

But that just pokes a hole in the hardening for those containers, since an attacker inside them could still reach AF_ALG through socketcall.

**Second attempt: LSM-based enforcement (v29.4.3)**

The fundamental problem is that seccomp operates at the syscall boundary, and socketcall multiplexes many operations behind a single syscall number with pointer arguments. You cannot selectively block AF_ALG through socketcall with seccomp alone.

AppArmor and SELinux operate on a different level. Linux Security Modules hook directly into the kernel’s security_socket_create() callback, which fires when the kernel actually creates the socket object, regardless of which syscall entry point was used. An LSM can deny AF_ALG specifically while leaving all other socketcall usage intact.

In v29.4.3 (release notes), we:

1. Reverted the `socketcall` seccomp deny to restore 32-bit compatibility.
2. Added `deny network alg,` to the default AppArmor profile (moby/profiles#22).

On systems with AppArmor enabled (e.g. Ubuntu, Debian), this blocks AF_ALG through both socket(2) and socketcall(2).

1. Integrated a SELinux CIL policy module for systems running SELinux (Fedora, RHEL, CentOS).

The module denies alg_socket creation for all container_domain types and can be loaded via semodule.

SELinux enforcement requires the daemon to be running with --selinux-enabled.

1. Kept the seccomp `socket(AF_ALG)` arg filter as defense-in-depth for the direct socket(2) syscall path.

What you should do

1. Patch your kernel.

This is the real fix.

Check with your distribution for a kernel update that addresses CVE-2026-31431.

1. Upgrade Docker Engine to v29.4.3 or later. You get the updated seccomp + AppArmor + SELinux defaults. A systemctl restart docker (or equivalent) is enough; no host reboot required.
2. If you cannot upgrade the kernel or the engine immediately:

• Blacklist the kernel modules: add blacklist af_alg and blacklist algif_aead to /etc/modprobe.d/.

This only works if the modules are built as loadable modules (CONFIG_CRYPTO_USER_API=m), not compiled into the kernel.

• Apply a custom seccomp profile that denies AF_ALG using --security-opt seccomp=/path/to/profile.json or the seccomp-profile option in daemon.json.

Closing thoughts

Security comes in layers, and sometimes no single layer is enough. Seccomp blocks socket(AF_ALG) on every system but is blind to socketcall. AppArmor and SELinux block both paths, but they depend on host configuration. Together, they cover what neither can alone.

On systems without an LSM, the socketcall path remains unblocked from Docker’s side. Ultimately, the kernel bug is what needs to be fixed.

Kernel vulnerabilities will keep coming. When they do, the container runtime is often the fastest place to deploy a mitigation, because updating the engine is one change that protects every container on the host. The Copy Fail timeline made that especially clear: the embargo broke before distros had fixes ready, and for several days the engine was the only place users could mitigate anything without waiting for a kernel rebuild.

Keeping Docker Engine up to date is not just about new features. It is one of the most effective ways to shrink the window between a kernel CVE going public and your workloads being protected against it.

Table of contents

[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fmitigating-cve-2026-31431-copy-fail-in-docker-engine%2F "Visit this Linkedin profile")[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Fmitigating-cve-2026-31431-copy-fail-in-docker-engine%2F "Visit this X profile")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.docker.com%2Fblog%2Fmitigating-cve-2026-31431-copy-fail-in-docker-engine%2F "Visit this Facebook profile")

Related Posts

• May 12, 2026 #### Docker AI Governance: Unlock Agent Autonomy, Safely Introducing Docker AI Governance: centralized control over how agents execute, what they can reach on the network, which credentials they can use, and which MCP tools they can call, so every developer in your company can run AI agents safely, wherever they work. Your laptop is the new prod Agents are the biggest productivity unlock… 
• Docker Captain May 26, 2026 #### The Untrusted Autonomous Workload: How AI Coding Agents Reshape What Isolation Has to Do Learn why AI coding agents need stronger isolation, how Docker Sandboxes use microVMs, and what secure autonomous workloads require. 
• May 19, 2026 #### Meet Gordon: Docker’s AI Agent For Your Entire Container Workflow Gordon understands your environment, proposed fixes, and takes action across your entire Docker workflow. Now generally available. 
• May 18, 2026 #### Coding Agent Horror Stories: The Security Crisis Threatening Developer Infrastructure Explore real AI coding agent security failures, from database wipes to secrets leakage, and learn how Docker Sandboxes reduce the blast radius. 

Products

• Products Overview
• Docker Desktop
• Docker Hub
• Docker Scout
• Docker Build Cloud
• Testcontainers Desktop
• Testcontainers Cloud
• Docker MCP Catalog and Toolkit
• Docker Hardened Images

Features

• Command Line Interface
• IDE Extensions
• Container Runtime
• Docker Extensions
• Trusted Open Source Content
• Secure Software Supply Chain

Developers

• Documentation
• Getting Started
• Trainings
• Extensions SDK
• Community
• Open Source
• Preview Program
• Newsletter

Pricing

• Personal
• Pro
• Team
• Business
• Premium Support and TAM
• Pricing FAQ
• Contact Sales

Company

• About Us
• What is a Container
• Blog
• Why Docker
• Trust
• Customer Success
• Partners
• Events
• Docker System Status
• Newsroom
• Swag Store
• Brand Guidelines
• Trademark Guidelines
• Careers
• Contact Us

Languages

• English
• 日本語

• [](http://twitter.com/docker)
• [](https://www.linkedin.com/company/docker)
• [](https://www.instagram.com/dockerinc/)
• [](http://www.youtube.com/user/dockerrun)
• [](https://www.facebook.com/docker.run)
• [](https://www.docker.com/blog/feed)

© 2026 Docker Inc. All rights reserved

Terms of ServicePrivacyLegal

Do Not Sell My Personal Information

This website uses cookies to enhance user experience and to analyze performance and traffic on our website. We also share information about your use of our site with our social media, advertising and analytics partners.

Do Not Sell My Personal Information Accept Cookies

Do Not Sell My Personal Information

When you visit our website, we store cookies on your browser to collect information. The information collected might relate to you, your preferences or your device, and is mostly used to make the site work as you expect it to and to provide a more personalized web experience. However, you can choose not to allow certain types of cookies, which may impact your experience of the site and the services we are able to offer. Click on the different category headings to find out more and change our default settings according to your preference. You cannot opt-out of our First Party Strictly Necessary Cookies as they are deployed in order to ensure the proper functioning of our website (such as prompting the cookie banner and remembering your settings, to log into your account, to redirect you when you log out, etc.). For more information about the First and Third Party Cookies used please follow this link.

More information

Allow All

Manage Consent Preferences

#### Strictly Necessary Cookies

Always Active

These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.

#### Sale of Personal Data

• [x] Sale of Personal Data

Under the California Consumer Privacy Act, you have the right to opt-out of the sale of your personal information to third parties. These cookies collect information for analytics and to personalize your experience with targeted ads. You may exercise your right to opt out of the sale of personal information by using this toggle switch. If you opt out we will not be able to offer you personalised ads and will not hand over your personal information to any third parties. Additionally, you may contact our legal department for further clarification about your rights as a California consumer by using this Exercise My Rights link.

If you have enabled privacy controls on your browser (such as a plugin), we have to take that as a valid request to opt-out. Therefore we would not be able to track your activity through the web. This may affect our ability to personalize ads according to your preferences.

• ##### Performance Cookies

• [x] Switch Label label

These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.

• ##### Targeting Cookies

• [x] Switch Label label

These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.

Cookie List

Clear

• [x] checkbox label label

Apply Cancel

Consent Leg.Interest

• [x] checkbox label label

• [x] checkbox label label

• [x] checkbox label label

Confirm My Choices

%20in%20Docker%20Engine&tw_document_href=https%3A%2F%2Fwww.docker.com%2Fblog%2Fmitigating-cve-2026-31431-copy-fail-in-docker-engine%2F&tw_iframe_status=0&tw_order_quantity=0&tw_pid_src=1&tw_sale_amount=0&twpid=tw.1779924320137.930794629983353424&txn_id=nv75j&type=javascript&version=2.3.53)%20in%20Docker%20Engine&tw_document_href=https%3A%2F%2Fwww.docker.com%2Fblog%2Fmitigating-cve-2026-31431-copy-fail-in-docker-engine%2F&tw_iframe_status=0&tw_order_quantity=0&tw_pid_src=1&tw_sale_amount=0&twpid=tw.1779924320137.930794629983353424&txn_id=nv75j&type=javascript&version=2.3.53)