|
|
Over the past few weeks, our team has dealt with an XSS security vulnerability in the Freemius WordPress SDK. Due to the unique nature of WordPress being an open-source ecosystem, our WordPress SDK, and all products using the SDK are open source — making the patch-planning and execution trickier than software in closed ecosystems.
The primary objective of this article is to transparently shed light on how we managed the Freemius SDK vulnerability. Additionally, we’ll share valuable insights so that others can learn from our experience navigating the security issue in an open-source environment.
Before getting to the sequence of events and how we tackled the fixing and distribution of the patch, let’s start with the bottom line.
What Are the Potential Risks of the XSS Security Issue?
Following the initial investigation, we found that the vulnerability would require an attacker to engineer a malicious JavaScript code embedded within a URL, send it to a site’s administrator, and then make them click the link while logged in.
While it requires a human “weakness”, when executed successfully, a sophisticated hacker may be able to add themselves as a site administrator.
At a later stage, our VP of Engineering discovered another attack vector that circumvented the need for a “phishing” attack and exploited a different mechanism of the SDK, along with the current weakness. While the procedure requires extensive knowledge of the WordPress SDK, it could have activated privilege escalation for existing users who use an admin interaction that is much easier to obtain.
Is the Freemius SDK Vulnerability Being Abused in the Wild?
We are unaware of any attacks targeting this vulnerability.
How Can I Check If a Website Runs a Secure SDK Version?
A special mechanism in our WordPress SDK ensures that the latest SDK is automatically used. As a result, it is sufficient if one plugin/theme uses the fixed SDK, even when a website actively utilizes multiple plugins/themes that use Freemius.
An admin can verify a website is already patched by visiting /wp-admin/admin.php?page=freemius and making sure the Active SDK version is 2.5.10 (or higher) as shown here:
What Is the Current Status of the Incident?
The majority of the products running the Freemius SDK have already upgraded to the patched version. Additionally, our SDK comes with a nifty feature that lets multiple plugins or themes supported by Freemius on the same WordPress site access the latest SDK version even if just one of the products is updated.
That said, there are still vulnerable sites. This is why we don’t share technical details about the vulnerability itself, or the affected products. We still want to offer our developers the chance to patch their products and allow their users to update to the secure versions.
The Freemius SDK Vulnerability Report
On June 19th, we received a report from Patchstack about a potential XSS security issue in our WordPress SDK.
We take security very seriously and immediately prioritized the report’s review.
After confirming the validity of the reported issue, we spent time developing a proof-of-concept attack to test the weakness in action. It helped us assess the severity of a potential attack and what it would require to execute one.
If there’s one key lesson we learned from previous security incidents, it’s to avoid rushing. It’s counterintuitive because, naturally, there’s an emotional urge to get things fixed as soon as possible. But we learned the hard way that not taking the time to think and plan properly eventually leads to execution mistakes, which can do more harm than good.
With the Freemius SDK vulnerability validated and tested, we got down to the strategy of how to tackle it:
The Planning
Our CEO, acting as our Chief Information Security Officer (CISO), arranged a meeting with key team members on the day of discovery to devise a strategy to address the incident, with a focus on ensuring the safety of websites that utilize products with Freemius’s SDK.
Here’s the plan we came up with:
- Let multiple team members evaluate, test, and patch the vulnerability independently so that we could either choose the best patch or get to the same solution.
- Patch the vulnerability in a private GitHub repository to make sure it wouldn’t leak.
- While we were on it, leverage this opportunity to tighten up the SDK’s security even further.
- Get Patchstack security researchers to review and approve the fix to the Freemius SDK vulnerability.
- As soon as the fix was ready, contact developers and give them two weeks to prepare an update while ensuring everyone releases patched product versions on the same “patch day” (more on this in the section below).
- Only notify developers who are actively using the SDK in their products (not all registered developers) to reduce exposure to the absolute minimum.
- 48 hours after the expected patch day, send reminders to developers who hadn’t pushed a fix yet.
- Give users two weeks to update their websites after “patch day”.
Why Synchronize the Patch for the Same Day?
The instinctive reaction is to ask our partners to update the SDK and release a patched version of their products immediately (or as soon as they can). And this is how we tackled the previous incident. However, following a tip we got from Patchstack, we realized it’s not the best strategy. Here’s why: The SDK is used by thousands of products and developers. As soon as developers start pushing updates, there’s a risk of unwanted attention by security trolls and bots which are actively monitoring the WordPress.org repo.
Basically, a single product update can jeopardize the entire patch launch for everyone else. Therefore, to give enough time for all developers to upgrade, we decided on July 5 as the official “patch day” and requested our partners to push the patch on the same day (or as soon as they could afterwards). So, even if it gets caught by trolls, the vast majority of products using the SDK will already have been patched by then.
Fix Distribution Plan
Following the meeting, our team started to work on the patch.
In parallel, we scheduled a meeting with Patchstack to plan the patch distribution and public disclosure.
In coordination with Patchstack, we decided developers would release a patched version exactly on July 5th (the 4th of July was already taken 😅), and the public disclosure would follow on July 18th, giving two additional weeks for users to update.
Things worked precisely as planned! We emailed the patch to the relevant developers and asked them to patch it on July 5th. We then sent three more email reminders between July 5th and the public disclosure (today) to nudge developers who hadn’t updated in order to minimize the number of vulnerable products upon disclosure. Following the precautions we took, bots didn’t pick up on the vulnerability and no one leaked the issue, giving a healthy grace period for developers and website owners to update. This truly feels like a miracle 🙏
A Note About Patchstack (+ a Huge Thank You!)
What a refreshing and positive experience it was to work with the Patchstack team (thank you, Darius and Rafie 🙏). Finally, a security company that truly cares about website security and works with you in full cooperation and coordination.
In previous incidents, not only did the vulnerability reporter not cooperate with us, they also publicly disclosed the vulnerability ahead of time (including an attack example) and didn’t follow responsible disclosure practices. All for the sake of taking credit for the discovery while risking millions of users. Because of the potential harm this behavior can bring about, it is important to spread awareness to mitigate early disclosure as much as possible.
Final Thoughts
Security issues can (and will) happen to anyone, whether you’re a talented indie plugin developer, a creative theme designer, a growing startup of twenty, or even a tech giant like Meta. But here’s the thing: what really matters is how we handle these situations while prioritizing our partners’ and users’ safety, first and foremost.
Here at Freemius, we keep learning and improving. When these hiccups occur, it’s painful, but we grow and improve our recovery playbook and processes even further.
On behalf of the entire Freemius team, we want to extend our heartfelt apologies for any inconvenience caused. Rest assured, we’re here for you every step of the way, offering support, advice, or any other assistance you might need to tackle this issue head-on. And to our new partners, we understand that this might not be the greatest first impression, but we’d love to prove to you that we ship way more features than security issues 😉 But seriously, vulnerabilities are quite rare on our end, and when they do happen, we are committed to addressing and resolving them swiftly and transparently.
