In Avada 5.1.5, we fixed two security issues which were in Avada versions 5.1.4 and below. This can always be found in our Changelog and we recommend to keep your theme up to date. It’s best to use auto updates and to also keep an eye on the Fusion Patcher tool as we typically issue updates for security issues in less than 24 hours.

Like WordPress, we understand that security is not an absolute, it’s a continuous process and should be managed as such. While we try to be proactive in preventing security problems, we do not assume they’ll never come up. Our job is to quickly take care of them and work to get customers notified about them. The major difference here is that we do not get our customer emails.

First off, the two issues fixed are below, and you can read more about them here and how to update the full theme which we recommend, or manual fix for older versions

  • FIXED: Security fix to prevent additional calls to permalink structure (XSS)

  • FIXED: Security fix that adds AJAX request verification for Fusion Builder content importer

Our development team immediately took action to check and verify the issue at hand. Once accurately identified, our team fixed it with a patch in less than 24 hours, and the full Avada 5.1.5 update was sent out in 4 days. Confirmation of the patch release date can be found here under 5.1.4: … and confirmation of the changelog release that lists out the security fixes can be found here: Avada changelog.txt

This was a unique situation for us because it started with a person who reported this and showed us the post they would make live. While we appreciate being made know of security or bug issues, and fix them quickly, we had major concerns over how we were approached.

A bounty reward was being pursued, the content of the post they were making live explained how to fully use the exploit itself, in addition questions asked to hide those portions of the content were asked and we answered, but were ignored. The person hid their identity, ignored our requests and even published the post early. Most shockingly is the creator of that site had a script running that automatically creates their email as an admin user for the sites it’s run on. You can view this in their comments. While the script appears to be changed, even having such a thing should give anyone caution. We had no clue who we were dealing with, but clearly this was wrong. Anyone using Avada should check their user area of WP Admin and verify you know of all users listed.

There are several important factors to note:

1. We (ThemeFusion) do not have all customer emails. In fact, we have less than 1/5th. Envato keeps them and does not give them to the authors who sell items. While we petition to get them, it goes nowhere so sending out a public blog post before everyone was made aware (through Envato’s eBlast) would of also made potential hackers aware who would take advantage of it.

2. Due to the above, we have no way of contacting all of our customers at once. In addition, we had concerns over the post of the reporter which explains how to use the exploit, and not knowing when they were sending out the post, we had to rely on Envato to do so.

3. Each time we send in a theme update, it lists out the changelog in detail. Both security issues were listed and their fixes approved by the Envato review team and the new version posted on the marketplace.

4. We did a similar thing to what WP did back in February and elected to put off disclosing the vulnerability to make sure that our users who use automatic updates on their sites – were protected before going public.

We allowed customers to see auto updates for both the theme and the patcher tool and get as many updated as possible. The patcher tool description and changelog were descriptive in making users aware that security issues were fixed. Nor is this information buried as we described above, in fact they use the standard WordPress method of letting you know updates or patches are available and ready to apply. The changelog link is directly on the updates page in WP admin, the themes page as well, and the patcher tool describes each one in it’s location in WP admin. In addition, all of this is online at our support center.

5. This all being very recent, and in agreement with Envato about the security related customer notification, we expected the actual communiqué to be sent out to each person that has purchased Avada, which it has been. However we implicitly asked Envato to allow us to review the content of the email before it was sent. We wanted to review the content of the eBlast so that we can ensure our customers are being given the correct information and to include additional helpful information about the update or users who were updating from much older versions. Lastly, we asked to know exactly when it was sent out so we could time ours as well. Unfortunately Envato did not get in touch with us in time.

6. The day Envato did send out the eBlast to every customer, we received it as any customer would and then also posted the information on our site:

We did inform our users about the available update that included the security fix through the several ways that we could: changelog, automatic patcher tool, a user through our private Facebook group and of course the automatic theme update. None of this information is buried. Even before we released 5.1.5, the security patch fix was done in 24 hours or less through our live patcher tool. Like it is in WordPress, it can be easily seen, that a patch/update is available. Both were labeled starting with “Security fix”, containing the kind of security issue “(ex: XSS)”.

Why did we wait some time before a publicly available disclosure was done from our side?
To protect our customers.

How can this course of action protect customers?
We do know from website traffic checks, that our user base does update to new versions very fast. So making the update available, and using the more private information channels listed above (auto patch notifications, auto theme updates), we made sure that the majority of our users was already protected before the general public (which of course includes potential hackers) was made aware of the security issue through public blog posts.

This is not an uncommon approach, but also something WordPress has done, examples below:

The issue itself has been resolved over a month ago, a patch created in 24 hours or less once we were notified and our user base was informed about it (automatically) through our changelog, our live patcher tool and a post in our private Facebook group. That is as much as we can do since we do not have all customer emails. Lastly and finally, Envato sent the full eBlast to all customers last week. Time in-between users updating and a public disclosure is needed for a reason.

Our customers know we are not negligent in any way, they know we do everything possible for them and this involves fixing any and all security or bug issues. We campaign tirelessly for all of our customers, to maintain their installs and ensure that the theme is always updated or a patch applied.

We will keep doing what we always have done and build strong relationships with our customers through trust and communication.