Citrix Bleed 2: Critical Netscaler security gap exploited for almost a month
In the last week of June, suspected Chinese actors were already looking for vulnerable Netscaler devices. Citrix has a tip for its customers.
(Image: heise online / dmk)
The security vulnerability nicknamed “Citrix Bleed 2” has apparently been known to attackers for longer than initially assumed. This was discovered by a provider of attack detection solutions. Using historical data, which they compared with the signatures of the exploit, they found an attempted attack on one of their honeypots, i.e., a server that was only apparently vulnerable, on June 23, 2025.
This is almost exactly one week after Citrix released patches for CVE-2025-6543 and CVE-2025-5777, the critical flaw later dubbed “Citrix Bleed 2” by security researchers. The security company ReliaQuest had also already suspected at the end of June that there was an actively exploited exploit, but found only circumstantial evidence and no hard proof.
Videos by heise
Who had the first exploit?
The evidence is now there, writes Greynoise. And apparently these were not untargeted scans, but targeted attack attempts that targeted a honeypot disguised as an outdated netscaler. These early attack attempts came from IP addresses in China, reports Greynoise.
Security researcher Kevin Beaumont also pointed out the early attempts to exploit the vulnerability a few days ago. At that time, Citrix still denied that “Citrix Bleed 2” had ended up in the arsenal of cybercriminals or state hackers. On July 10 at the latest, however, the denials came to an end when the US cyber security authority CISA included the vulnerability in its “Known Exploited Vulnerabilities Catalog”. One day later, Imperva, another threat intelligence company, reported over 11.5 million attack attempts, mainly against targets in the USA, Spain, and Japan.
Almost 4,000 netscalers still vulnerable
Meanwhile, the volume of attacks has remained stable. Between July 14 and 16, the Shadowserver project recorded around 3,000 attack attempts per day on thirty to forty targets, while Greynoise only recorded three attacker IPs during the day on July 17. However, the number of vulnerable devices made a surprisingly large jump in mid-July and now stands at over 4,500 according to Shadowserver statistics, so admins of Netscaler installations should check their devices and update them as soon as possible.
(Image:Â The Shadowserver Foundation)
Kevin Beaumont provides a list of over 25,000 Netscaler instances accessible from the Internet on Github, of which 3,829 were still vulnerable on the morning of July 18. Almost five hundred of these vulnerable Netscalers report a domain ending with the German country code “.de”.
New information in slices
And Citrix? They had at least published patches, but otherwise used salami tactics and omitted important information on the severity of the vulnerability and how to deal with it. Security researcher Beaumont did not hold back with his criticism of what he saw as Citrix's overly hesitant approach. In a blog post, he criticizes the fact that Netscaler's own Web Application Firewall (WAF), of all things, is unable to intercept attack attempts, whereas those of other manufacturers can. In the “Frequently Asked Questions” on Citrix Bleed 2, Citrix even goes so far as to say that WAFs cannot prevent the attack at all – a bold statement because the exploit works by means of several HTTP requests.
Beaumont also does not have a good word to say about other tips for Citrix administrators. Cleanup system commands for deleting connections controlled by attackers are incomplete because they do not clean up session data, according to the security researcher.
Beaumont told heise security that Citrix's response was unacceptable. “They were far too late in providing information about attack activity and notices about the impact assessment,” said Beaumont.
The nickname “Citrix Bleed 2” refers to a flaw in the memory management of Netscaler devices that attackers can exploit remotely via the web. If they make an HTTP request with a specific, incorrect parameter, the device responds with a few bytes of its main memory, it “bleeds memory”. These memory dumps can contain useless data but also session and other sensitive information.
(cku)
