Decade-old critical vulnerability in Jetpack patched on millions of WordPress websites

Jetpack. an extremely popular WordPress plugin that provides a variety of functions including security features for around five million websites, has received a critical security update following the discovery of a bug that has lurked unnoticed since 2012.

Jetpack’s maintainers, Automattic, announced on Tuesday that it had worked closely with the WordPress security team to push out an automatic patch for every version of Jetpack since 2.0.

The security hole is in Jetpack’s API and has been present since version 2.0 was released over a decade ago, in 2012.

The vulnerability, which could allow authors on a site to manipulate any files in a WordPress installation, was found during an internal security audit.

If exploited, the flaw could have allowed a malicious hacker to change content on a website, which might have compromised the security of other users and website visitors.

The good news is that Automattic says it has not seen any evidence that the vulnerability has been used in malicious attacks. However, that is far from a guarantee that the security hole has not been exploited.

If anything, now the problem has been made public, there may now be more determined attempts by cybercriminals to exploit the flaw – underlining the importance for all vulnerable WordPress-powered websites to ensure that they are running a secure version of Jetpack.

Fortunately, WordPress has in place a reasonably robust system of automatically pushing out critical security updates in situations like this, and almost all at-risk WordPress-powered websites are likely to have already been automatically updated to a secure version of the Jetpack plugin.

Jetpack, just like WordPress, is open source. That means that anyone can check the source code, and it is frequently claimed that one of the benefits of open source is that this means it is more likely that security holes will be found.

And yet this security vulnerability went unnoticed for over ten years.

Just because anyone can check open source code for critical security vulnerabilities, it doesn’t necessarily mean anyone is.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire.