Is Your Third-Party App a Backdoor?

# Is Your Third-Party App a Backdoor? I’ve spent the afternoon reviewing the wire. There are 401 data breach stories this week, but one is dominating the conversation: the claim that ShinyHunters has exfiltrated 284 million patient records from McKesson. The attackers are demanding $55 million to keep the data quiet. It's a staggering number. But for those of us who track these movements, the most interesting detail isn't the record count; it's that the breach occurred via a third-party application. This is where today’s mailbag begins. **Sarah from Bristol asks: "I saw the news about McKesson on the news. I don't even know who they are, but I'm worried my medical records are on the internet now. How does this happen if I never gave them my information?"** Sarah, it's completely normal to feel uneasy when you see numbers in the hundreds of millions. You likely didn't give your data to McKesson directly because they operate behind the scenes as a pharmaceutical wholesaler and healthcare provider. They are the plumbing of the medical world. If your pharmacy or doctor uses their systems to manage prescriptions or billing, your data lives on their servers. When a company this size is hit, it doesn't mean every single record has been downloaded by a human and read. It means the data is "exposed." However, once it's in the hands of an extortion group, the risk is real. The best thing you can do now is keep an eye on your medical billing statements for any oddities and be skeptical of any unexpected emails or texts claiming to be from your healthcare provider. **Marcus from Chicago asks: "We use a dozen different SaaS vendors for our logistics and HR. If one of them gets hit like the app that let attackers into McKesson, does that mean my entire network is compromised? What actually happens during that 'hop'?"** This is the tradecraft idea for today: the trusted relationship. Attackers rarely kick down the front door of a hardened target if there is a side door left propped open by a vendor. In this scenario, the attacker doesn't necessarily need to find a zero-day in the target's own firewall. Instead, they compromise a smaller, perhaps less secure, third-party application that has been granted legitimate access to the target's environment—often through an API key or a service account with overly broad permissions. Once the attacker controls the vendor's app, they aren't "hacking" into the target in the traditional sense; they are using a valid, trusted identity. They "hop" from the vendor's compromised infrastructure into the target's database. This rhymes with the 2013 Target breach, where attackers used credentials stolen from an HVAC contractor to move laterally into the payment systems. The parallel is the exploitation of trust. Where it differs today is the scale and speed. In 2013, they were moving through a corporate network; in 2026, these hops happen via cloud-to-cloud integrations in milliseconds. If your vendors have "read/write" access to your core databases when they only need "read" access to one specific table, you've built a bridge for any attacker who hits that vendor. **Elena from Madrid asks: "ShinyHunters is asking for $55 million. If we were in their shoes, would it be smarter to just pay the ransom to avoid the public fallout and the fines?"** I'll be blunt: paying a ransom is a bet where the house always wins. You aren't paying for the deletion of your data; you're paying for a promise from a criminal that they won't sell it. There is no mechanism to verify that every copy of those 284 million records has been erased. Furthermore, paying often marks you as a "payer," which increases your attractiveness to other groups. Look at GS Retail in Korea. They were recently fined W12.8 billion won for a breach affecting 1.66 million users. Regulatory fines are painful, and public fallout is embarrassing, but they are finite events. Paying a ransom creates an open-ended liability. My position is that you should never pay unless the alternative is the immediate loss of human life. Regarding attribution, my confidence that ShinyHunters is the primary actor here is moderate. They have a history of both performing breaches and simply buying leaked data from other actors to claim "credit" for the extortion. To move my confidence to high, I would need to see the initial access logs from the third-party application showing the specific TTPs associated with that group's known infrastructure. If the data appears in a format consistent with an API scrape rather than a full database dump, my confidence would drop to low; it would suggest they bought a partial set of data and are overstating their haul. We should also consider the second-order effects here. McKesson isn't just a data repository; they are critical infrastructure for drug distribution. The "service degradation" reported is more worrying than the data theft. If the breach disrupts the supply chain, the victims aren't just the people whose records were stolen—they're the patients at pharmacies who can't get their medication on time. While the world focuses on the 284 million records, I'm watching CVE-2026-66066. It's a critical remote code execution vulnerability in Ruby on Rails that is being actively exploited. While it hasn't hit the headlines with the same noise as the McKesson breach, it's the kind of flaw that allows the "hops" I described to Marcus. If you're running Rails, check your version now. If you're using a third-party vendor who runs Rails and hasn't patched, you're essentially waiting for your own mailbag question.