WordPress 6.8 introduces several important security improvements that site owners should be aware of. While not a major security overhaul, the update includes meaningful changes to core authentication, API security, and database handling that tighten the platform’s security posture. This article breaks down the key changes, explains how they affect your site, and provides guidance on preparing for the update. Whether you run a single blog or a multisite network, understanding these changes helps you plan your update strategy and evaluate whether your current security setup covers gaps that core now addresses.
WordPress 6.8 security features news: The Security Landscape Leading to WordPress 6.8
WordPress powers over 43% of all websites on the internet, making it a primary target for attackers. In 2025, the WordPress ecosystem saw a 50% increase in reported plugin vulnerabilities according to Patchstack’s Q1 2026 report, with over 1,200 new CVEs disclosed. This rising threat landscape 2026 WordPress Security Threats has put pressure on WordPress core developers to strengthen the platform’s built-in security mechanisms rather than relying solely on third-party plugins.
The WordPress 6.8 release reflects this shift. While previous major releases focused primarily on feature development and the block editor, 6.8 dedicates substantial engineering effort to security hardening. This is a welcome change for site owners who manage multiple WordPress installations and need a strong security baseline without configuring dozens of security plugins on every site.
WordPress 6.8 was developed over a six-month cycle with input from the WordPress Security Team, hosting providers, and independent security researchers. The changelog includes contributions from over 200 developers, with approximately 30% of all changes touching security-related code. This represents the highest proportion of security-focused commits in any WordPress major release since version 5.0.
WordPress 6.8 security features news: Updated Salts and Key Generation
WordPress 6.8 updates the secret-key generation in wp-config.php to use cryptographically stronger random sources. New installations will automatically get improved authentication salts and keys. Existing installations are not affected unless you regenerate your salts. This change aligns with modern cryptographic standards and addresses recommendations from security audits of the WordPress core codebase.
The improvement ensures that newly generated authentication keys and salts have higher entropy, making them more resistant to brute force attacks on session tokens. For existing sites, we recommend regenerating your salts after updating to 6.8 using WP-CLI (wp config shuffle-salts) or by visiting the WordPress salt generation API and updating wp-config.php manually.
Salts are critical because they add randomness to password hashes and session tokens. If an attacker gains access to your wp-config.php file, having outdated or weak salts makes it easier to crack session tokens offline. The new generation algorithm uses /dev/urandom on Linux systems and CryptGenRandom on Windows, both of which are cryptographically secure pseudorandom number generators (CSPRNGs). Previous versions relied on a simpler random generation that, while not broken, did not meet the latest NIST recommendations for cryptographic key generation.
REST API Rate Limiting Improvements
The REST API now includes better rate limiting for unauthenticated requests. While WordPress has historically relied on plugins for rate limiting, 6.8 introduces core-level protections that reduce the impact of API-based brute force attacks. The rate limits are conservative by design to avoid breaking legitimate integrations. Sites that use the REST API heavily should test their integrations against the new limits to ensure they are not prematurely throttled.
The rate limiting targets common abuse patterns: repeated login attempts via the REST API, excessive user enumeration queries, and rapid-fire requests that indicate automated scanning. These protections reduce server load during attacks and slow down credential stuffing attempts. Site owners who already use a security plugin with rate limiting may notice less overlap now that core provides base-level protection.
The default rate limits are set at 60 unauthenticated requests per minute per IP address for read endpoints, and 15 unauthenticated requests per minute for write endpoints. These values are configurable through the wp_config_rest_api_rate_limit filter, which allows developers to adjust them based on their site’s specific needs. For headless WordPress setups or sites with heavy API usage, testing these limits before deploying to production is essential.
It is important to note that the core rate limiting does not replace a Web Application Firewall (WAF) or dedicated rate limiting plugin. It serves as a baseline protection layer that catches low-effort automated attacks. Sophisticated attackers distributing requests across thousands of IP addresses will still bypass IP-based rate limiting. For comprehensive protection, combine core rate limiting with Trusti Security’s Brute Force Protection module, which uses behavioral analysis and progressive delays to stop distributed attacks.
Better Password Hashing
WordPress 6.8 updates its password hashing implementation to use bcrypt with a higher cost factor. The default cost factor has been increased from 10 to 12, making password hash computation approximately four times slower. This means brute force attacks against a stolen password hash database take significantly longer to execute.
Bcrypt is already an industry-standard password hashing algorithm, and increasing the cost factor keeps WordPress ahead of advancing hardware capabilities. The change is transparent to users: passwords still work the same way, and existing password hashes continue to be valid. New passwords and password changes will use the new, higher cost factor.
To put this in perspective: a cost factor of 10 means a single hash takes about 80 milliseconds on modern hardware. At cost factor 12, that same hash takes approximately 320 milliseconds. An attacker with a GPU cluster that can try 100,000 passwords per second against cost factor 10 hashes would be reduced to roughly 25,000 attempts per second against cost factor 12 hashes. Over a 24-hour period, that is the difference between testing 8.6 billion passwords versus 2.1 billion passwords. For sites with strong passwords, this makes offline cracking practically infeasible.
Site owners should also check whether their hosting environment supports bcrypt efficiently. Most modern PHP installations include native bcrypt support, but some older shared hosting configurations may run PHP versions where bcrypt is slower than expected. If you notice login page slowdowns after updating, contact your hosting provider to confirm they are running PHP 8.0 or later with the sodium extension enabled.
Database Query Hardening
Several database query paths have been hardened against SQL injection in 6.8. The changes primarily affect the wpdb class and meta query handling. These are proactive hardening measures rather than fixes for known vulnerabilities. The wpdb class now uses stricter type checking for query parameters, and meta queries undergo additional validation before execution.
For developers, this means custom queries that previously worked with loosely typed parameters may now require explicit type casting. Review your custom database queries, especially those using WP_Meta_Query or WP_Query with meta parameters, to ensure they pass properly typed values. The WordPress 6.8 developer notes provide specific guidance on affected functions.
The most significant change is in how wpdb::prepare() handles integer and float parameters. Previously, passing a string where an integer was expected would still work because PHP’s loose typing would convert it automatically. WordPress 6.8 now throws a _doing_it_wrong() notice when this occurs, and future versions may enforce strict typing. Developers should update their code to use %d for integers and %f for floats explicitly in all prepared statements.
For site owners who do not write custom queries, these changes are transparent. However, if you use plugins or themes that perform custom database operations, check with the plugin authors for 6.8 compatibility updates. Incompatible plugins may generate PHP warnings or, in rare cases, fail to execute queries correctly after the update.
Updated Third-Party Libraries
WordPress 6.8 includes updates to several third-party libraries that it bundles. These updates address known vulnerabilities and improve stability. The updated libraries include the jQuery and Underscore.js JavaScript libraries, the PHPMailer library used for email sending, and the SimplePie RSS parser. Each of these libraries has had security patches released since they were last updated in WordPress 6.7.
Outdated JavaScript libraries are a common finding in WordPress security audits. By updating bundled libraries, WordPress 6.8 closes several vectors for cross-site scripting (XSS) and other client-side attacks. Site owners should test their admin interface and frontend functionality after updating, as library version changes can occasionally cause plugin conflicts.
The jQuery update is particularly noteworthy. WordPress has been running jQuery 3.x for several core releases, but the 6.8 update patches multiple DOM manipulation vulnerabilities that affect how plugins and themes interact with the DOM. PHPMailer, which handles all outbound email from WordPress, received patches for remote code execution vectors that were disclosed in mid-2025. SimplePie, used for fetching and parsing external RSS feeds, was updated to fix XXE (XML External Entity) injection vulnerabilities that could allow attackers to read local files on the server.
New Security Headers in Core
WordPress 6.8 introduces better default security headers for the admin area. The login page now sets stricter Content-Type headers, and the admin dashboard includes additional cache-control directives. While not as comprehensive as what a dedicated security plugin provides, these core-level headers improve the baseline security posture of every WordPress site that upgrades.
For full security header support including Content Security Policy (CSP), HSTS, and custom Permissions Policy, site owners should continue using a security plugin like Trusti Security which provides comprehensive header management through a dashboard interface.
The new headers specifically include: X-Content-Type-Options: nosniff on all admin pages, preventing MIME type sniffing attacks; Cache-Control: no-store, no-cache, must-revalidate on login and admin pages to prevent sensitive data from being cached in the browser; and Referrer-Policy: same-origin on the login page to prevent the login URL from being leaked in referrer headers when users navigate away. These headers address OWASP Top 10 recommendations that WordPress core had not previously implemented.
Performance Implications
The increase in bcrypt cost factor from 10 to 12 has a measurable performance impact on login requests. Each login attempt now takes approximately 200-300 milliseconds of CPU time for password verification, compared to 50-100 milliseconds previously. This is negligible for individual users but significant for brute force attempts: an attacker who could try 10,000 passwords per second now can only try about 2,500. On shared hosting environments, the increased CPU usage per login may be noticeable during traffic spikes on the login page.
High-traffic login pages and SSO integrations should be tested after the update to ensure performance remains acceptable. Most sites will not notice any difference in normal operation. The performance trade-off is well worth the security improvement.
For sites experiencing login page slowdowns, consider implementing login page caching through a reverse proxy like Nginx or Varnish, but be careful not to cache POST requests or authenticated sessions. Another option is to use Trusti Security’s Brute Force Protection, which adds progressive delays after failed attempts and can reduce the number of legitimate password verifications by blocking attackers before they reach the login handler.
General WordPress Security Release Patterns
WordPress follows a predictable release pattern for security updates. Minor releases (6.8.1, 6.8.2) are typically security-only releases that patch vulnerabilities without adding features. Major releases (6.8, 6.9) include new features alongside security hardening. Understanding this pattern helps you plan your update schedule:
- Minor releases: Apply immediately. These fix known vulnerabilities and rarely cause compatibility issues.
- Major releases: Test on staging first. Wait 1-2 weeks for initial bug reports from the community, then deploy.
- Release candidates: Test on non-critical staging sites to identify compatibility issues before the stable release.
One notable change in WordPress 6.8 is the introduction of automatic background updates for security patches in plugin and theme dependencies. While core has supported automatic background updates since WordPress 3.7, 6.8 extends this capability to allow site owners to opt in to automatic updates for bundled library dependencies. This feature is disabled by default and must be explicitly enabled via the auto_update_bundled_libraries filter.
How to Prepare for Major Updates
Follow these steps before every major WordPress update to minimize risk:
- Back up your site: Full backup of files and database. Store the backup off-server.
- Create a staging environment: Clone your production site to a staging subdomain or subdirectory.
- Update on staging: Apply the WordPress update to your staging site first.
- Test thoroughly: Check every critical function: login, content editing, forms, e-commerce, API integrations.
- Run security scans: Use WPScan or your security plugin to verify no new vulnerabilities were introduced.
- Update plugins and themes: Ensure all plugins and themes are compatible with the new WordPress version.
- Deploy to production: If staging tests pass, update your production site during a low-traffic period.
After deploying, verify that your security plugin’s firewall rules are active and that all monitoring systems are functioning correctly. Check your server error logs for any PHP warnings or deprecation notices that may indicate compatibility issues. Monitor login attempt logs for the first 48 hours after deployment, as attackers often probe newly updated sites for regression vulnerabilities.
What Has Not Changed
WordPress 6.8 does not introduce built-in two-factor authentication Two-Factor Authentication guide, automated vulnerability patching, or file change detection. These features remain the domain of security plugins like Trusti Security, which provides 2FA, Core Integrity Scanner, Activity Logging, and Brute Force Protection alongside firewall and hardening modules. Site owners who rely solely on core WordPress security should evaluate whether a security plugin is necessary for their specific threat model, especially for e-commerce, membership, or high-traffic sites where the risk of targeted attacks is higher.
As always, update to WordPress 6.8 on a staging site first, test your plugins and theme for compatibility, then deploy to production. Major version updates should always be tested before going live. Trusti Security helps you monitor the update process and alerts you to any files that change unexpectedly.
Summary of Action Items for WordPress 6.8
Here is a concise checklist of what you should do to make the most of WordPress 6.8’s security improvements:
- Update to WordPress 6.8 after testing on staging
- Regenerate your salts using wp config shuffle-salts or the WordPress salt API
- Review custom database queries for strict type compliance
- Test REST API integrations against the new rate limits
- Verify all plugins and themes are compatible with updated libraries (jQuery, PHPMailer, SimplePie)
- Check login page performance after the bcrypt cost factor increase
- Update your security plugin to the latest version for compatibility
- Review Trusti Security’s hardening checklist for additional protections not covered by core
- Monitor error logs for 48 hours after deployment
- Educate your team about the new security headers and their benefits