The SharePoint deserialization flaw

# The SharePoint deserialization flaw Sit down. Let's look at the SharePoint mess before the afternoon reports start lying to us. We're talking about CVE-2026-58644. If you're looking at the CISA KEV list, you'll see it landed on July 16. The federal patch deadline was July 19. It's now the 21st. That means there is a window of about 48 hours where every federal agency and half the Fortune 500 are currently sitting ducks if they haven't hit the update button. In plain terms, this is a deserialization vulnerability. I know the textbooks make it sound complex, but here is how it actually works: a server takes a stream of data—an object—and turns it back into a usable piece of software. The flaw is that SharePoint is trusting the data too much. It's like someone handing you a package that says "Cake" on the label, and instead of checking the contents, you just open it and the package tells you to hand over your house keys and open the front door. The attacker doesn't need to be a genius. They just need to send a specially crafted object that the server "deserializes" into a command. Once that happens, you've got Remote Code Execution (RCE). Who runs this? Everyone who thinks they need a "collaborative environment" but actually just wants a place to dump PDFs and spreadsheets they'll never read again. We're talking about the massive corporate behemoths and government departments that have SharePoint farms so large they have dedicated teams just to keep the lights on. When this goes sideways, the blast radius isn't just one server. SharePoint is rarely an island. It's usually tied deep into the Active Directory, connected to SQL back-ends, and integrated with every other internal service the company owns. If I'm the attacker and I land on your SharePoint server via CVE-2026-58644, I'm not staying there. I'm using that footprint to scrape credentials from memory and move laterally. I've seen this movie before. Back in 2017, NotPetya didn't start as a global catastrophe; it started as a compromise of a single software update mechanism. The parallel here is the trust. Once the perimeter is breached through a trusted application, the internal network is essentially a playground. The difference now is that we have better tooling, but the human element—the delay in patching—remains exactly the same. You'll see a press release soon from some breached company calling the attack "sophisticated." I hate that word. There is nothing sophisticated about using a public PoC to exploit a known flaw three days after a federal deadline. It's not a ghost in the machine; it's just a criminal using a door you left unlocked. Now, your first instinct is to tell me the patch is already out. You'll say, "Ray, Microsoft released the fix, why is this still a problem?" Because patching SharePoint is a nightmare. You aren't just updating a browser extension. You're dealing with farms, load balancers, and dependencies that break if you look at them wrong. A lot of sysadmins are terrified to patch SharePoint on a Thursday because they don't want to spend their Friday explaining to the VP of Operations why the entire company can't access their project folders. The objection you'll hear from the CISO is that they have a WAF (Web Application Firewall) in front of the server. They'll tell you the WAF is filtering the malicious traffic. That's a fantasy. WAFs are speed bumps, not walls. A determined attacker will wrap their payload in enough encoding or use a slightly modified vector to slide right past the signatures. If the vulnerability exists in the application code, the WAF is just a spectator watching the breach happen in real-time. Let's talk about the second-order effects, because that's where the real cost is. It isn't just the company running the server. Look at the Managed Service Providers (MSPs) who handle the infrastructure for a hundred different mid-sized law firms or medical clinics. If the MSP missed the July 19 deadline, they've effectively created a master key for every one of their clients. One compromised MSP admin account, combined with this flaw, and you've got a supply chain collapse. Then you have the insurance carriers. I guarantee you there's a clause in those policies about "reasonable security measures." Missing a CISA-mandated federal patch deadline by 48 hours is a great way for an insurer to decide they aren't paying for the recovery. We saw the scale of these costs recently with the 23andMe settlement, where 42 states squeezed them for $18 million. While that was a different kind of breach, the lesson is the same: negligence has a specific price tag. What would this cost you on a Tuesday? If you're the junior analyst and you find a web shell on the SharePoint server at 2:00 AM on Tuesday, it costs you your sleep, your sanity, and probably your entire weekend. For the company, it costs the total loss of confidentiality for every document in that repository. If that's a government agency, it's a national security incident. If it's a law firm, it's a malpractice suit that lasts a decade. We're seeing a trend here. It's not just SharePoint. We had CVE-2026-56164 hitting the same product this week, and the WordPress crowd is dealing with CVE-2026-63030. The common thread isn't the software; it's the lag. The time between "here is the fix" and "we have actually deployed the fix" is the only window the attackers need. Stop worrying about who the attackers are. I don't care if it's a state-sponsored group or a teenager in a basement. Attribution is for the people who write the reports after the data is already on a leak site. Your job is containment. If you haven't verified the patch version on every single node in the farm, you aren't "monitoring the situation." You're waiting to be paged. The question you should be asking isn't "Are we patched?" but "If we were hit right now, how long would it take us to realize the attackers are moving from SharePoint into the domain controller?" Because they probably already are.