2011 security incident
On Tuesday, May 3, 2011, LastPass discovered an anomaly in their incoming network traffic, and then another similar anomaly in their outgoing traffic. Administrators found none of the hallmarks of a classic security breach (for example, database logs showed no evidence of a non-administrator user being elevated to administrator privileges), but neither could they determine the root cause of the anomalies. Furthermore, given the size of the anomalies, it is theoretically possible that data such as email addresses, the server salt, and the salted password hashes were copied from the LastPass database. To address the situation, LastPass decommissioned the "breached" servers so they could be rebuilt and, on May 4, 2011, they requested that all users change their master password. However, the resulting user traffic overwhelmed the login servers and, temporarily, administrators were asking users to refrain from changing their passwords until further notice, having judged that the possibility of the passwords themselves being compromised was trivially small. LastPass also stated that while there was no direct evidence any customer information was directly compromised, they preferred to err on the side of caution.[22][23]
2015 security breach
On Monday, June 15, 2015, LastPass posted a blog post indicating that the LastPass team discovered and blocked suspicious activity on their network on the previous Friday. Their investigation revealed that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised. LastPass encrypted user vault data were not taken in this incident. The blogpost was quoted as saying, "We are confident that our encryption measures are sufficient to protect the vast majority of users. LastPass strengthens the authentication hash with a random salt and 100,000 rounds of server-side PBKDF2-SHA256, in addition to the rounds performed client-side. This additional strengthening makes it difficult to attack the stolen hashes with any significant speed."[24][25]
2016 incidents
In July 2016, a blog post published by independent online security firm Detectify detailed a method for reading plaintext passwords for arbitrary domains from a LastPass user's vault when that user visited a malicious web site. This vulnerability was made possible by poorly written URL parsing code in the LastPass extension. The flaw was not disclosed publicly by Detectify until LastPass was notified privately and able to fix their browser extension.[26] LastPass responded to the public disclosure by Detectify in a post on their own blog, in which they revealed knowledge of an additional vulnerability, discovered by a member of the Google Security Team, and already fixed by LastPass.[27]
2017 incidents
On March 20, Tavis Ormandy discovered a vulnerability in the LastPass Chrome extension. The exploit applied to all LastPass clients, including Chrome, Firefox and Edge. These vulnerabilities were disabled on March 21, and patched on March 22.[28]
On March 25, Ormandy discovered an additional security flaw allowing remote code execution based on the user navigating to a malicious website. This vulnerability was also patched.[29][30]