Paidwork Breach Exposes 23 Million Users While SonicWall Zero-Days Deploy Custom Malware

# Paidwork Breach Exposes 23 Million Users While SonicWall Zero-Days Deploy Custom Malware The Technology sector is currently absorbing a disproportionate amount of the world's misery, ranking first of 15 sectors this week with 373 stories. Today alone, 68 new incidents have landed on the wire. While the press releases will inevitably describe these as "sophisticated attacks," a look at the paperwork suggests a more mundane reality: the tools we use to manage our organisations are becoming the primary vectors for their collapse. The most concerning trend isn't the volume of attacks, but where they are landing. We are seeing a concerted effort to compromise the "plumbing"—the middle-ware and gateway appliances that sit between a company and the internet. Take the current situation with SonicWall. State-sponsored actors, tracked as UTA0533, have been exploiting two zero-day vulnerabilities in SMA1000 appliances. This wasn't a quick smash-and-grab. These attackers spent weeks deploying custom malware before a patch was even conceptualised. When a gateway is compromised, the internal network is essentially a trust-exercise gone wrong. Then there is the ServiceNow situation. A critical remote code execution flaw is being actively exploited in the wild. For those unfamiliar with the administrative burden, ServiceNow is the software that many enterprises use to track everything from HR requests to IT tickets. It is the central nervous system of the corporate office. When an attacker gains root access to the system that manages your tickets, they aren't just stealing data; they are stealing the map of how the entire company operates. And if you prefer the sheer scale of data loss, look at Paidwork. A breach there has exposed the banking and personal data of 23 million users. It's a staggering number, though in the current climate, it almost feels like a rounding error. The industry's response is usually a flurry of patches and a carefully worded apology. But the regulatory machinery moves at a different pace. In Brussels, the focus is often on the 72-hour reporting window mandated by GDPR. The problem is that the 72-hour clock starts when the breach is *detected*, not when it occurs. If a group like UTA0533 sits in a SonicWall appliance for weeks, the "timely notification" required by law becomes a historical footnote rather than a useful warning. There is a second-order effect here that the C-suite usually ignores. When a platform like ServiceNow or a hardware vendor like SonicWall is compromised, the exposure cascades downstream. It isn't just the vendor's problem; it's the problem of every client who trusted that "secure" gateway. This creates a nightmare for cyber insurers. If a breach is caused by a zero-day in a third-party appliance, who is liable for the downstream loss? The vendor who wrote the buggy code, or the client who failed to identify an invisible flaw? The common defence is that "patching cycles are faster than ever." Microsoft's July update, for instance, fixed 570 security vulnerabilities. The sheer velocity of patching is often cited as proof of resilience. This is a fallacy. Patching is a reactive cure for an architectural disease. We are building increasingly complex stacks of interdependent software, and then acting surprised when a single flaw in a gateway appliance grants an attacker the keys to the kingdom. The objection, of course, is that we cannot simply stop using these tools; the modern enterprise cannot function without centralised management and remote access. That is true. But we are pricing in the risk incorrectly. We pay for the licence and the support contract, but we don't price in the cost of the inevitable failure. We treat security as a product you buy, rather than a state of constant, managed degradation. In Oslo, regulators are beginning to look more closely at the actual resilience of critical infrastructure providers, rather than just checking if they have a written policy on the shelf. It is a shift from "did you follow the process" to "does the system actually work under pressure." The real question is whether the fines are high enough to force a change in how these platforms are built. Currently, a settlement—like the one recently reached by 23andMe over genetic data breaches—often feels like a cost of doing business. It is a line item in a budget, not a catalyst for engineering change. If we continue to rely on a handful of monolithic platforms to manage the entire global economy, we are essentially creating a single point of failure for the planet. We've seen this before with the CrowdStrike outage, though that was a mistake of stability, not security. A security failure is simply a mistake that someone is actively profiting from. I'll be watching to see if the ServiceNow exploit leads to a wider wave of corporate espionage. If the attackers have spent time in the ticketing systems, they know exactly who is talking to whom and what the internal priorities are. That's far more valuable than a list of passwords.