Security Flaw in WordPress: A Flawed Email Confirmation Feature
Introduction:
WordPress introduced a feature in version 4.9 requiring an email confirmation link to change the site email address. While this feature aims to enhance security by verifying that the user has access to the new email address, I argue that it creates confusion and weakens security in certain contexts, particularly in single-site WordPress installations.
Purpose of the Email Confirmation Feature:
The idea behind this feature is to ensure that the person requesting a site email change can access the new email address, preventing SPAM, reducing mistakes, and confirming that the email is active. This pattern is widely used in platforms like Facebook, where a confirmation email is sent to verify identity before account changes are made. However, in WordPress, the implementation of this feature—especially on single-site installations—introduces more problems than it solves.
Issues with the Current Implementation
1. Confusion Between Roles in Single-Site vs. Multisite Installations:
In a multisite installation, there are two distinct admin roles: super admin and regular administrator. These roles have different capabilities, making the email confirmation feature somewhat logical. The super admin has authority over the network, while regular admins manage individual sites. However, on a single-site installation, there is only one type of admin, and this feature introduces unnecessary role confusion by implying there are two distinct roles: an “installing admin” and a “post-install admin.”
This distinction doesn’t apply to single-site installations, where all admins have the same capabilities. The requirement for email confirmation adds complexity, making it harder for admins to understand their permissions. It also creates an inconsistent experience between single-site and multisite installations.
2. Arbitrary Code Execution Makes the Feature Pointless:
In WordPress, admins can run arbitrary code, giving them unrestricted control over the site. This means an admin can bypass the email confirmation process by simply running code that changes the site email. As a result, the feature gives a false sense of security. If an admin has the power to run code, the system shouldn’t impose an artificial restriction that they can easily work around. The current implementation pretends to enforce security, but admins can still override it.
3. Transient Data Exposure and Security Risks:
During the email confirmation process, the old and new email addresses are both stored in the database, potentially for a long period of time. This creates a window of vulnerability where sensitive information could be exposed, especially if backups are taken during this transient period. Storing two email addresses for no clear reason seems like an unnecessary security risk.
4. Inconsistent Logic for Admin Roles:
The feature assumes that admins need to confirm email addresses, but this is inconsistent with how other admin actions work. For example, when an admin creates a new user, they can skip sending a confirmation email. This inconsistency makes the email confirmation requirement for site email changes feel arbitrary and out of place. If email confirmation is necessary for security, why isn’t it applied to more critical settings like the site URL?
Fundamental Flaw: False Security in Single-Site Installations
The core issue with this feature is that it doesn’t make sense in the context of single-site installations, where admins have equal power. The process of confirming the email doesn’t prevent admins from making changes if they can run arbitrary code. This false restriction can confuse admins, leading them to believe they are limited when, in reality, they are not.
Additionally, WordPress allows users to install the platform without outbound email access. During installation, the site email can be set without confirmation, but after installation, the same user is blocked from changing it without email credentials. This inconsistency makes the feature feel more like an oversight than a security enhancement.
Encryption Problem: Non-Standard and Insecure
One significant concern is that the encryption method used for the site email confirmation link is a custom MD5 hash, which is weaker than the standard WordPress nonce system. This inconsistency introduces potential security vulnerabilities, as custom solutions are typically less robust and harder to maintain than standardized approaches. The user email change system, for example, uses the nonce system, which is extensible and more secure. Why wasn’t the same method used for site email changes?
Conclusion: A Poorly Implemented Design Choice
This email confirmation feature in WordPress 4.9 was likely added with good intentions, but it introduces more complexity and confusion than necessary, especially for single-site installations. The reliance on email confirmation for a setting that an admin can bypass with code creates a false sense of security. Moreover, the custom encryption used is less secure than standard options available in WordPress. While preventing typos in email addresses might be a reasonable goal, the approach taken is overkill and creates more problems than it solves.
In conclusion, this feature should either be rolled back or significantly rethought to align with WordPress’s actual user roles and security needs. Admins with the ability to run arbitrary code should not be subject to artificial restrictions, and any system that claims to enhance security should not introduce new vulnerabilities in the process.