🔥 The DB Grill 🔥

Where database blog posts get flame-broiled to perfection

Elastic response to blog ‘EDR 0-Day Vulnerability’
Originally from elastic.co/blog/feed
August 18, 2025 • Roasted by Rick "The Relic" Thompson Read Original Article

Alright, settle down, kids. Let me put down my coffee mug—the one that says "I survived the Y2K bug and all I got was this lousy t-shirt"—and take a look at this... this masterpiece of corporate communication. I've got to hand it to you Elastic folks, this is a real doozy.

It's just so inspiring to see you all tackle this "EDR 0-Day Vulnerability" with such gravity and seriousness. An arbitrary file deletion bug! Gosh. We used to call that "a Tuesday." Back when we wrote our utilities in COBOL, if you put a period in the wrong place in the DATA DIVISION, you didn't just delete a file, you'd accidentally degauss a tape reel holding the entire company's quarterly earnings. There was no blog post, just a cold sweat and a long night in the data center with the night shift operator, praying the backup tapes weren't corrupted. You kids and your "bug bounties." We had a "job bounty"—you fix the bug you created or your job was the bounty.

And I love the confidence here. The way you talk about this being "chainable" is just precious.

The researcher chained this vulnerability with another issue... to achieve arbitrary file deletion with elevated privileges.

You mean one problem led to another problem? Groundbreaking. It's like you've discovered fire. We called that a "cascade failure." I once saw a single failed disk controller on a System/370 cause a power fluctuation that fried the I/O channel, which in turn corrupted the master boot record on the entire DASD farm. The fix wasn't an "expeditious" patch, it was three straight days of restoring from 9-track tapes, with the CIO standing over my shoulder asking "is it fixed yet?" every fifteen minutes. You learn a thing or two about "layered defense" when the only thing between you and bankruptcy is a reel of magnetic tape and a prayer.

But my favorite part is the earnest discussion of "security-in-depth." It's a fantastic concept. Really, top-notch. It reminds me of this revolutionary idea we implemented for DB2 back in '85. We called it "resource access control." The idea was that users... and stay with me here, this is complex... shouldn't be able to delete files they don't own. I know, I know, it's a wild theory, but we managed to make it work. It's heart-warming to see these core principles being rediscovered, like they're some ancient secret unearthed from a forgotten tomb.

Honestly, this whole response is a testament to the modern way of doing things. You found a problem, you talked about it with lots of important-sounding words, and you shipped a fix. It's all very professional. Back in my day, we'd find a bug in the system source—printed on green bar paper, mind you—and the fix was a junior programmer with a red pen and a box of punch cards. There was no "CVE score." The only score that mattered was whether the nightly batch job ran to completion or crashed the mainframe at 3 AM.

So, good on you, Elastic. You keep fighting the good fight. Keep writing these thoughtful, detailed explanations for things we used to fix with a stern memo and a system-wide password reset. It's cute that you're trying so hard.

Now if you'll excuse me, I think I have a COBOL program from 1988 that needs a new PIC 9(7) COMP-3 field. Some things just work.