There are two massive problems and neither of them have anything to do with executing attacker's code. First, for Equifax, their databases should be sufficient

There are two massive problems and neither of them have anything to do with executing attacker's code. First, for Equifax, their databases should be sufficiently isolated from front-end web servers. SQL gives you the ability to, in essence, ask the database any question the data can possibly answer. Instead, Equifax needs to do the work to enumerate all the questions they want the data to answer and put intermediate API services in place that answer only those questions. Public-facing web servers should only be allowed contact the intermediate API servers, and not the database. With data that has the value (to an attacker) that Equifax's database does, this is the minimum that needs to be done to offer reasonable security. Second, there's an identity problem. That identities can be stolen using largely facts about people (name, address and such and, yes, SSN) is a fundamental problem in how we identify people. They're using non-secrets in a way that assumes they are secret. A Keybase identity is much closer to the model that the industry needs to adopt. Chalking up the cause of this to flaws in some ancient Java web framework that's barely used anymore is just sweeping the true problems under the rug. The industry needs a fundamental overhaul to how they identify people and mandatory security compliance (hey...they foisted PCI-DSS on etailers and card processors, so they can't complain when something similar is foisted back on them) to keep our information safe.