Show Notes
LACMA’s year-long breach disclosure delay and what it says about incident response Jess Hebenstreit and Jake Williams break down a Los Angeles County Museum of Art data security incident that raises big questions about breach timelines, notification delays, and response ownership. They focus on what the disclosure says, what it leaves unsaid, and why the cleanup process may have taken far longer than it should have. In this episode, they examine the gap between initial detection, timeline validation, data review, and eventual notification. They also unpack why the kind of data exposed suggests employee and benefits records, and why that matters for both legal exposure and response logistics. Key topics The breach timeline looks unusually long Jess and Jake note that LACMA says it detected suspicious activity on July 11, 2025, but did not publish the disclosure until August 24, 2026. They question how it took weeks to confirm the intrusion window and then months more to complete the data review.
The delay in scoping the incident raises red flags Jake points out that the investigation later narrowed the third party’s access to July 7 through July 11. They discuss how incident teams can get stuck chasing false leads in logs, but still say this timeline feels slow.
Data review appears to have dragged on The disclosure says the initial data review results arrived in late February 2026. Jess and Jake interpret that as a sign of weak data governance, poor vendor management, or both.
The affected data suggests employee and benefits records The potentially exposed data includes full names, dates of birth, Social Security numbers, government ID numbers, financial account numbers, payment card data, health insurance information, and limited medical details. Jess argues that this pattern looks like employee data, possibly tied to a self-funded health plan.
Notification logistics seem inconsistent Jake questions why the organization spent months trying to obtain “accurate contact information” before notifying impacted people. He notes that breach notification rules generally do not wait for perfect contact data before state reporting obligations begin.
A class action lawsuit seems likely Jess says she expects litigation, and Jake agrees. They also suggest state attorney general investigations are likely.
The response may have suffered from leadership turnover Jess thinks a change in leadership or responsibility may have disrupted the response. Jake agrees that handoffs, missing context, or people being removed mid-incident can create major problems.
They believe outsourcing the data review was the right move, but too late Jake explains why identifying impacted records is harder than it sounds, especially with inconsistent name formats, spellings, and duplicate records. Both agree this kind of work should be handled by a firm that does breach review every day.
Cyber insurance and breach counsel likely shaped the response They debate whether the organization had cyber insurance and how that would have affected the handling of the case. Jake explains that cyber claims usually involve upfront costs and reimbursement later, which can slow response work.
The human cost of a broken incident response Jess closes by saying she feels bad for the responders who had to deal with the mess. Jake advises responders to keep notes, assume they may be deposed later, and remember that the organization will not protect them in enforcement actions.
Timestamps 00:00 - Breach Please intro and the show’s no-nonsense mission 01:33 - LACMA data security incident enters the conversation 01:50 - Why the disclosure timeline is so hard to believe 03:18 - What the timeline says about detection and scoping 06:01 - Late February 2026 data review results 07:57 - Why “accurate contact information” is a weak explanation 08:52 - Why a lawsuit and state investigations seem likely 09:27 - The exposed data and why it looks like employee records 10:54 - A Reddit
More from Breach Please
Jake Williams and Jess Hebenstreit dig into the week's vulnerability pile-up — PHP, GitLab, Node.js, and a LightLLM supply-chain keylogger — and the much bigger story blowing up the week: ChainGuard's CEO unilaterally broke the coordinated disclosure embargo on the PHP vulnerability, posting technical details hours before the agreed release. They cover why that decision may have put the final nail in coordinated disclosure's coffin, Jake's fire department (not bucket brigade) framework for arguing a changed risk landscape to your board, and the pushback on a widely-shared LinkedIn post telling security leaders to 'just ask your board for the basics.' They also get into whether AI model providers bear responsibility for accelerating vulnerability discovery, how to tell your board the risk calculus has actually changed instead of just asking for the same resources again, and why cybersecurity has become a far more cutthroat, specialized field than the one they came up in. Spicy/rant warning: Jess does not hold back on this one. Topics covered: - ChainGuard's CEO breaking the coordinated PHP vulnerability disclosure embargo, and the industry backlash that followed - Why Jake and Jess think this may be the beginning of the end for coordinated disclosure as it's worked until now - The week's vulnerability pile-up: PHP, a new GitLab flaw, Node.js, and a LightLLM supply-chain keylogger compromise - Jake's fire department vs. bucket brigade analogy for explaining a changed risk landscape to your board - The backlash to a viral LinkedIn post telling security leaders to go ask their boards for 'the basics' - Whether AI model providers share responsibility for accelerating vulnerability discovery and exploitation - Why cybersecurity has become a more cutthroat, specialized field than the one Jake and Jess came up in Sources: Jason Clinton (Deputy CISO, Anthropic): https://x.com/JasonDClinton/status/2113325263157395456 ChainGuard CEO: https://lnkd.in/p/gufhMCU7 Marcus Hutchins: https://lnkd.in/p/gwzFmFeE FireEye: https://lnkd.in/p/gZAW7tAA Join our Discord: https://discord.gg/wYJnTpczV
Jake Williams and Jess Hebenstreit break down three vulnerabilities that blew up in the same 24 hours: a brand-new CVSS 10 unauthenticated RCE in self-managed GitLab (not the one from October 12 — a different flaw, patch again), PHP's actively-exploited critical vulnerability and why 'we don't have PHP' is almost never actually true, and the eMudra certificate authority mess, where researchers found ECC keys so weak that one of them was literally the number 4. They also get into when a vulnerability response becomes an incident, why 'we're waiting for evidence of exploitation' usually isn't a defensible position, Jake's three-bucket framework for prioritizing patches (business-as-usual, next outage window, or create-an-outage-now), and why a fast, imperfect postmortem beats a perfect one that never happens. Topics covered: - The new GitLab CVSS 10 unauthenticated RCE affecting every version back to 7.0 (2014) — distinct from the October 12 patch - PHP's critical, actively-exploited vulnerability: where PHP actually hides in your environment (appliances, admin interfaces) even if you think you don't run it - eMudra's catastrophically weak TLS/ECC private keys, the browser and package-manager fallout, and why a clean certificate transparency log doesn't mean you're safe - Who actually has the authority to accept the risk of staying unpatched, and how to make that case in dollars - Running vulnerability response like an incident without calling it an incident - Jake's three-bucket patch prioritization framework and why quick postmortems beat delayed ones
Two critical PHP vulnerabilities (CVE-2026-109618) are getting patches today — a remote code execution bug spanning PHP 5 through current, with early severity estimates as high as a CVSS 10 (PHP's own advisory puts it at 9.2). Guest Richy fills in for Jake this episode and joins Jess to break down what's actually exploitable, why this hits vendor appliances hardest (you can't just drop an EDR on a closed-source box), and the one thing they disagree on: wait for a CISA KEV listing before acting, or patch now if you're internet-facing? (Jess says now.) Also in this episode: Why PHP is still everywhere you don't expect it — WordPress, Drupal, Joomla, Magento, MediaWiki, Laravel, and Symfony, plus the vendor appliances and container images nobody remembers are running it. Richy's "proactive threat response" framework — running a hair-on-fire vulnerability like an incident, without calling it one, so you keep the communication lines and decision speed without the regulatory/insurance baggage. How to actually find PHP in your environment without a reliable CMDB: attack surface management tooling, EDR process queries, and vendor SBOMs. Guest: Richy, filling in for Jake Williams this episode. Sources: PHP's official advisory: https://www.php.net/archive/2026.php#2026-10-21-5 Watchtowr's FAQ (CVE-2026-109618): https://watchtowr.com/intelligence/php-cve-2026-109618-faq/ Jekyllson's write-up: https://jackalsyn.com/posts/php-up-2026.html Join our Discord: https://discord.gg/wYJnTpczV
Hashcat core developer EvilMog joins Jess and Jake to explain why so many "NTLM v1 is disabled" Windows networks are still exploitable. MSCHAPv2 and PPTP VPN are cryptographically equivalent to NTLM v1 — so a rogue RADIUS server and one unchecked "verify the certificate" box can hand an attacker domain admin, no matter how long or random your password is.
ConnectWise disclosed over the weekend that threat actors used existing OAuth credentials to take over Microsoft 365 tenants through its Cloud Management platform — Huntress has confirmed 162 tenants impacted so far, with ConnectWise's own SkyKick backup service shut off entirely as a result. Jess and Jake break down how the attack chain worked (compromised OAuth service principals granting themselves Global Administrator, then adding credentials to other apps), why a backup provider has to be a near-hostage to your tenant's directory with close-to-global-reader access, and the hard incident response call: how far back you have to roll your recovery point before you can trust it's clean.