I’m an heavy container user, and deployed several containers through container station. Since this new vulnerability will break the security in container environment, does QUTS/QTS been affected by this vulnerability
If so, does QNAP planning to fix this on the mainstream QTS 5.2/QUTS 5.2/QUTS 5.3/QUTS 6.0 beta branches ASAP? Or should I shutdown all containers to prevent further risk.
It depends on your risk tolerance. Just because an exploit is available does not mean that someone will take advantage of that exploit on your machine.
If you are concerned about the risk, I would take all internet exposed containers off the internet.
If your NAS is entirely behind your firewall, you have no worries.
Hi @Sam25 ,
Thank you for bringing this topic to our attention.
QNAP takes information security seriously. For CVE-2026-31431 / “Copy Fail,” QNAP has published an official security advisory here:
https://www.qnap.com/en/security-advisory/qsa-26-16
The advisory provides official information, including the affected scope, non-affected products, and recommended security measures. We recommend referring to this advisory as the primary source of information.
For general risk reduction, users may also review the security measures listed in the advisory, such as limiting shell or terminal access for non-administrator users, using only trusted container images, disabling unnecessary services, and avoiding direct exposure of the NAS to the internet.
Thank you again for helping bring this matter to the community’s attention.
Just been testing my devices here with this PoC: GitHub - rootsecdev/cve_2026_31431: Exploit POC for CVE_2026_31431 · GitHub
I can confirm the info in the security advisory: the only QNAP NAS affected by this issue has an ARM64 CPU (TS-216G running QTS 5.2.9.3451).
[/share/Public] # python3 test_cve_2026_31431.py; echo $?
[*] CVE-2026-31431 detector kernel=5.10.60-qnap arch=aarch64
[i] Kernel 5.10.60-qnap predates the affected 6.12/6.17/6.18 lines; trigger may not apply even if prerequisites match.
[+] AF_ALG + 'authencesn(hmac(sha256),cbc(aes))' loadable - precondition met.
[!] VULNERABLE to CVE-2026-31431.
[!] Marker b'PWND' (AAD seqno_lo) landed in the spliced page-cache page at offset 0.
[!] Surrounding bytes: 50574e444641494c2d53454e (b'PWNDFAIL-SEN')
[!] Apply the upstream fix or block algif_aead immediately.
2
All other arches were OK. 
Edit: here’s an x86-64 (TS-251+ running QTS 5.2.9.3451):
[/share/Public] # python3 test_cve_2026_31431.py; echo $?
[*] CVE-2026-31431 detector kernel=5.10.60-qnap arch=x86_64
[i] Kernel 5.10.60-qnap predates the affected 6.12/6.17/6.18 lines; trigger may not apply even if prerequisites match.
[+] Precondition not met (AF_ALG socket family unavailable (Address family not supported by protocol)). NOT vulnerable.
0
I found it very interesting that only QNAP Arm models are affected. The x86 models must be using a different kernel. In fact, wasn’t someone complaining not long ago that their QNAP was running an “old” Linux kernel? 
I think this particular vulnerability depends on the capabilities of the kernel, as-set at compile time. I guess QNAP compile the aarch64 kernel with options different to the other NAS arches.
But I could be wrong. I’m not a kernel guru. 
Edit: I’ve updated my previous post with the output from an x86-64 NAS that tested OK.
Another edit: The temporary mitigation for the vulnerability is-to blacklist a loadable kernel module, so it might only require recompiling that module.