WordPress 7.1 “Mary Lou” was released on 19 August 2026. It is a major update with new editor and design features, but the security releases immediately before it are just as important for website owners to understand.
The practical lesson is simple: updating WordPress is not about chasing every new button in the dashboard. It is about closing known paths before somebody else tests them against your website. A current WordPress version still needs current plugins, safe hosting, strong accounts and sensible access controls.
What WordPress 7.1 introduces
WordPress 7.1 improves the editing experience in several areas. Responsive styling can be controlled directly in the Site Editor, so block-based sites can adjust appearance across screen sizes without relying on custom CSS for every change.
The release also adds a dedicated media editing workflow, richer Notes for collaboration, new Playlist and Tabs blocks, improved admin navigation and further accessibility work. Developers receive new options around icons, responsive styles, admin interfaces and the WordPress design system.
These features matter most to sites that use the WordPress Site Editor and block themes. A site built with Bricks Builder may not use every new editor control, but the underlying WordPress security and maintenance benefits still apply.
Why security updates should not wait for a convenient maintenance window
The releases before 7.1 show why automatic or prompt updates matter. WordPress 7.0.2 fixed a critical REST API batch-route problem that could be combined with a SQL injection issue. The chain could be reached without a normal administrator login and was treated as serious enough for forced updates on affected sites.
WordPress 7.0.3 fixed twelve security issues, including a reflected XSS issue on the login screen with a potential path to PHP code execution, several stored XSS issues, privilege escalation, information disclosure and an SSRF issue in URL validation.
WordPress 7.0.4 fixed an authenticated Author-level remote code execution issue involving malicious file uploads on sites using Imagick and Ghostscript. The permission level and server configuration matter, but the example is important: a vulnerability does not need to start with a simple password guess to become dangerous.
What SQL injection in WordPress can mean in practice
SQL injection is not just a technical phrase about a database query. If an attacker can reach an unsafe query, the consequences may include reading sensitive records, discovering user information or using the result as one step in a larger takeover chain.
The WordPress 7.0.2 issue was especially serious because the vulnerable path involved the REST API and could be reached without authentication when the route confusion and query weaknesses were combined. That is why updating only a security plugin would not have been enough: the vulnerable code was in WordPress Core.
Can attackers log in to wp-admin without the password?
Sometimes the problem is not a stolen password. A vulnerable login, OAuth or SSO integration can make WordPress create a valid session for the wrong person. From the site owner’s point of view, the result can look like an attacker has logged in through wp-admin even though the password was never guessed.
A recent example involved the miniOrange SAML 2.0 Single Sign-On plugin. Public reporting described critical authentication-bypass issues that could allow an unauthenticated attacker to forge or confuse the SAML verification process and obtain a session as an existing WordPress user, including an administrator. The affected version depends on the product edition, so checking only the plugin name is not enough.
Other recent plugin reports have involved OAuth callbacks, unverified email addresses and weak server-side checks. This is why a login limiter alone is not a complete defence. It can slow repeated password attempts, but it may not stop an authentication-bypass flaw that creates a valid session in a different way.
The plugin layer can be more urgent than Core
WordPress Core is only one part of the application. Forms, page builders, SEO tools, ecommerce extensions, SSO plugins and file-upload features all process data from visitors or logged-in users. A single vulnerable extension can create a route into an otherwise updated site.
For example, a recent Elementor Pro advisory described an unauthenticated file-upload issue in the Forms module that could lead to remote code execution when the vulnerable upload feature was present. The correct response was not simply to disable WordPress login attempts; it was to update the plugin and review affected upload directories on sites that had been exposed.
The same principle applies to SQL injection in plugins. Recent vulnerability databases contain both authenticated and unauthenticated SQL injection reports. The required permission, active feature and patched version must be checked for the exact plugin installed on the site.
What AI changes in the security race
AI is changing the economics and speed of security research. Researchers can use models to inspect large codebases, compare patches, identify inconsistent validation and build test cases faster. Attackers can use similar automation to scan many websites and plugins instead of studying one site manually.
Public reporting around the WordPress 7.0.2 SQL injection chain described an AI-assisted research process that reached a working pre-authentication result in hours rather than weeks. That report came from independent security research, not from the WordPress project, and it should be read as evidence of a changing capability rather than a guarantee that AI finds every bug.
Some WordPress 7.0.3 issues were also credited to security teams using automated or AI-focused research. The practical consequence is that the time between a vulnerability being discovered, explained and added to automated scanning can become shorter. Once details are public, bots do not need to understand the whole website; they can test for the same known condition at scale.
What we do after a WordPress update
Updating the files is only the first step. After a major or security update, we check whether the site still works and whether the update changed an integration or exposed a new conflict.
- Confirm the exact WordPress, PHP, Bricks, theme and plugin versions
- Check plugin and theme advisories, not only the WordPress dashboard
- Review administrator accounts, SSO providers and recent login activity
- Test the public website, forms, payments, email and integrations
- Check backups before making a major change and confirm that restoration is possible
- Remove unused plugins, themes, test files and exposed backup archives
- Investigate unexpected users, files or administrator sessions instead of simply reinstalling the latest update
Should every website update immediately?
Security releases should normally be applied quickly, with a backup and a recovery path. A major feature release deserves a compatibility check when the site has important ecommerce, membership, booking or custom integrations. Delaying a security fix for weeks without a compensating control is a different decision from testing a feature release for a short period.
Do not disable automatic updates just because one previous update caused a visual issue. Use staging, backups, monitoring and a rollback plan. The safer process is controlled updating, not permanent avoidance.
Sources and further reading
WordPress 7.1 release — official announcement
WordPress 7.0.2 security release — official announcement
WordPress 7.0.3 security release — official announcement
WordPress 7.0.4 security release — official announcement
Patchstack analysis — WordPress Core SQL injection chain
Patchstack analysis — miniOrange SAML SSO authentication bypass
Patchstack analysis — Elementor Pro file-upload vulnerability
