Experts Comments On Bugs In WordPress plugins LearnPress, LearnDash, And LifterLMS For Online Courses Let Students Cheat

By   ISBuzz Team
Writer , Information Security Buzz | May 01, 2020 07:37 am PST

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  LearnPressLearnDash, and LifterLMS are together have been installed on more than 130,000 school websites as part of their learning management systems, including the University of Florida, University of Michigan and University of Washington.

Notify of
2 Expert Comments
Oldest Most Voted
Inline Feedbacks
View all comments
Ameet Naik
Ameet Naik , Security Evangelist
May 1, 2020 3:58 pm

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.

Last edited 3 years ago by Ameet Naik
Tim Mackey
Tim Mackey , Principal Security Strategist, Synopsys CyRC (Cybersecurity Research Center)
May 1, 2020 3:38 pm

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.

Last edited 3 years ago by Tim Mackey

Recent Posts

Would love your thoughts, please comment.x