Did anyone else experience the recent PhishRIP incident in which a targeted email-removal query unexpectedly affected an entire organization? I submitted a query at 1:08 p.m. EST to find phishing messages from a specific domain and subject. The interface showed the correct criteria, but the request processed as though it had no effective filters and began moving emails from all 4,900 employee mailboxes into a hidden quarantine folder.
The job ran for more than 11 hours and affected close to a million messages. There was no customer-facing way to cancel the query or perform a bulk restoration. Support had to involve another internal team, and restoration was limited to batches of 200 messages, with many emails still requiring manual recovery.
The vendor confirmed that other customers were affected and opened an incident, but I have not received a useful explanation or root-cause analysis. Queries run roughly ten minutes before and six minutes after the affected request worked normally, so this may have been limited to a short processing window. The vendor has since said the issue was resolved, but communication and support have been extremely slow.
Has anyone else experienced this, received a detailed explanation, or learned how the query is actually sent to Exchange? More broadly, I am trying to understand how a tool with permission to modify mailboxes could lack hard result limits, cancellation controls, anomaly confirmations, or a practical bulk rollback process.
6 Answers
We did not notice the issue because we rarely depend on PhishRIP. Our mail is already being filtered by several other security layers, including the mail gateway and Microsoft’s built-in protections. We also collect vendor status feeds in an internal alert channel, which made it easier to correlate the timing with the published incident about unexpected PhishRIP quarantines.
That is an awful cleanup scenario. Training users to recognize suspicious messages is valuable, but it cannot replace operational safeguards for an administrative tool that can alter thousands of mailboxes. The platform needs both human awareness and technical controls that prevent one malformed request from becoming an organization-wide action.
The root cause matters, but the lack of safety controls is the bigger issue. A request that expands from matching a few phishing messages to touching every mailbox should trigger several protections: a maximum result count, an automatic timeout, a prominent confirmation for unusually large scopes, a kill switch, and a real bulk-restore capability. A bug or user mistake can happen, but it should not be able to run for hours with no practical way to stop or undo it.
I had something similar happen that week: the domain criteria was ignored and the tool started processing messages across the organization. We are much smaller, so restoring everything only took a couple of hours, but it is reassuring to know this was not just a mistake in my query.
After an incident like this, it is reasonable to evaluate alternatives with stronger search, quarantine, and recovery controls. Some dedicated email-security platforms offer more capable investigation workflows, although replacing a bundled product can be difficult if the existing contract also covers training and phishing simulations. Regardless of the product choice, I would treat independent validation, scope limits, cancellation, and restoration as requirements rather than optional features.
This looks like a fail-open incident. A blank or malformed search should be rejected before execution, and a job with organization-wide scope should require confirmation or hit a hard limit. I would request the exact submitted payload, processing and audit logs, the incident timeline, and a written root-cause analysis. The fact that several customers were affected during the same period suggests a problem in the vendor’s query-generation or processing layer rather than Exchange independently dropping every parameter.
That was my initial concern too, but the query was not blank or incorrectly entered. The saved query still displays the sending domain and subject exactly as entered, and the interface normally refuses to run without at least one populated field. I am still waiting for the RCA after multiple unanswered calls and messages; support only confirmed that the incident was resolved and then stopped responding.
The vendor later released an RCA that confirmed the guardrails were mostly superficial front-end validation. In this case, a domain search was mishandled when the input did not meet a specific formatting check, and downstream processing treated the field as empty. There was no meaningful validation before execution. Engineering only noticed because an anomaly monitor detected the unusual query activity. Their proposed improvements still seem inadequate, especially without a default quarantine limit that customers can explicitly raise when necessary.