Salesforce says faulty script deployment gave users access to all of their company's Salesforce data, forcing it to shut down much of its infrastructure Friday
Faulty production script gave users access to all their company's Salesforce data. — Salesforce is going through …
Context & Ripple Effects
This is the second major self-inflicted availability crisis in Salesforce's recent history: three years earlier, a database failure in its NA14 instance left large parts of the US without service for over 12 hours (the 2016 NA14 outage). Friday's incident is different in kind — a faulty production script broke permission boundaries so users could reach all of their own company's Salesforce data, forcing the vendor to take down much of its infrastructure to contain it.
First-order effects
- Salesforce customers spent Friday unable to work in the platform while much of its infrastructure was shut down, and every affected tenant must now assume internal permission walls were porous during the exposure window.
Second-order effects
- Enterprise buyers will press Salesforce on change-management and release controls rather than just uptime SLAs, since two outages in three years — one infrastructure, one access-control — point to process risk, not bad luck.
Third-order effects
- The deeper pattern the later record confirms: because Salesforce concentrates customer data across hundreds of thousands of tenants, any lapse makes it a high-value target — a trajectory that runs through Cloudflare's Salesloft Drift exposure, the Com-affiliated intrusions Google reported, the Lapsus$ leak-site threat against ~1B records, and the Gainsight supply-chain breach hitting 200+ companies.
The trend: SaaS platforms that centralize enterprise customer data are becoming recurring single points of failure, with incidents shifting from self-inflicted outages toward targeted third-party data theft.