Researchers disclosed critical-severity flaws in three popular WordPress plugins used widely by colleges and universities. It was discovered that the flaws could be used to steal personal information (including names, emails, usernames, passwords), modify payment schemes, change grades, forge certificates or access tests in advance. These plugins LearnPress, LearnDash
According to the #CheckPoint, the three #WordPress plugins in question — #LearnPress, #LearnDash, and #LifterLMS — have #security flaws that could permit #unauthenticated users, to pilfer #personalinformation and even attain teacher privileges. #PII https://t.co/gMlV4yY0dj
— Taslet Security (@TasletCom) May 1, 2020
WordPress plugins are a critical third-party risk in any web application and a frequent target for attackers. A single compromised plugin can infect tens of thousands of websites in one stroke, hence they remain a popular attack vector. XSS vulnerabilities that enable RCE attacks are particularly problematic since they give attackers potentially unlimited access to the application. In addition to server-side attacks like these, third-party plugins can also introduce client-side risks such as Magecart attacks.
Businesses must understand the risks involved in adding third-party components to their web application. Staying up to date on versions helps but cannot guarantee the integrity of the third-party code.
LearnDash, LearnPress and LifterLMS are all examples of WordPress plugins designed to turn WordPress into a custom delivery platform – in this case for eLearning. Each of these follow a business model known as “open core” wherein key aspects of their business are open source, but their commercial offering differs from that available via open source channels. For practical purposes, this means that fixes for security defects may not immediately be identifiable in the source code they publish and that their commercial customers should hold them to the same standards of security they’d apply to any software vendor. In this case, these plugins demonstrated SQL Injection, privilege escalation and arbitrary file write with remote code execution vulnerabilities.
The scope of these vulnerabilities demonstrate why procurement processes should include a security verification step. That verification step should look for any latent or unpatched vulnerabilities, but also look for weaknesses in configuration and susceptibility to attack. While we would love to accept that all vendors apply stringent security reviews to the code they release, the reality is those practices vary considerably between organisations and defects do slip through. In the end, with ever increasing regulatory scrutiny for digital privacy, holding suppliers to account for the code they ship is one option everyone has to raise the security bar.