Much of the impression that WordPress is not secure seems to be based on WordPress being blamed for hacks where the source wasn’t actually determined and security issues with plugins, but there are long-standing security issues in WordPress that haven’t been addressed. The Release Leads of WordPress and whatever the WordPress security team really is are failing to address these. To better understand what is at issue, we have created this page to keep track of those issues. If you are aware of an issue missing, please let us know.

Last updated: 5/1/2025

is_admin()

The WordPress function is_admin() is often believed incorrectly, but understandable, to tell if a request is coming from a user with the Administrator role. It actually indicates if an admin page is being accessed. That will return true in some situations even if someone is not logged in to WordPress. To make things more confusing, there is a is_super_admin() function, which does if a request is coming from an Administrator unless WordPress Multisite is being used.

The confusion over the function has been a part of widely exploited vulnerabilities for many years. A ticket to rename the function was created in February 2011. It was closed in January 2013 without the issue being addressed. The explanation was given “this ticket was totally ignored for 2 years, and those have been in use for a long time now, so now I really think this patch is completely pointless now, and not worth doing.” It is an odd response to decide to not fix a security issue because you failed to fix it for two years.

maybe_unserialize()

The PHP function unserialize() has long been known to be vulnerable to PHP objection injection. A non-default fix for that was introduced in December 2015. The WordPress function maybe_unserialize() uses unserialize() without implementing the fix. A ticket to address that was started in August 2016. It was last updated in September 2017. It is labeled as normal priority and normal severity, despite the security risk. The milestone is set as awaiting review. In August, a vulnerability in WordPress plugin caused in part by this issue received press coverage. This function’s role in that was conspicuously not mentioned by a major WordPress security provider.

SSRF Protected Functions Failing to Prevent SSRF

The WordPress functions wp_safe_remote_get(), wp_safe_remote_post(), and wp_safe_remote_request() are claimed to “avoid Server Side Request Forgery attacks (SSRF).” It is a known issue that they fail to do that in at least some instances where they should. WordPress has apparently known about this long enough for a fix to have been in the works for “few years,” without it being released. We couldn’t find where a fix is being on worked on.

Installer Insecure

It has long been a known issue that if the WordPress installer is not run promptly after WordPress is loaded on a website, hackers can go through the installation process and get control of the website. That is an issue that looks to have been exploited at scale. A ticket to address that was started in July 2022. It is labeled as high priority and major severity, but is simply scheduled to be addressed in a future release.