Cancel

Jeff Chandler

Ninja Forms Update Patches Critical Security Vulnerability

Ninja Forms Featured ImageNinja Forms, a popular plugin active on more than 500K websites, released an update 48 hours ago that addresses a critical security vulnerability. Wordfence is reporting that Ninja Forms versions 2.9.36 to 2.9.42 contain multiple security vulnerabilities.

One of the vulnerabilities allows an attacker to upload and execute code remotely on WordPress sites. The only information needed to exploit the vulnerability is the URL of the target site that’s using a form powered by an affected version of Ninja Forms.

Kevin Stover, CTO of Ninja Forms, explains to the Tavern how they discovered the vulnerabilities:

About two weeks ago, we were contacted by a security researcher, James Golovich, regarding a file upload issue within Ninja Forms. He demonstrated that it was possible to upload an arbitrary file using some test code that hadn’t been removed during our build process.

We realised that the test code had accidentally been utilised in other areas of the plugin, and we immediately began working on a fix. While the issue was being patched, we reached out to the devs at the WordPress.org repo and began the processes of preparing for auto updating users of the affected versions.

Once the patch had been tested, we pushed version 2.9.43 and .1 versions of 2.9.36 – 2.9.42. Shortly after, WordPress.org began pushing out automatic updates.

As to why there wasn’t a post published immediately on the official Ninja Forms blog announcing the update, “We didn’t want to go public with the vulnerability until our users had time to update, both to the newest version and the .1 versions,” Stover said.

“James Golovich’s responsible disclosure gave us time to fix the issue and for our users to update to safe versions before disclosing the vulnerability on his site,” he said. The company has since published a blog post concerning the update.

Working with the WordPress security team, automatic updates started rolling out on Tuesday, May 3rd. If automatic plugin updates are disabled, you’re highly encouraged to update manually to 2.9.45 as soon as possible. The Ninja Forms team is also working with a number of large webhosts to ensure as many sites as possible are updated.

Wordfence is not detecting wide-spread exploitation but this could change in the next few days as details of the exploit emerge.

When it comes to security vulnerabilities, the ability to upload and execute code remotely is about as severe as it gets. Golovich is credited with responsibly disclosing the vulnerability to the Ninja Forms team. He also provides technical details of each vulnerability, most of which are in the Ninja Forms 3.0 code base.

According to Golovich, the most vulnerable code is a proof of concept:

The following vulnerable code was, according to Kyle Johnson of the WP Ninjas team ‘not a live feature of Ninja Forms, but was more of a proof of concept for a future free feature.’ Unfortunately, even proof of concept code that is accessible is still vulnerable to attack. This is the most critical vulnerability here because it potentially allows an attacker to execute arbitrary php code on a site.

Users should update as soon as possible as it’s only a matter of time before tools are created that can easily take advantage of the exploit.

Category:
Tags: , ,
14

14 responses to “Ninja Forms Update Patches Critical Security Vulnerability”

  2. The following vulnerable code was, according to Kyle Johnson of the WP Ninjas team ‘not a live feature of Ninja Forms, but was more of a proof of concept for a future free feature.

    I call complete BS on this. Nothing about that sentence makes any sense in the real world. They screwed up bad – plain and simple.

    Create forum topic from comment

    • To be fair James Golovich’s report says this:

      For quite some time the WP Ninjas team has been busy doing a complete rewrite of the codebase to provide more flexibility in the future. Starting with version 2.9.36, a preview of the 3.0 code base has been included in the main plugin download and typically requires an administrator to manually enable that code for testing.

      All of the following vulnerabilities are in the 3.0 code base and any version before 2.9.36 are NOT affected in any way.

      http://www.pritect.net/blog/ninja-forms-2-9-42-critical-security-vulnerabilities

      Create forum topic from comment

      • users were expecting a release quality code and get beta quality code…… Every day you discover another way in which wordpress plugin development practices are horrible. Is there any one in addition to pippin and rarst that produces code that you can blindly trust for not doing stupid things? (talking about code quality, not about bugs or bad product design here).

        I am lucky in that I just had the plugin installed but haven’t had the time to actually do anything with it yet, so deleting it and never looking again at that direction will not be a problem.

        Seriously, for a week you left me exposed to security issues? If one guy knows about it then the whole internet knows about it, WTF were you thinking?, And many sites do not have the setting for automatic updates so pushing it by force from wordpress.org is not an alternative to a proper announcement.

        Create forum topic from comment

        • Is there any one in addition to pippin and rarst that produces code that you can blindly trust for not doing stupid things?

          Thank you for the compliment but this is just silly and blatantly wrong. Every single developer–PERIOD–introduces security vulnerabilities at some point. The only developer that’s never had one is the developer that has never released any code. Period, end of story.

          I was responsible for introducing one of the most severe vulnerabilities I’m aware of a few years ago. It was so bad, in fact, it allowed anyone to log into any site running one of my plugins as a full administrator by simply clicking a button–a button that was shown to all users on the frontend of the site.

          Let’s stay off of the high horses and be appreciative that the WP Ninjas acted immediately to resolve the issue once it was revealed to them and that they immediately worked to get every single site patched in a matter of minutes after releasing the fix.

          Create forum topic from comment

        • @Pippin, I actually said nothing about having the security issue, I was refering to the idea of shipping code that the developer himself knows it is not a release grade code marked as a release grade. That would have been a surprise if such design decision did not result in some exploitable code or just major major bugs that would have totally surprised people that are expecting a release grade product.

          Now the specific issue was solved, but was the design issue solved? Unlikely. So what bugs will be introduced in their next release from the code that “should not be active at all”, but made active by mistake?

          It is one thing to have one beer too much while coding, and another thing to plan to use the wordpress.org users as beta testers without their knowledge.

          And about your bug, that is exactly my point, when I install EDD the question I have in mind is “say pippin had access to my admin, would I have been able to trust him not to do something stupid?” because installing anyone’s code is in a way giving him admin level access to your wordpress, whether it is exploitable or not.

          Side note: It is nice to see you and others come to the defense of people that had a bad day, but if those people are not publicly whipped (yaost, jetpack come to mind as examples right now) what incentive will they have to improve? It sounds like any shenanigans is ok from plugin and theme authors as long as it doesn’t involve ads, or they say sorry. The chances of anything improving code wise in the ecosystem when failures are so easily fogiven is slim.

          Create forum topic from comment

        • It wasn’t beta testing on all users without their knowing. It was an opt-in beta that was made available to users if they wished to use it.

          Very different thing.

          Also never, ever, ever will I condone the public “whipping” of someone because they made a mistake and put some code in a plugin that shouldn’t have been there or contained vulnerabilities.

          Create forum topic from comment

        • As I understand it the code is exploitable whether they had the 3.0 preview running or not, so the “bad code” was installed and exploitable regardless of opting in to test it or not. That’s the issue Mark is referring to.

          If a site has not manually enabled the 3.0 code for testing, it is trivial for an attacker to bypass this and execute the 3.0 code. For all of the following vulnerabilities a site admin does NOT need to have enabled the 3.0 codebase.

          http://www.pritect.net/blog/ninja-forms-2-9-42-critical-security-vulnerabilities

          Create forum topic from comment

        • It was untested (or very poorly tested) code pushed to half a million installs, without any notice. Without that untested code, the exploit of being able to activate 3.0 without having admin permissions would have been just a forgettable curiosity, with it, it is an actual problem.

          We are talking here about half a million sites here that are in risk, not 5k, and from what I can read in the stats, a week after the updated release and the forced update only 25% were upgraded to latest release. And all those people were put in risk because someone had a great idea how to shortcut proper development cycles.

          Also never, ever, ever will I condone the public “whipping” of someone because they made a mistake and put some code in a plugin that shouldn’t have been there or contained vulnerabilities.

          At the outbreak of one of the latest plugin related security issue someone on slashdot summed it nicely “wordpress is not secure out of the box and you need a security plugin to make it secure, but if you want a secure wordpress site you better not use any plugin”. It doesn’t matter at all if it is true or not cause this is what the tech world thinks about wordpress, and that forgiveness that you show makes people in the wordpress ecosystem think that it is ok to write insecure bad code, therefor justifying the above view of wordpress security.

          Create forum topic from comment

    • Hey Ron,

      I completely agree with your sentiment. We did screw up. The feature that Kyle is referring to was an early prototype of a file upload field that we started developing but eventually shelved. The code shouldn’t have been in production because the feature was abandoned. It fell through the dev/testing cracks. Kyle isn’t trying to shirk any responsibly. He was just explaining that we didn’t catch the problem because of a breakdown in our development process. We’re working on improving this process so things like this don’t happen in the future.

      Create forum topic from comment

        • We will continue to release version 3.0 alongside the 2.9.x codebase. So far, this slow roll out has been invaluable in our development of 3.0. The security mistake has definitely helped us identify weaknesses in our processes and shown us where we can improve testing and auditing of the dual codebase.

          Create forum topic from comment

  3. The wording of the post is a bit misleading with this statement: “Wordfence is reporting that Ninja Forms versions 2.9.36 to 2.9.42 contain multiple security vulnerabilities.” It makes it sound like Wordfence discovered the vulnerability instead of James Golovich. Of course if you continue reading you can clearly see that James Golovich deserves all the credit. ;)

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.