pyn3rd

My presentation video in BlackHat Asia 2023. Hope you like it!😄❤️@BlackHatEvents youtu.be/8Qyghv00vEQ?si…

@steventseeley Before enlightenment: chop wood, carry water. After enlightenment: chop wood, carry water.

Security researchers become trapped into an identity that they can’t escape, life seems purposeless, reality shifts and they realize they can’t bend like a tree in the wind. It turns out that intelligence isn’t the key to happiness. For those that know. Chop wood, carry water.

@spendergrsec I definitely agree that this is not an appropriate approach.:-)

@pyn3rd x.com/spendergrsec/s…

As a mitigation, the Linux command echo 3 > /proc/sys/vm/drop_caches can be used to forcibly flush the page cache in cases where the cache may have been contaminated by CopyFail-induced artifacts. However, this may introduce a sharp increase in I/O latency and CPU starvation due to cache-miss amplification. It is strongly recommended to assess the potential impact on production workloads before applying this approach in a k8s environment.

This is somewhat controversial. From my perspective, the vendor recommends flushing the page cache as a temporary mitigation rather than a permanent fix—the proper solution is still to upgrade. However, in real-world incident response, this is not always straightforward. Some argue that even as a temporary measure, clearing the cache may compromise subsequent forensic analysis and attack traceability. Others believe that immediate containment to prevent further impact should take priority. I’m sharing this here to get the community’s perspective.

@pyn3rd Find a new vendor!

@spendergrsec To be honest, I’m referring to a vendor-provided temporary workaround, and love to discuss it in the community.:-)

@zer0pntr I’m referring to a vendor-provided temporary workaround. Please read the context carefully before commenting. In previous messages, we already discussed its side effects on system performance, attack traceability, and log auditing. I’ve also already emphasized my viewpoint.

@pyn3rd 😂 3 is a one shoot action, not a permanent one. Read before posting bullshit...

@spendergrsec I’m referring to a vendor-provided temporary workaround. It’s not a good solution and may introduce side effects, as mentioned earlier. Happy to share and discuss it.

@pyn3rd wat

@GrowlerEnjooyer In many cases, what matters more for the business is immediate mitigation and keeping the system stable. Incident response and “stopping the bleeding” usually take priority, while forensic analysis and root cause tracing are typically handled afterward.

@pyn3rd But wouldn't module blacklisting (if possible) or installing SELinux policy be better? They are just as easy to implement (shell one-liner), more effective, and give you the opportunity to preserve the forensic trail (eg. dump page cache before reboot)

@GrowlerEnjooyer I fully agree with that recommendation, but in practice I see that many people tend to prioritize immediate mitigation (damage control) first, and only then move on to forensics and auditing.😄

@pyn3rd So based on all that I think I'd explicitly recommend *not* performing the above steps 🥴

@GrowlerEnjooyer Undoubtedly, this also makes forensic analysis and attack traceability more difficult.

@pyn3rd Also if your system has already behind pwned by CopyFail this just removes the evidence

@GrowlerEnjooyer Exactly. I saw this proposed in the customer solution, but it doesn’t look like a proper mitigation. I think it’s just a temporary workaround to prevent victims from actively loading corrupted page cache.

@pyn3rd Is that really a mitigation? The system is still vulnerable to CopyFail after running that

There are two attack paths: Kubernetes-to-host escape and cross-container attacks. In practice, escaping from Kubernetes to the host is significantly harder to exploit, but the impact is much greater.

CopyFail is really an impressive research! If CopyFail achieves a k8s-to-host escape, it would still need to corrupt the host’s page cache. However, there is no guarantee that the corrupted page cache will be reliably used—especially since the runc execution path has already been patched. Are there other scenarios where this vulnerability could still be exploited?🤔@xint_official

@Random_Robbie Lovely!

@skyworship2 Same here! I guess there’s probably a whole new way to explore things.

@pyn3rd I am waiting for it so.maybe another self/exe trick?

Tweetable one-line RCE on GitHub.com - the potential for AI-assisted closed source bug hunting is insane 💥

#CVE-2026-40466 is a bypass of CVE-2026-34197 in Apache ActiveMQ, exploiting the vm:// protocol to achieve Remote Code Execution