🚨 An AI security tool just found a remote-code-execution bug that had been hiding in pgcrypto for over twenty years.
Let me tell you why that headline made me put my coffee down. pgcrypto is the extension teams reach for when they want to "encrypt a few columns" in Postgres without buying anything. CVE-2026-2005, a heap overflow rated CVSS 8.8, has lived in it since 2005. The reported kicker: around 80% of cloud Postgres environments are still vulnerable, and nearly half sit directly exposed to the internet.
Years ago I walked into a client who'd done exactly this: sensitive fields "encrypted" with pgcrypto, the box reachable from the open web, patch level untouched since launch. They thought encryption was the finish line. It was just the part they could see.
🛡️ Encryption buys you nothing if the engine doing it is unpatched and exposed. The quiet dependencies are the ones that bite.
When did you last audit the extensions actually running in your production database? 🔍
🔐 When attackers breached a Polish invoicing platform used by 600,000+ businesses, they reached the keys to everything those businesses had connected, along with the invoices.
Fakturownia disclosed this month that an intruder reached its servers and made off with password hashes, bank account details, and integration and authentication tokens, the part most teams underestimate. Here's what most people get wrong 👇
Your production database quietly becomes your secrets vault. API keys for payment processors, OAuth tokens for accounting integrations, webhook secrets, they pile up in columns next to customer data because it was convenient. So when the database falls, every connected system falls with it. One breach becomes ten. 💥
🛡️ Keep secrets out of the table that holds the data they protect. Move them into a dedicated secrets manager, encrypt them with keys the database can't reach, and rotate on a schedule, so a stolen dump stays a contained cleanup.
What's living in your database right now that should be in a vault instead? 👇
🚨 "An eight-hour outage." That's how one of 2026's biggest healthcare breaches was first described.
CareCloud, a healthtech platform, initially framed its March incident as a brief disruption. Five months later the real number landed: 3,756,469 patients, with Social Security numbers, government IDs, insurance and medical records, and some payment cards exposed. Attackers were inside the AWS environment for days, far longer than eight hours. 💥
My hot take after years of incident bridges: the first breach disclosure is almost always the floor of the damage. "Limited," "brief," "no evidence of data access" are what you say before forensics finish. They are placeholders, and the final count tends to be bigger. A few days of dwell time is plenty to exfiltrate millions of rows.
🛡️ Without proof of what left your database, assume everything did. Encryption at rest and tamper-proof access logs are what turn "we think it was limited" into something you can actually stand behind.
How confident are you that your first breach number would be your last? 👇
🚨 Years ago I got pulled into a 2 a.m. call: a client's primary database encrypted, a ransom note where the schema used to be. Clean backups saved them. Barely.
I thought about that call this week when Europol dismantled KillSec, the ransomware crew linked to around 1,000 attacks worldwide. Leak site seized, ~110 TB of stolen data recovered, and the alleged administrator turned out to be 16 years old. 🛡️
One teenager, a rented toolkit, a thousand victims. The barrier to hitting your database has never been lower, and "we're too small to be a target" has never been more wrong.
Encryption at rest didn't stop these crews. They stole the data and extorted on the copy. What held the line for my clients: tokenized fields, rotated keys, and immutable, tested backups.
What would your worst day look like if your main database locked tonight? 👇
🔐 "We require authentication, so we're covered." Here's what most teams get wrong about that sentence.
MongoDB's CVE-2026-82067 (CVSS 8.1, versions 7.0 / 8.0 / 8.3) is the nightmare version of it. A case-sensitivity bug in config validation can leave the authorization subsystem disabled when the server starts, silently. The database comes up, serves traffic, looks healthy. And anyone with network access can run admin operations with zero credentials. 💥
The lesson after years of hardening clusters: "auth is enabled" is a runtime state you have to verify. A flag in a config file proves nothing about whether the subsystem honored it.
Patch to 7.0.41 / 8.0.30 / 8.3.9. Then make your deploy fail if the server ever starts with authorization off. 🛡️
When did you last confirm that auth is actually on in prod? 👇
🔓 Let's stop pretending the perimeter is the problem.
Denmark just confirmed its largest breach ever: roughly 8 million people's records pulled from the Central Person Register. No zero-day. No firewall meltdown. Attackers used a private company's authorized access to the national database and walked out with names, addresses, and CPR (SSN-equivalent) numbers.
I've sat in enough incident bridges to tell you: the scariest breaches come from attackers who simply log in. 🛡️
If a trusted third party can query your production data today, assume that account is your real attack surface. Least privilege, per-record access logging, and tokenizing identifiers so a dumped table is worthless. That's the work. Encryption at rest won't save you from a credential that's allowed to read.
Who actually reviews which vendors can touch your production database, and when did you last check? 👇
🚨 Years ago I audited a fintech and found a "quick lookup" endpoint built for a partner integration. No rate limiting, barely logged, wired straight to the customer table. It had been live for two years. Nobody remembered building it.
I thought about that reading this week's Shinhan Bank breach. Attackers pounded a simplified inquiry API, the one built for loan brokers, and enumerated roughly 25,000 customers' names, incomes, and loan limits. No zero-day. Just a convenience feature nobody hardened. 💥
Here's the pattern I see constantly: the breach usually comes through a side door you forgot you built: the partner API, the admin tool, the legacy export. 🔐
When did you last inventory every path into your production data? 👇
💡 "We don't use time-series collections, so we're fine." I've heard a version of that about CVE-2026-8053 more than once this year. Here's what most people get wrong. 🧵
The flaw (CVSS 8.8) lets any account with plain readWrite privileges corrupt memory in the MongoDB process and potentially run code as the database itself. The time-series code is just the trigger. The real prerequisite is a single valid readWrite credential. 🔐
And that's the part teams underestimate: readWrite creds are everywhere: in app configs, CI pipelines, .env files, old scripts, log lines. "It requires authentication" stopped being a comfort years ago.
Patch it. Then go hunt for every over-privileged account that can write to your database, because that's your real blast radius. 🛡️
How tightly scoped are your database roles, honestly? 👇
🛡️ Epic just hit pause on its entire product roadmap for six weeks to fix security flaws before shipping anything new.
Here's my hot take: that should be the industry standard. 💥
Most companies would have quietly logged the bug, shipped the next feature, and hoped. Epic stopped the line. The detail that should scare every healthtech and fintech CTO: one flaw could let outsiders read patient records with no trace left in the logs. An intruder who leaves no footprint makes "we saw no evidence of access" meaningless. 🔐
Encryption, least privilege, and tamper-proof audit logs are the product. When did you last choose a fix over a feature? 👇
🧵 A few years back a client asked me to "just store the ID scans, we might need them for disputes." Every driver's license, passport, and selfie their users uploaded, kept forever in the primary database, long after verification was done.
I pushed to purge them after KYC. I got overruled: "storage is cheap." 😬
I thought about that reading about the Times Car breach this week: 6.6 million accounts exposed, including driver's license images, after attackers sat inside the system for roughly a month. The verification was finished years ago. The liability never expired. 🔐
Here's the practitioner's rule: data you don't store can't be breached. If an ID scan only existed to verify identity once, tokenize the result and delete the image. "Storage is cheap" holds until it's 6.6 million licenses in a breach notice. 🛡️
What's the oldest thing in your database that no longer needs to exist? 👇
💡 Here's what most people get wrong about an exposed database: they treat it as a race to close the port before someone finds it. The data says someone already did.
A 2026 study of 30,000+ internet-exposed databases found 46% already carried ransom notes or wipe messages the moment researchers reached them. For open MongoDB instances it was 99.8%. For MySQL, 99.97%. 🚨
Automated bots sweep the entire IPv4 space in hours. There is no quiet window where your misconfigured database sits undiscovered. "I'll lock it down tomorrow" usually means it's already been hit. 🔐
So stop treating exposure as a near-miss. Default-deny every database, never bind to 0.0.0.0, and encrypt at rest so that even a found database is just noise. 🛡️
What's the actual gap between "we exposed it" and "we'd notice"? 👇
🔐 Unpopular opinion: "data discovery" tools have been selling you a longer to-do list and calling it security.
Thales launched CipherTrust DSPM this week, and the most honest part of the announcement was the admission underneath it: the hard part of data security is acting on what you find. 🛡️
I've run encryption rollouts across dozens of fintech and healthtech shops, and every one already had a dashboard glowing red with "exposed data." Encryption, masking, and tokenization at the source are what stop breaches. 💡
A scan that ends in a report is theater. A scan that ends in ciphertext is control.
Where does your program actually stop, at the alert, or at the fix? 👇
🧵 A few years back, a healthtech client asked me to map where their patient data actually lived.
It took three weeks. We found PHI in a billing vendor's data center that nobody on the security team could name. 😬
That exercise came back to me reading about the health-tech vendor breach that exposed 3.8 million patients' Social Security numbers, diagnoses, and scanned IDs. Attackers quietly copied data for roughly nine days, and patients weren't notified for months.
Here's the part that should keep founders up at night: most of those people had never heard of the vendor. Their data was there because a provider they trusted handed it off, and then that provider's vendor got breached. 🔐
Your breach surface is everyone you've ever sent data to.
When did you last map every third party holding your customers' data? 👇
🔐 Here's what most people get wrong about patching: they treat the CVSS number as the risk assessment itself.
Case in point: the Redis flaw CVE-2026-81934, a use-after-free in TLS handling that can lead to remote code execution. NVD scored it 9.8, critical. Redis scored the same bug 7.5. Same vulnerability, two very different numbers. 💥
Both numbers are defensible, because CVSS base scores measure the flaw in a vacuum. Your actual risk lives in the context the score can't see: is that Redis instance reachable from the internet or pinned to a private subnet? Who holds authenticated access? Is it caching session tokens and PII, or throwaway data?
A 9.8 on an isolated, locked-down node can matter less than a "medium" on something exposed. The score tells you to look. Context tells you how fast to move. 🛡️
Patch it, then triage by blast radius. How does your team prioritize CVEs? 👇
🚨 The Revolut breach started with a call to its vendor.
Revolut just had its second breach in a month, this one through DriveWealth, the brokerage partner that handled some customers' trading accounts. No zero-day, no SQL injection. Attackers social-engineered the partner's staff and walked off with names, addresses, employment info, and partial account numbers. 🔓
My take after years of securing financial data: your attack surface includes every human with a login at every company you've ever integrated with. You can encrypt every column you own and still land in a breach notice because someone else's help desk got smooth-talked.
Vendor due diligence has to go past a SOC 2 PDF. Can you answer "what could this partner's compromised employee reach?" That answer is your real exposure. 🛡️
How deep does your vendor risk review actually go? 👇
🔐 Early in my career I flagged a SQL Server CVE in a review and got waved off: "It needs authentication, so it's low risk. Skip it." I've watched that exact sentence age badly more times than I can count.
It came back to me reading about CVE-2026-67629 (patched last month, CVSS 6.5): an out-of-bounds read in SQL Server 2017 through 2025 that lets an authenticated user read chunks of the server's process memory over the network: other sessions' data, fragments of queries, whatever's resident. 💥
Here's the thing: "requires credentials" stopped being a comfort years ago. Credential theft and phishing are the front door now. The moment you assume an attacker can log in as some low-privilege account, every "authenticated-only" bug becomes part of your real attack surface. 🛡️
Patch it, then model your database as if the attacker already has a valid login. Statistically, that's the breach.
Do you threat-model your DB assuming creds are already compromised? 👇
💡 A 16-year-old just made 17.3 trillion Microsoft database rows reachable with a forged token. Here's the auth mistake most teams are quietly shipping. 🧵
The internal analytics service (Titan) checked the claims inside the JWT (tenant, audience, app) but never verified the token's cryptographic signature. So you could hand it an unsigned token claiming to be an admin, and it believed you. Full unauthenticated SQL access to the backend. (Security Magazine, Sep 29.) 🚨
What most people get wrong: validating what a token says only tells you its claims, and proving the token is real takes a signature check. A JWT you don't signature-check is just a URL parameter with extra steps.
Three rules that would've killed this: verify the signature on every request, reject unsigned / `alg:none` tokens outright, and make auth fail closed. 🔐
When did you last test what your API does with a garbage token? 👇
🚨 The "we have backups" era of ransomware defense is over.
Zscaler's new ThreatLabz report (out this week) found the volume of data stolen by ransomware crews jumped 275% year over year, reaching nearly 900 terabytes. Meanwhile, attacks actually fell in healthcare, government, and education. Fewer attacks, far more data walking out the door. 💥
Crews have figured out that encrypting your files is optional. Exfiltration is the real leverage. One healthcare victim in the report paid a $2M ransom even though nothing was ever encrypted.
Here's the uncomfortable part for every fintech and healthtech CTO: backups restore availability. They do nothing for confidentiality. 🔐 If your crown-jewel tables leave the network readable, the breach already happened, whether or not you restore.
Is your data strategy built to survive theft, or just downtime? 👇
🧵 The worst leaks I've investigated were reports working exactly as designed.
A DC health agency just disclosed that ~399,000 Medicaid beneficiaries had their birth dates, race, and ethnicity exposed through two "summary" web reports that quietly carried the underlying row-level data to anyone who looked. It sat open from 2023 until someone finally noticed in 2026. 💥
I've walked into orgs with hardened databases, encrypted volumes, and tight firewalls, and a BI dashboard happily exporting the exact rows those controls were meant to protect. The analytics and reporting layer is where access control goes to die, because nobody threat-models a "read-only report." 🛡️
Who reviews what your dashboards and exports can actually reach, before they ship?
💡 Most teams think their database is "secure by default." It almost never is.
Security firm UpGuard just found roughly 16,000 Supabase databases leaking personal data to the open internet: names, addresses, phone numbers, even auth tokens (TechCrunch, Sep 25). The common thread was default-open tables, missing row-level security, and AI-generated app code shipped straight to prod without anyone checking who could read what. 🚨
Here's what most people get wrong: encryption and access control are separate controls. Encrypting data at rest does nothing if your API will hand any anonymous caller the decrypted rows. "Secure by default" is a design choice you have to make: default-deny, explicit grants, RLS on every table, and a review step before vibe-coded backends ever touch real customer data.
What's the first thing you audit when you inherit a new database? 🔐
🔐 They encrypted the database. The attackers still walked away with plaintext.
A health platform (Medyc, built by Qbusoft) just disclosed a breach via a textbook SQL injection. Poland's data protection authority says it may touch up to 5 million people. Here's the part that should keep every fintech and healthtech CTO up at night: the names and national IDs were encrypted at rest. The clinic still told patients to assume everything was readable in plain text, because the app itself could decrypt on demand, and so could the attacker riding its queries. 🛡️
Encryption-at-rest earns its keep only when your application cannot silently decrypt the whole table. Otherwise it is theater. The question that matters: who holds the keys, and what has to happen before data gets decrypted?
Is your encryption protecting data, or just your audit report? 💬
🔐 A few years back, a fintech client asked me to "just turn on encryption" before an audit. Two days later the real question surfaced, the one nobody wanted to answer: who holds the keys?
Their data was encrypted. But the keys lived in the same cloud account as the database, behind the same credentials. That's encrypting the vault and taping the combination to the door. 🗝️
I thought about that this week reading Thales' launch of UK-hosted cloud HSMs. The entire pitch is key sovereignty: keys generated, stored, and destroyed somewhere your cloud provider (and an attacker loose in your account) can't reach. Their own research found 36% still believe strong key management alone satisfies data sovereignty.
Encryption is the easy 20%. Key custody is the 80% that decides whether a breach is survivable, and post-quantum is coming for those keys next. 🛡️
Where do your encryption keys actually live, and who can reach them?
🧵 A 12-year-old PostgreSQL flaw just dropped (CVE-2026-6471, nicknamed "PostGREShell," CVSS 7.2), and the part most teams miss is the prerequisite.
The exploit needs replication privileges. And here's what most people get wrong: they hand out REPLICATION like it's a harmless read-only convenience for the analytics box or the CDC pipeline. In fact, any role with replication rights is now a path to full server takeover: arbitrary file reads, RCE, persistent backdoors. 💥
After auditing dozens of Postgres fleets, the pattern never changes: over-provisioned roles nobody remembers granting. Yes, patch to 18.6 / 17.11 / 16.15, but then query pg_roles and ask who actually needs rolreplication. Most don't. 🛡️
When did you last audit who holds replication rights in your database? 💡
🚨 Nearly 3 million people just learned their Social Security numbers sat exposed in a Pentagon file-sharing system from October 2025 until this July, and reporting indicates those SSNs weren't encrypted.
Here's my hot take after years of encryption rollouts: "we have a firewall and access controls" describes a perimeter, and perimeters fail. When they do, the only thing between an attacker and 3 million SSNs is whether that data was encrypted at rest, and who held the keys. 🔐
Encryption at rest is the single control that turns a catastrophic breach into a shrug. Encrypt those files with keys the intruder never touches, and this becomes a footnote. 🛡️
Are you encrypting the data that would land you in the headline, or just the data that's easy?
