Your Ticket to Root Access

# Your Ticket to Root Access The news from ServiceNow this morning is the kind of thing that makes a sysadmin want to go live in a cabin without electricity. We're looking at a critical remote code execution flaw being exploited in the wild. For those who don't spend their weekends reading CVE logs, here is the core of the problem. ServiceNow is essentially the nervous system for a lot of large enterprises. It handles everything from HR requests to IT tickets and asset management. When a flaw allows "remote code execution" (RCE) on a platform like this, it isn't just a bug. It's an invitation. To understand the technical side, we have to talk about deserialization. Think of a serialized object as a piece of furniture that has been taken apart and packed into a flat-box for shipping. Deserialization is the process of taking those parts and putting them back together based on the instructions in the box. The flaw occurs when the system trusts the instructions too much. An attacker sends a "box" that doesn't contain a chair, but instead contains a set of instructions that tells the server to open a command shell and hand over control. The server, trying to be helpful, follows the instructions. Suddenly, the attacker isn't just a user submitting a ticket. They are the system. The second-order effect here is the real nightmare. If an attacker gains root access to your ServiceNow instance, they don't just get your employee directory. They get your vulnerability backlog. They see exactly which servers you haven't patched, which legacy systems you're terrified to touch, and who the admins are. They aren't just inside the house; they have the blueprints and the list of every broken lock in the building. This is where we see the difference between a cryptographic failure and a management failure. People will call this a "security breach," but it's a trust failure. We've spent a decade building massive, complex platforms that have more permissions than any single human should ever possess, then we act surprised when a single entry point grants total dominion. Claude Shannon, the father of information theory, understood that noise is the enemy of the signal. In this case, the "noise" is the bloated complexity of modern enterprise software, which has become so loud that we can no longer hear the signal of a basic logic error until the root shell is already open. The industry likes to pretend that we're moving toward a "Zero Trust" architecture. But you can't have Zero Trust when you have a single, monolithic platform that holds the keys to every other piece of infrastructure in your company. *** **MAILBAG** **Gary, Des Moines: "I keep hearing about these WordPress and ServiceNow things. I paid for a 'military-grade' encrypted VPN for my small business. Does that protect my data from these kinds of attacks?"** Gary, I'll be gentle here. Please stop buying anything described as "military-grade." That phrase is marketing shorthand for "we want to charge you a premium for standard AES-256 encryption." The military actually uses a dizzying array of proprietary and open standards, and they certainly don't use a single VPN to solve every problem. To answer your question: no. A VPN is a tunnel. It protects the data as it moves from point A to point B. It does absolutely nothing if point B—your server—has a hole in the wall. If your WordPress site has an RCE flaw like CVE-2026-63030, an attacker doesn't need to break your VPN encryption. They just send a malicious request to your web server, and the server executes it. You've built a very secure, encrypted tunnel that leads directly to a door that's been left wide open. **Sarah, Berlin: "My company uses the SonicWall SMA 1000 series. We saw the news about the zero-days and the UTA0533 group. We patched immediately, but since they had root access before the patch, should we assume the appliance is permanently compromised?"** You should. This is the part that vendors hate to mention in the patch notes. If an attacker gains root access to a VPN appliance, they aren't just stealing data; they're installing persistence. They can modify the firmware, drop a web shell in a hidden directory, or create a new administrative user that doesn't show up in the standard UI. A patch fixes the hole so new people can't get in, but it doesn't kick out the people who are already sitting in the living room. If you were exposed during the window when those zero-days were active, the only way to be sure is a full factory reset and a firmware re-flash from a known-good image. Anything less is just hoping the attacker was lazy. **Marcus, Toronto: "I saw that 23andMe is settling with the states for $18 million after that genetic data breach. As someone who used their service, does a settlement like this mean the data is somehow 'recovered' or deleted?"** Marcus, unfortunately, no. Once data is exfiltrated, it's gone. You cannot "un-leak" genetic information. The $18 million is a penalty for failing to protect the data, not a magic wand that retrieves it. What we're seeing with 23andMe is a classic key-management failure. These breaches rarely happen because someone "broke" the encryption. It's almost always because a credential was leaked or a database was left exposed via an API without proper authentication. The encryption was likely fine; the people holding the keys just left them under the doormat. Your genetic data is now part of the permanent record of the internet. *** The scale of this week's chaos is staggering. We've seen 544 reported data breaches and 103 exploits in the wild. It's a volume of noise that makes it almost impossible to prioritize. For example, Carnival Corporation just leaked the passport details of 6 million travelers. That's a massive amount of PII, but for a sysadmin, it's a distraction from the RCEs that actually let attackers into the network. The real question is whether we'll ever move away from this "patch-and-pray" cycle. We're treating the symptoms rather than the disease. The disease is the tendency to deploy massive, privileged systems with zero compartmentalization. If you want to fix this, the cost isn't in the software. The patch for ServiceNow is free. The patch for SonicWall is free. The actual cost is the hundreds of man-hours required to audit your current permissions and move your most sensitive blueprints out of the same tool you use to reset employee passwords. It's an expensive, boring, and politically difficult project. That's why most people won't do it.