WordPress’ Latest Canonical Plugin WPGraphQL is Still Using Vulnerable Version of Library 18 Months Later
Two days ago Matt Mullenweg announced the WordPress plugin WPGraphQL was becoming a canonical plugin:
Happy to announce that WP GraphQL is becoming canonical on WordPress.org. I could say more, but I’ll let Jason tell his story.
The post that links to is rather problematic for reason we won’t get in to now. What will say is that a basic of security vetting hasn’t done before announcing it is becoming canonical.
Running the plugin through our Plugin Security Scorecard today, the plugin got a C+:

The last three issues mentioned are not all that concerning, they are focused on having best-in-class security. The first is rather concerning:
- The plugin contains a version of the third-party library Appsero Client that contains a privilege vulnerability. If the library is active in the plugin, then the plugin is also vulnerable.
If you follow the link, it is post we wrote talking about us finding another plugin was still using a vulnerable version of the Appsero Client library 17 months later. That was written a month ago, so the developer of WPGraphQL hasn’t bothered to update that same library in 18 months since the vulnerability was fixed. The last time they updated the library was in October 2022.
The threat posed by the vulnerability is very minor, unless a hacker could figure out someone to combine it with something more serious. The vulnerably does make part of this claim made on the plugin’s page on the WordPress Plugin Directory false:
Integrating Appsero SDK DOES NOT IMMEDIATELY start gathering data, without confirmation from users in any case.
The vulnerable library is also included in the WPGraphQL for ACF and WPGraphQL Smart Cache plugins from the same developer.
We notified the developer after seeing those results.
On the plugin’s security page developer claims that “WPGraphQL has been developed with security in mind.” Part of we wrote last month also applies with this plugin, with only the dates being slightly different:
Beyond the problem here of not updating the vulnerable library in 17 months or even updating it outside of knowing it is vulnerable for 24 months, the vulnerability would have been caught during a decent security review of the plugin or the library. Unfortunately, as this plugin is yet another reminder of, plugin developers are often not vetting third-party code being incorporated into their plugins. With another library, even a vulnerability being widely exploited in the library didn’t cause developers incorporating it to vet the security.