Secure Hardware. Insecure Shipping.

# Secure Hardware. Insecure Shipping. We love to talk about the "hardened" part of the stack. We spend weeks arguing over whether a hardware security module (HSM) uses the right random number generator or if a seed phrase is stored in a truly isolated enclave. But most data doesn't leak through the front door; it leaks through the side window of a third-party vendor who forgot to update their business intelligence tool. The current disaster involves CVE-2026-72898, a SQL injection vulnerability in Metabase. For those who aren't spending their weekends reading CISA’s Known Exploited Vulnerabilities list, Metabase is a popular open-source BI tool that lets companies turn their databases into pretty dashboards. It's the kind of software a data analyst installs so they don't have to write raw SQL every time the CEO wants a chart on quarterly growth. The flaw is textbook. An attacker can craft a query that tricks the application into executing unintended commands against the underlying database. In plain terms: instead of asking the database for "all sales in July," the attacker asks for "all sales in July AND every single row in the users table, including hashed passwords and emails." If you're running Metabase, the fix was a simple version bump. CISA set a federal patch deadline of August 14. If you missed that date, you aren't just trailing behind on maintenance; you're effectively leaving your database keys in the lock. The real story here isn't the bug itself—it's the ripple effect. Trezor makes some of the most secure hardware wallets on the planet. Their devices are designed to keep private keys offline and unreachable. Yet, just under 14,000 Trezor customers had their data exposed. Why? Because Trezor uses a logistics partner called ShipMonk. ShipMonk, in turn, was running an unpatched instance of Metabase. This is the second-order effect that keeps me up. You can spend millions on "military-grade" encryption for your internal vaults—a term I despise because it usually just means "we bought a product from a company that has a government contract"—but your security is only as strong as the least competent person in your supply chain's BI department. Claude Shannon once noted that the enemy knows the system. In this case, the "system" includes every single SaaS provider you've granted an API key to and every logistics firm that holds your customer shipping addresses. I see a lot of people calling this a "cryptographic failure" because sensitive data was leaked. It isn't. This is a fundamental input-validation failure. There is no amount of AES-256 in the world that saves you if the application layer is happily handing over decrypted records to anyone who knows how to use a single quote and a semicolon. We have to stop pretending that "encryption at rest" is a shield against SQL injection. If the app has the key to decrypt the data for the legitimate user, the attacker just becomes the "legitimate user" by tricking the query logic. Some might argue that Trezor can't be responsible for ShipMonk's patching schedule. From a legal perspective, maybe. From a systemic perspective? No. If your business model relies on third parties handling PII, those third parties are effectively part of your attack surface. The objection is usually that auditing every vendor's software versions is impossible. I agree it's tedious, but the alternative is exactly what happened here: you build a fortress and then hire a shipping company that leaves the back door wide open. We're seeing this pattern everywhere this month. Look at SafePal, where just under 40,000 customers were hit by a breach, or the SAP Commerce Cloud flaw (CVE-2026-58231) which boasted a CVSS 10.0 and offered an unauthenticated path to remote code execution. The common thread isn't a failure of math; it's a failure of hygiene. The question we should be asking is why we still treat "Vendor Risk Management" as a checkbox exercise performed once a year by a compliance officer with a spreadsheet. If your vendor is running an exposed Metabase instance, your HSM doesn't matter. The fix for the software is free—it's a patch. The actual cost of deployment is higher: it's the man-hours required to actually audit who has access to your data and whether they are updating their dependencies. For most mid-sized firms, that's a few weeks of dedicated engineering time and a very uncomfortable conversation with their logistics provider.