WordPress developers fixed a serious SQL injection vulnerability on Tuesday with the release of version 4.8.3.. Apply it as soon as possible.
WordPress developers fixed a serious SQL injection vulnerability that was reported by the researcher Anthony Ferrara, VP of engineering at Lingo Live.
The issue was addressed on Tuesday with the release of version 4.8.3.
The vulnerability can be exploited via WordPress plugins and themes, an attacker can take over vulnerable websites by powering an SQL injection attack.
The new security release implemented hardening mechanisms to the WordPress code to prevent attacks.
“WordPress versions 4.8.2 and earlier are affected by an issue where $wpdb->prepare() can create unexpected and unsafe queries leading to potential SQL injection (SQLi). WordPress core is not directly vulnerable to this issue, but we’ve added hardening to prevent plugins and themes from accidentally causing a vulnerability. Reported by Anthony Ferrara.” read the description provided by WordPress.
The problem is linked to a SQL injection vulnerability discovered a few months ago by a researcher who goes online with the moniker “Slavco.” The issue was addressed with the release of WordPress 4.8.2 in September, but the fix introduced by the development team broke many websites. Furthermore, shortly after the patch was released, Ferrara, discovered that the latest release did not fix the vulnerability.
The WordPress security team took roughly 6 weeks to fix the problem and create a proper patch.
The researcher criticized the speed in approaching the issue by the WordPress security team, initially, he also planned on disclosing the details of the flaw without a concrete response from the organization.
Once established a contact, the things went better.
“It took literally 5 weeks to even get someone to consider the actual vulnerability. From there, it took me publicly threatening Full Disclosure to get the team to acknowledge the full scope of the issue (though they did start to engage deeper prior to the FD threat).
Once the issue was understood, we got to a really good place. If the entire interaction was like Oct 27 – Oct 31, I would have been ecstatic. Even if on a different time-line (the good part wasn’t the speed of the replies, but the content of the conversation).” explained Ferrara.
“Security reports should be treated “promptly”, but that doesn’t mean every second counts (usually). I get that there are competing priorities. But show attention. Show that you’ve read what’s written. And if someone tells you it seems like you don’t understand something, stop and get clarification.”
“It took literally 5 weeks to even get someone to consider the actual vulnerability. From there, it took me publicly threatening Full Disclosure to get the team to acknowledge the full scope of the issue (though they did start to engage deeper prior to the FD threat),” Ferrara said in a blog post.
“Security reports should be treated ‘promptly’, but that doesn’t mean every second counts (usually). I get that there are competing priorities. But show attention. Show that you’ve read what’s written. And if someone tells you it seems like you don’t understand something, stop and get clarification.
Source:https://securityaffairs.co/wordpress/65057/hacking/sql-injection-vulnerability.html
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
