A recent ransomware incident at Coca-cola owned dairy company Fairlife provides a potent example of network edge devices being targeted for exploitation, and of the scale of outcomes attackers can achieve by exploiting them.
According to reporting from MSN and others, the ransomware attack caused Fairlife to temporarily suspend production across its U.S. facilities after an unauthorized third party gained access to systems that included production-related infrastructure. Eleven days after the initial disclosure, Coca-Cola said the majority of production had resumed.
The Anubis ransomware group claimed responsibility. The group said it encrypted Fairlife’s Nutanix systems and stole approximately 1 TB of data. Coca-Cola subsequently confirmed that data had been taken, although it has not publicly validated all of Anubis’s claims about the attack.
According to published reporting, Anubis exploited CitrixBleed 2 (CVE-2025-5777) to gain initial access to Fairlife’s environment before encrypting its Nutanix infrastructure. The resulting ransomware incident suspended U.S. production, with the majority of production restored 11 days after Coca-Cola’s initial disclosure.
Regardless of what further details emerge about this specific incident, it is clear that network edge devices are increasingly being used as an initial intrusion path. This trend is consistently observed in reporting from Verizon, Mandiant, and other security researchers. Defense strategies need to catch up.
Network appliances have become a high-value path into enterprise infrastructure. And once an attacker gets through one of these devices, installing a patch does not establish that the device, its credentials, or the environment behind it can still be trusted.
Patching can close the vulnerability without removing the compromise
CitrixBleed 2 is an insufficient input validation vulnerability affecting NetScaler ADC and NetScaler Gateway. It allows an unauthenticated attacker to read memory from a vulnerable appliance, potentially exposing credentials and session tokens.
A patch has been available for CitrixBleed 2 since 2025. But patching does not eliminate all the risk. Updating the appliance closes the vulnerability, but does not automatically invalidate session material an attacker obtained before the update. An organization can therefore have a NetScaler reporting the corrected software version while an attacker retains access established before remediation.
Patching is as urgent as ever, but security teams also need to determine whether the device was compromised before the patch, whether credentials or sessions were exposed, whether unauthorized changes occurred, and whether the attacker established another path into the environment.
Attackers are concentrating on the network edge
The Fairlife incident fits a broader shift toward internet-facing network infrastructure.
Verizon’s 2025 Data Breach Investigations Report found that edge devices and VPNs accounted for 22% of targets involved in vulnerability exploitation, up from 3% the previous year. That is an increase of almost eightfold. Verizon also found that organizations fully remediated only about 54% of the edge vulnerabilities it tracked during the year, with a median remediation time of 32 days.
Attackers do not operate on that schedule, as noted by JPMorgan Chase Global CISO Pat Opet in his RSA 2026 Keynote, stating: “The very devices that are supposed to be our frontline defense are turning into our greatest weakness. I would argue that the mean time to adapt those devices is on a potentially decade scale, versus the speed of the attacker which is on a daily scale.”
VulnCheck analyzed 884 vulnerabilities with first-time exploitation evidence during 2025. Nearly 29% showed evidence of exploitation on or before the day the CVE was published. Network edge devices, including firewalls, VPNs, and proxies, were the most frequently targeted technology category.
Mandiant reached a similar conclusion from incident response investigations. Its M-Trends 2026 data found that vulnerability exploitation remained the most common initial infection vector for the sixth consecutive year, accounting for 32% of observed intrusions where the initial vector was identified. Mandiant also reported sustained attacker interest in edge and core network devices because these systems frequently lack support for traditional security tooling.
The problem is not simply that network appliances contain vulnerabilities. Every sufficiently complex technology does. The problem is the combination of exposure, exploitation speed, privileged network position, and limited security visibility.
A VPN gateway, firewall, or other edge appliance is reachable by design. It often controls or observes valuable traffic. At the same time, security teams typically have less ability to inspect what is happening inside the device than they do on a conventional endpoint or server.
That makes the edge an attractive place to get in and an effective place to remain hidden.
Patching is falling behind while vulnerabilities ramp up
Vulnerability management is necessary. But vulnerability management alone cannot answer whether an attacker got there first.
The number of disclosed vulnerabilities continues to rise, increasing the workload on teams already managing large remediation queues. At the same time, exploitation is moving closer to disclosure and, in some cases, preceding it.
This breaks the familiar defensive sequence: Discover vulnerability. Assign severity. Scan the environment. Prioritize affected systems. Deploy the update.
If exploitation starts before disclosure, there may be no meaningful patch window. A vulnerability may be exploited before a scanner has a detection for it, before it appears in a prioritized catalog, or before a security team has enough information to determine its significance.
CVSS scores and exploited-vulnerability catalogs remain useful inputs. They cannot provide evidence about what happened on a specific device before remediation. For exposed network infrastructure, teams need both vulnerability management and compromise assessment. Often, the latter is hard to come by. Network devices are opaque by design, with their underlying Linux or FreeBSD internals hidden from customers behind vendor-specific interfaces that limit the access and visibility increasingly needed to assure the infrastructure has not been compromised.
FortiBleed shows why version numbers are insufficient
FortiBleed provides another example of the same problem from a different direction.
The campaign targeting Fortinet FortiGate appliances is not a single new vulnerability with a single corrective patch. Attackers have used stolen credentials, exposed management interfaces, legacy credential storage, and previously compromised devices to maintain or regain access.
Fortinet introduced PBKDF2-based storage for administrator passwords to replace older SHA-256-based hashes. But upgrading the firmware did not necessarily migrate every existing credential immediately. Administrator passwords could remain stored using the older scheme until the corresponding administrator logged in after the upgrade. That means the device could be running current firmware while still containing credential material requiring remediation.
Compromised appliances can also contain unauthorized administrator accounts or other persistence mechanisms. Eclypsium research has documented symlink-based persistence capable of surviving both reboot and firmware upgrade.
None of those conditions can be ruled out by reading a version string, which is all you get from most traditional vulnerability management tools.
A scanner can tell you that a FortiGate has been updated. That is useful. But it can’t, from the version alone, tell you whether the device is concealing an unauthorized administrator, whether legacy credential material remains exposed, whether its configuration has been modified, or whether persistence is present on the appliance.
Assume the edge may already be compromised
Organizations need to patch quickly, especially when an internet-facing appliance has a known exploited vulnerability. But the response cannot stop with the patch.
For high-risk network infrastructure, remediation should answer two separate questions:
- Is the known vulnerability closed?
- Is there evidence that the device was compromised before or after remediation?
The first question is vulnerability management. The second requires device-level verification and threat detection.
What happened at Fairlife demonstrates the operational stakes. A ransomware incident involving production-related systems was enough to suspend U.S. manufacturing operations. FortiBleed demonstrates the technical problem from another angle: current firmware does not prove that credentials, configuration, or the underlying appliance remain trustworthy.
As exploitation moves toward infrastructure that is internet-facing, privileged, and difficult for conventional security controls to inspect, security teams need evidence about the state of the device itself.
You cannot validate an active threat by treating the device as a black box
Network appliances create a particular detection problem.
Traditional EDR is built around operating systems where an agent can observe processes, files, memory, and other endpoint activity. Network appliances frequently do not allow third-party agents or provide equivalent access to their underlying components. Vulnerability scanners generally identify software versions and known exposures, but version information does not establish device integrity, nor verify that the device is not already compromised.
This leaves security teams with a visibility gap that attackers are, increasingly, targeting.
Eclypsium’s approach is to inspect and continuously monitor devices for the conditions that version-based vulnerability management cannot establish on its own. That includes device and firmware posture, configuration changes, integrity failures, known threats, and other evidence that a device has diverged from an expected state.
Eclypsium can detect CVE-2025-5777 as well as other vulnerabilities and exploitation activities on network edge devices across a wide range of vendors, including Citrix, Fortinet, Palo Alto Networks, Cisco, Ivanti, SonicWall, and others that have recently been involved in attacks on major companies and U.S. critical infrastructure.
This complements existing EDR and vulnerability management controls rather than replacing them. Those tools continue to cover the layers they were designed to monitor. The missing control is independent validation of infrastructure that those tools often have limited ability to inspect. Enterprises use Eclypsium to establish what should be present on the device, monitor for changes, and identify evidence that the device can no longer be trusted.
To learn more about how Eclypsium verifies device integrity, hardens against risk, and detects active compromises in network edge devices, visit our Infrastructure Assurance Platform page.
Frequently Asked Questions
Fairlife, a Coca-Cola-owned dairy company, disclosed a ransomware attack that disrupted production across its U.S. facilities. The Anubis ransomware group claimed responsibility for the attack and said it encrypted Fairlife’s Nutanix infrastructure and stole approximately 1 TB of data. According to published reporting, Anubis exploited CitrixBleed 2 (CVE-2025-5777) to gain initial access. Coca-Cola later confirmed that data was stolen and reported that the majority of production had resumed 11 days after its initial disclosure.
CitrixBleed 2 is the name commonly used for CVE-2025-5777, an insufficient input validation vulnerability affecting Citrix NetScaler ADC and NetScaler Gateway. An unauthenticated attacker can exploit the vulnerability to read memory from an affected appliance, potentially exposing sensitive information such as session tokens and credentials.
No. Patching closes the vulnerability, but it does not establish that the device was clean before the update or invalidate every credential or session an attacker may have obtained. Organizations responding to CitrixBleed 2 should assess affected appliances for evidence of compromise and address exposed sessions or credentials in addition to installing the update.
Network edge devices such as VPN gateways, firewalls, and application delivery controllers are often internet-facing and occupy privileged positions in enterprise networks. They can also provide less security telemetry than conventional endpoints and servers. Verizon’s 2025 DBIR found that edge devices and VPNs accounted for 22% of targets involved in vulnerability exploitation, up from 3% the previous year.
Vulnerability scanning can identify known vulnerabilities and determine whether a device appears to be running an affected software version. It does not necessarily determine whether the device has already been compromised. A device can be patched while still containing unauthorized accounts, persistence mechanisms, configuration changes, or other evidence of previous attacker activity.
Yes. Installing current firmware does not by itself prove that a network device is clean. Attackers may have obtained credentials, created unauthorized accounts, changed configurations, or established persistence before the update. Eclypsium’s FortiBleed research documents examples of conditions that can remain after patching, including persistence capable of surviving firmware upgrades.
Patching addresses a known vulnerability by updating affected software or firmware. Device integrity verification determines whether the device remains in an expected, trusted state. That requires examining the device for unauthorized modifications, configuration drift, persistence, rogue accounts, and other indicators that cannot be established from a version number alone.
Organizations should combine rapid vulnerability remediation with continuous monitoring and device integrity validation. For high-risk network infrastructure, teams need to determine both whether known vulnerabilities have been closed and whether there is evidence that the device was compromised before or after remediation. Eclypsium helps security teams monitor device and firmware posture, detect integrity failures and threats, and identify changes that indicate a device has diverged from its expected state.
