Key details

  1. WordPress developer note dated October 9, 2026; committed changeset 64240 dated October 8.
  2. wpdb::set_sql_mode() removes NO_BACKSLASH_ESCAPES from the WordPress session, not global server configuration.
  3. The change targets WordPress 7.2, with Beta 1 scheduled October 20, 2026.
  4. Plugins opening separate database connections must handle their own SQL modes.
  5. Opt-out requires incompatible_sql_modes in an early db.php drop-in; normal plugins load too late.
  6. This is not a universal SQL injection remediation or a newly assigned CVE.

What builders should take away

  1. Test WordPress plugins that use PDO/mysqli directly, custom database drop-ins, raw SQL builders or manual sql_mode changes.
  2. Compare @@SESSION.sql_mode on WordPress's connection with @@GLOBAL.sql_mode on the database server.
  3. Test apostrophes, backslashes, percent signs and underscores in form inputs and search queries on staging.
  4. Continue using $wpdb->prepare() for dynamic values; session-mode hardening does not make string concatenation safe.
  5. Only override the incompatible mode with a db.php drop-in when you understand the risk.

What changed

An October 9, 2026 WordPress Core developer note confirms that WordPress 7.2 adds NO_BACKSLASH_ESCAPES to wpdb's list of incompatible MySQL/MariaDB SQL modes. Changeset 64240, committed October 8, updates wpdb::set_sql_mode() and its regression test. On connecting, WordPress removes that mode from its own session so backslash-based SQL escaping works as intended. This does not change the server's global mode or connections opened independently by plugins or scripts. WordPress 7.2 Beta 1 is scheduled for October 20 and final release for December 8.

Why it matters

NO_BACKSLASH_ESCAPES makes MySQL treat backslashes literally. WordPress's database layer expects them to escape special characters, so some host configurations can produce wrong data, broken searches or SQL errors only for particular input. This removes a subtle mismatch on the main WordPress connection but cannot fix custom clients, drop-ins or plugins that change session SQL modes. It is a compatibility correction, not a blanket security cure.

Only the WordPress database session changes

WordPress 7.2 will remove NO_BACKSLASH_ESCAPES from @@SESSION.sql_mode when wpdb connects, without changing @@GLOBAL.sql_mode. The change matters for unusual server configurations; standard hosts and standard wpdb usage should usually be unaffected. It is committed in trunk, not yet released as stable.

Custom SQL layers remain responsible for their own escaping

Code opening separate PDO or mysqli connections, implementing db.php drop-ins or setting sql_mode can still encounter incompatible escaping. Independent MySQL 8.0.46 examples demonstrate that escaped apostrophes and LIKE wildcard queries behave differently with the mode enabled. These are compatibility and potential security concerns for badly escaped raw SQL, not proof of a new general WordPress CVE.

Opt-out must run before ordinary plugins

The official developer note documents the incompatible_sql_modes filter for sites that need the mode. It must be added to an early db.php drop-in because normal and must-use plugins load after the connection is established. WordPress warns that retaining the mode may cause core to work incorrectly.

The October 20 beta is the first major migration checkpoint

WordPress 7.2 Beta 1 is scheduled for October 20, Release Candidate 1 for November 17, and final release for December 8, 2026. Test staging configurations and verify the session mode, rather than assuming the server's global SQL settings match the application's connection.

What to watch next

  • Whether the change is included in the October 20 WordPress 7.2 beta and subsequent RC.
  • Plugin and hosting compatibility reports for custom database connections.
  • New diagnostics or migration guidance from WordPress Core.

Still unclear

  • No reliable count of WordPress sites running NO_BACKSLASH_ESCAPES globally is available.
  • Stable release has not shipped as of October 19.
  • Independent MySQL behaviour tests do not constitute an audit of affected plugins.

Sources

Direct reading behind this dossier.

4 sources
WordPress changeset 64240
WordPress Core Trac primary code

Committed implementation and test, fixes ticket #66185.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment