Also, didn't the Equifax breach happen in May, 2017? If so, I fail to see how the Sept, 2017 exploit plays into this unless it was in the wild months before it was published in Sept, 2017 - which I find hard to believe.

I completely disagree. It is open-source for a reason. If you find a bug in it, fix it and everybody wins. Otherwise, nobody would ever publish any code/software because you would get sued if you did any mistake. On top of that, the software is free. So you basically want to blame some group which gave you something for free which you used to make big money and expect to also sue them for consequences if they made a mistake.

I also feel bad for the engineering team at Equifax. But on the other hand, you have to take into account that any software you employ could have a security flaw in it. That is why you should have additional means to protect it and no single point of failure. And this is especially true if your whole business depends on that data!

edit: spell check

I would have expected this type of data to be stored in such a way that even if someone got access to one of their web/application servers they wouldn't be able to dump 143 million records from it without serious red flags going off.

'Encryption at rest' only works for data that is not actively used, like backups or if a physical storage device is stolen.

A better additional safeguard is to have quotas and alarms in place for data access. Is data being accessed sequentially in a application environment where data is usually accessed randomly? Is data access bound to individual credentials and do indivudals access more data than usual?

I think, there is actually potential for new database products or addons, which can reduce the impact of breaches in the vicinity of these 'core databases'.

    ObjectInputStream ois = new ObjectInputStream(input);
    MyObject obj = (MyObject)ois.readObject();