Christmas-Eve security sweep, quiet release, loud impact
A pure security and sanitization release. No new features, no UI changes. Every input path tightened, every escape added, every nonce verified.
- Hardened input sanitization across every AJAX endpoint
- Tightened escaping on every output path that renders entry data
- Nonce verification ordering audited and corrected
- No breaking changes, drop-in replacement for 4.1.5
Some releases are loud. This one is the opposite.
What’s in 4.1.6#
A full pass through:
- Every
$_POST,$_GET,$_REQUESTaccess is now wrapped inwp_unslash()before sanitization - Every AJAX handler verifies the nonce before doing any work, and sanitizes the nonce input itself first
- Every field value rendered to HTML uses the right escaping function for its context (
esc_html,esc_attr,esc_url,wp_kses_post) - Every SQL query that uses dynamic values uses
$wpdb->prepare()with the right placeholder
None of these were known vulnerabilities. They were defensive hardening. Most existed correctly already; a handful had the right call in the right order but with a subtly wrong sequence (sanitize-before-verify vs verify-before-sanitize).
Why ship at Christmas?#
Because security work is finished when it’s finished. Sitting on it for a calendar slot is how vulnerabilities turn into exploits. The change set is small and reversible; if your site breaks (it won’t), rolling back is a one-click WordPress core operation.
What’s next#
The 4.2 line will introduce conditional formatting (heat-maps and threshold colours), but the foundation laid here, strict input sanitization, is what makes safe rendering of user-controlled HTML possible. Without 4.1.6, conditional formatting would have to render through wp_kses with a tighter allowlist. With 4.1.6, we can trust the data layer.