Fix unslashed REMOTE_ADDR warning in email provider

[masteradhoc]

What?

This fixes the remaining Plugin Check warning outside of the intentionally skipped includes files.

The email provider now applies wp_unslash() to $_SERVER['REMOTE_ADDR'] before the existing sanitization step, matching WordPress input-handling expectations while preserving the current output filtering.

Validation: npm run lint:php -- providers/class-two-factor-email.php passes.

Fixes #

Why?

Pass the Plugin Check Checks

How?

Changelog Entry

Fixed - Unslash REMOTE_ADDR before sanitizing it in the email provider.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: masteradhoc <masteradhoc@git.wordpress.org>
Co-authored-by: georgestephanis <georgestephanis@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Copilot]

🟢 Approval recommended

The functional change is minimal and aligns with WordPress sanitization expectations; only a minor inline-comment grammar nit was found.

Pull request overview

This PR updates the Two-Factor Email provider to unslash $_SERVER['REMOTE_ADDR'] before sanitizing it, resolving a remaining Plugin Check warning (outside the intentionally skipped includes/ files) while keeping the existing character allowlist filtering.

Changes:

• Apply wp_unslash() to $_SERVER['REMOTE_ADDR'] before the existing preg_replace() sanitization in the Email provider.

File summaries

File	Description
providers/class-two-factor-email.php	Unslashes REMOTE_ADDR prior to sanitization to align with WordPress input-handling expectations and address Plugin Check warnings.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[georgestephanis]

The wp_unslash() is correct — wp_magic_quotes() slashes $_SERVER alongside $_GET/$_POST/$_COOKIE, so this isn't a false positive from the sniff.

One suggestion inline though: switching the regex for filter_var( ..., FILTER_VALIDATE_IP ) clears the same warning and lets the WordPress.Security.ValidatedSanitizedInput.InputNotSanitized ignore go away, because WPCS recognises filter_var with a validate filter as sanitisation but not a hand-rolled regex. I checked both forms through PHPCS to be sure:

Form	InputNotSanitized
preg_replace( '/[^0-9a-fA-F:., ]/', '', wp_unslash( ... ) )	still fires
filter_var( wp_unslash( ... ), FILTER_VALIDATE_IP )	clean

It's also a stronger check. The character class is a whitelist rather than validation, so things that aren't IPs survive it:

Input	preg_replace	filter_var
1.2.3.4	1.2.3.4	1.2.3.4
..::,,	..::,,	false
<script>1.2.3.4</script>	cf1.2.3.4cf	false

That last one is the one I'd worry about — c and f are inside the hex range, so the leftovers land in the email body looking vaguely like a real address.

And it would match what #973 just put into class-two-factor-core.php for the same value, so the plugin ends up with one idiom for reading REMOTE_ADDR instead of two.

Trade-off worth naming: a proxy-rewritten REMOTE_ADDR carrying a comma-separated list (1.2.3.4, 5.6.7.8) currently passes through and would become null. The docblock does anticipate proxies, so this is a real behaviour change — I'd argue it's the right one, since a list isn't an address and today it gets printed verbatim, but it's your call and it's a reasonable reason to prefer the minimal fix.

---

Two pre-existing things I noticed while reading, both out of scope here and neither a reason to hold this up:

• $remote_ip is interpolated unconditionally at line ~303, so a null renders as "A user from IP address  has successfully authenticated" — dangling sentence, double space. Already reachable when REMOTE_ADDR is empty; filter_var would make it reachable more often, so it may be worth guarding that whole sentence if you take the suggestion.
• That same string says "has successfully authenticated", but the email goes out at the password stage, before the second factor is entered. Nobody has authenticated at that point. Happy to open a separate issue for it if it's not already tracked.

[Copilot]

🟡 Changes recommended

The new FILTER_VALIDATE_IP logic changes behavior beyond the stated “unslash before sanitizing” goal and can drop values that were previously preserved.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

[georgestephanis]

Yeah I think this is good