WordPress 6.8: what the move to bcrypt really changes for security

Why this still matters in 2026

WordPress 6.8 shipped in April 2025. Before the release, the Core team announced an important security change: user passwords would stop relying on the older portable phpass mechanism and move to bcrypt via PHP's native password APIs.

That still matters in 2026 for two reasons. First, many production sites are still running on the 6.8 branch. Second, part of the WordPress ecosystem had built custom logic around legacy hash formats or old assumptions about how password handling worked internally.

What changed exactly

Core updated wp_hash_password() and wp_check_password() to use password_hash() and password_verify() with bcrypt, while adding SHA-384 pre-hashing to avoid bcrypt's 72-byte input limit.

In practice, the new default prefix for user-password hashes becomes `$wp$2y$`.

In parallel, WordPress introduced wp_fast_hash() and wp_verify_fast_hash() for several randomly generated application secrets. According to the official Core dev note, application passwords, password reset keys, personal-data request keys, and the recovery mode key move to BLAKE2b via Sodium.

What does not change

The reassuring part is also explicit in the official documentation: legacy phpass hashes remain supported. There is no need for a mass password reset just because a site upgrades.

That means:

Another important nuance: the official note also says that post passwords still use phpass for now. So this is a meaningful improvement, but not a blanket change across every password-related mechanism in WordPress.

What developers should verify

The official guidance is clear: code that simply calls `wp_hash_password()` and `wp_check_password()` should continue to work and does not need to change.

The risky cases are different.

1. Code that inspects hash prefixes directly

If a plugin, mu-plugin, or custom snippet assumes that WordPress password hashes always start with `$P$`, that assumption is now unsafe. This is exactly the kind of brittle logic that breaks quietly after an upgrade.

2. Homegrown authentication bridges

Some teams added SSO bridges, migration scripts, external-user synchronization, or manual checks around the wp_users table. If that code manipulates hashes directly instead of using WordPress APIs, it deserves a review.

3. Plugins that replace native hashing logic

Core kept compatibility with the $wp_hasher global and alternative mechanisms. That is useful, but it also means sites with historical overrides should verify that they are not creating contradictory or outdated behavior.

4. Internal support procedures

Some teams were used to visually checking a hash format, comparing prefixes, or reasoning from the old portable-hash behavior. Those habits need to be updated.

What this does not fix

This point should not be oversold.

Moving to bcrypt improves how authentication secrets are stored. It does not fix the rest of a typical WordPress attack surface:

In other words, better password hashing is good security engineering. It is not a substitute for access review, plugin hygiene, secret management, or real application-layer testing.

Our view

WordPress 6.8 is a meaningful step in the right direction. The move to bcrypt and the introduction of BLAKE2b show that Core is still modernizing its security primitives.

But for a production site, the real question remains: what have you exposed around the CMS?

If your WordPress instance handles client access, private media, regulated forms, exports, or custom business workflows, your main risk is rarely just the password hash. The bigger risk often sits in plugins, REST routes, storage, webhooks, roles, and secrets that are visible from the outside.

That is exactly what a external review can test quickly: not whether WordPress has done its part, but whether your implementation has done its own.