The IT Nerd

Comparitech reported today that Wayne Memorial Hospital in Jesup, GA over the weekend confirmed it notified 163,440 people of a May 2024 data breach that compromised SSNs, passwords, financial card numbers, medical history, diagnoses, prescriptions, lab results and images, health insurance, state-issued ID numbers, and more. 

We will get back to the why did it take a year to notify these people about the breach part of this in a moment. Right now here’s a comment from Rebecca Moody, Head of Data Research at Comparitech: 

“This is another worrying case where there has been a significant delay in notifying the majority of people involved in a data breach. Despite having initially notified 2,500 people of a breach in August 2024, it’s taken another year to confirm that over 163,000 people may have been impacted. Furthermore, even though Wayne Memorial Hospital added a data breach alert to its website in August 2024, according to Wayback Machine internet archive data, this had been removed by January 2025. So, unless patients were one of the first 2,500 people to receive a data breach notification letter or happened to view the alert on the hospital’s website from August to December 2024, it’s highly likely they were completely unaware of this breach until now.

While Wayne Memorial Hospital hasn’t confirmed whether or not a ransom was paid, the fact that the hospital was posted on Monti’s website suggests it wasn’t (for the data theft, at least). This means patients’ highly sensitive data has been posted on the dark web since the end of June 2024, leaving them exposed to identity theft and fraud.”

Erich Kron, Security Awareness Advocate at KnowBe4: 

“A delay of over a year to notify people who have had their information stolen is unfortunate. Every day the information is in the hands of bad actors puts the victims at risk of not only identity theft, but also of scams and other social engineering tactics.

Information such as procedures, dates and insurance information, all stolen along with other data, allow bad actors to contrive stories that can be used to scam victims again, such as convincing the victim that they have outstanding debts related to the procedure, or similar ruses. Having a lot of detailed information can allow attackers to create detailed stories, and unless the victim is aware that the information is available to bad actors, can easily convince the victims of the validity of the scam.

Organizations that handle sensitive data need to ensure they are making every effort to secure it. Since human error is the top way that ransomware and other malware infect organizations, especially through email phishing, these organizations need to have a well-designed human risk management (HRM) program in place.”

The fact that it took a year before people were notified is unacceptable. This hospital really needs to be held to account for this. But I suspect that given the current political climate, that may not happen. But I am free to be surprised.

 In what is being called the largest supply chain attack in history, attackers have injected malware into NPM packages with over 2.6 billion weekly downloads after compromising a maintainer’s account in a phishing attack.

Yikes!

Ensar Seker, CISO at SOCRadar had this to say:

“This incident represents a watershed moment in software supply chain security. The compromise of NPM packages with over 2.6 billion weekly downloads highlights just how devastating upstream attacks can be when they exploit the foundational trust built into open-source ecosystems. Attackers didn’t need to break into servers or bypass technical defenses; they simply hijacked a legitimate maintainer’s account through a targeted phishing campaign. That alone granted them the keys to a vast software kingdom.

What’s particularly dangerous here is how the attackers used a domain that convincingly mimicked a legitimate one, npmjs.help, to socially engineer the maintainer. This wasn’t a spray-and-pray phishing attempt. It was calculated, timed, and executed with a deep understanding of developer psychology. The fear-based tactic of threatening to lock accounts by a specific deadline added urgency, increasing the chance of a successful compromise.

Once inside, the attackers tampered with highly popular libraries like chalk and debug, which are ubiquitous in front-end and back-end stacks across the world. These libraries are not surface-level tools; they sit deep in dependency trees, often pulled into projects silently via transitive dependencies. That’s what makes this breach so insidious. Developers and CI/CD pipelines rarely question dependencies that come pre-vetted from trusted registries. Malicious code embedded in these packages can bypass traditional static security checks and propagate downstream at incredible scale.

The software industry is facing a reality where dependency hygiene is no longer optional. When a single compromised maintainer account can poison a global software supply chain, organizations must rethink what software trust means. This starts with strong identity protection for maintainers, including mandatory hardware-based two-factor authentication, anomaly detection, and continuous monitoring of commit behaviors.

Organizations must also start treating their dependency trees as living assets that require governance, not just during development but throughout the entire software lifecycle. A software bill of materials (SBOM) is now essential. It’s no longer enough to know what code you wrote, you need to know what you inherited. Continuous validation of the packages that flow into build pipelines, coupled with deterministic dependency resolution and runtime behavior monitoring, is critical for defense.

This event also underscores a broader issue. We often assume open-source software is secure because it’s open, but that openness means nothing if identity controls are weak, if changes go unreviewed, and if package provenance isn’t verified. Security must now follow the code from origin to runtime, not just within corporate networks, but across global ecosystems.

I believe we will see more targeted phishing attacks against popular open-source maintainers in the future. This won’t be the last time. The question is how fast our tooling, our governance, and our development practices can adapt to match the evolving threat landscape.”

Roger Grimes, Data-Driven Defense Evangelist at KnowBe4:

“Is this the thousandth time NPM packages have been compromised this decade? What’s the over/under on that number? Can’t be that much. The idea that maintainers are still not using phishing-resistant MFA to protect their maintainer accounts is so, so not understandable. Cybercriminals want to compromise NPMs and do so all the time. And yet, maintainer after maintainer don’t get and use phishing-resistant MFA! It’s like almost asking to be hacked. I’m going to put most of the blame on the majority of the cybersecurity industry that tells people they must use MFA and doesn’t tell them that 85% to 95% of the MFA being used is as phishable as the extremely hackable login name and password they replaced with their weak MFA. And to every cybersecurity expert and guide that says, “You should be using MFA” and not “You must be using phishing-resistant MFA (like FIDO, Yubikeys, passkeys, etc.)” you’re doing a HUGE disservice to your congregation. You are contributing to the problem. Both need to change their ways.”

This illustrates the fact that the way software is built needs to be changed. Developers need to assume that anything that they use from the open source world or anywhere else is suspect until proven otherwise. And they need to keep track of what they use so that if the worst happens, there’s a paper trail of sorts.