Short answer: a PHP vulnerability being in the news does not mean your site was hacked, and running an unpatched PHP version raises your risk without proving anything. If you see real warning signs (unknown admin users, strange PHP files in uploads, spam pages, redirects, a host suspension notice), treat the site as compromised: take it offline, keep a copy for evidence, rotate every credential and key, patch PHP, reinstall clean code, and restore from a backup taken before the incident. This applies to any compromise, whatever the cause.
Key takeaways
- Being on an unpatched PHP version is a risk factor, not evidence of compromise. Look for actual signs before assuming the worst.
- Check safely first: your host's malware scanner,
wp core verify-checksums,wp plugin verify-checksums --all, the admin user list, and your access logs. - Cleanup order matters: contain, preserve evidence, rotate all secrets, patch PHP, reinstall core and plugins from clean sources, restore from a pre-incident backup, then re-scan.
- Do not just delete one suspicious file and move on. Backdoors usually come in several copies, and stolen passwords let attackers walk back in.
- If customer data, payments or a business-critical site are involved, bring in a professional early.
Why this question is trending right now
On 21 October 2026, the PHP project published a security advisory titled "Critical remote code execution vulnerabilities, update now". According to php.net, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. Site owners naturally ask the follow-up question: "Could someone already be inside my WordPress site?"
The honest answer is that it depends on evidence, not on headlines. As of 2026-10-25, some third-party outlets have reported early attack attempts, but details change quickly, so check the current status from the PHP project and your host rather than relying on this article. A WordPress site on an unpatched PHP build is easier to attack. It is not automatically compromised.
The checklist below works for any WordPress or PHP site and for any cause: an old plugin, a stolen password, a vulnerable theme, or a PHP flaw. If you also need to understand the patching side, ask your host which PHP build they are running and whether it includes the fixes. On shared hosting you generally cannot patch PHP yourself, because the host builds the packages. Some distributions also backport fixes without changing the version string, so a version number alone can mislead. Check your host's security bulletin.
Signs your WordPress site may be compromised
One sign on its own can have an innocent explanation. Several together, or any of the first three below, deserve immediate attention.
| Sign | What it looks like | How serious |
|---|---|---|
| Unknown administrator users | An admin account you or your team did not create, often with a generic name or a random email | High |
| Unfamiliar PHP files in uploads | A .php file inside wp-content/uploads, where only images and documents should live | High |
| Modified core files | Files in wp-admin or wp-includes that differ from the official release | High |
| Redirects | Visitors, often only those arriving from Google or on mobile, land on unrelated or scam sites | High |
| Spam pages | Search results show pharmacy, casino or foreign-language pages under your domain that you never published | High |
| Odd scheduled tasks | Cron events with random hook names, or events that re-create a deleted file | Medium to high |
| Host suspension or abuse notice | Your host disables the site or reports malware, outbound spam or a phishing page | High |
| Traffic or CPU spikes | Sudden resource use, bandwidth spikes or an unexpected mail queue with no marketing activity to explain it | Medium |
| Browser or search warnings | "Deceptive site ahead" or a "This site may be hacked" label in results | High |
Not every symptom means hacking. A broken plugin update can cause errors, and a viral post can cause a traffic spike. That is why the next section is about confirming with tools rather than guessing.
How to check safely before you change anything
The goal here is to gather evidence without making things worse. Work read-only where you can, and avoid logging into wp-admin from a computer you do not trust, since an attacker may have planted something that captures credentials.
1. Run your host's malware scanner
Many hosts include a scanner in the control panel or can run one on request. It is a quick first pass. A clean result is useful but not a guarantee, because scanners rely on known signatures and miss new or customized backdoors. Also ask your host whether their logs show anything unusual for your account.
2. Verify WordPress core files with WP-CLI
If you have SSH access and WP-CLI installed, compare your files against the official checksums published by WordPress.org. Run these from the WordPress root:
wp core verify-checksums
wp core verify-checksums --include-rootPer the WP-CLI documentation, the first command checks core files against the official release and prints "Success: WordPress installation verifies against checksums" when they match. The --include-root option also checks the root directory and warns about items that do not belong to WordPress, which is a good way to spot stray files. If your site uses a non-English locale, the docs note you can pass --locale=<locale> to match, and you can use --version=<version> if the check cannot detect it. Expect harmless warnings for files such as readme.html in some setups. Treat changes to anything in wp-admin or wp-includes as serious.
3. Verify plugins
wp plugin verify-checksums --allThis compares installed plugins against the checksums WordPress.org holds. It only works for plugins hosted in the official directory. Premium and custom plugins will not verify this way, so you will need to compare them against a fresh download from the vendor. Adding --strict treats even minor changes such as readme.txt edits as failures, which is noisier but sometimes useful.
4. List administrators and scheduled events
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run_gmt,recurrenceLook for admin accounts nobody recognizes, especially ones registered recently. In the cron list, look for hook names that are random strings or that do not belong to any plugin you use.
5. Search for PHP files where they should not be
On a Linux host, this lists PHP files inside the uploads folder:
find wp-content/uploads -type f -name "*.php"A few legitimate plugins place an index.php file containing only a comment, such as "Silence is golden". Anything else is suspicious. Also look at recently modified files:
find . -type f -name "*.php" -mtime -14Do not open suspicious files in a browser, which could execute them. Read them in a text editor or with a command such as less.
6. Compare against a clean copy
Download the same WordPress version and the same plugin and theme versions from their official sources into a separate folder, then compare them with a tool such as diff -r. Anything that exists only on your live site, or differs in content, needs an explanation. Do this on a copy of the site, not on the live server.
7. Check access logs for suspicious POST requests
Your host's raw access logs show who requested what. Patterns worth a closer look include:
- POST requests to files in
wp-content/uploadsor to PHP files you do not recognize. - Repeated POSTs to
wp-login.phporxmlrpc.phpfrom the same addresses, which suggests password guessing. - Requests with very long or encoded parameters to a single script.
- A sudden burst of requests to a file that was created just before it.
Note the dates and times. They help you decide how far back to go when choosing a clean backup. If the logs are rotated away after a few days, ask your host whether older copies exist.
Not sure what is wrong? Get a diagnosis first.
Our certified tech can connect remotely, check your software, drivers and backups, and tell you honestly whether the problem needs a hands-on repair.
Cleanup order: what to do, step by step
The sequence matters. If you reinstall files before changing passwords, or restore before patching, the attacker can simply return.
- Contain. Put the site in maintenance mode or take it offline. With WP-CLI,
wp maintenance-mode activatedoes this, andwp maintenance-mode statusconfirms it. If the site is sending spam or serving malware, ask your host to suspend outbound mail or the site itself. - Preserve evidence. Before deleting anything, make a full copy of the files and a database export, and save the access and error logs. Store it somewhere offline. You may need it to find the entry point, for an insurer, or for a professional.
- Rotate every credential. Change the hosting account, SFTP/SSH, database, email and WordPress admin passwords, plus any API keys stored in the site. Use a password manager and unique passwords. Remove unknown admin users and unused accounts. See our business password manager guide if you do not have one.
- Replace the authentication keys and salts. Running
wp config shuffle-saltsrefreshes the salts inwp-config.php. This invalidates existing login sessions, so anyone holding a stolen cookie is logged out. Also change the database password and update it inwp-config.php. - Patch PHP first. Ask your host for the patched PHP build, or select a supported branch in your control panel. As of 2026-10-25, php.net lists the fixed releases as 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and says PHP 8.1 and older get no project releases. Patching comes before restoring, otherwise you restore onto the same weakness.
- Reinstall WordPress core from a clean source. From the WordPress root,
wp core download --force --skip-contentoverwrites core files with fresh ones and leaves yourwp-contentfolder alone. Add--version=<version>to pin a specific release. Then delete any stray files that--include-rootflagged. - Reinstall plugins and themes from clean sources. Delete and reinstall each one from the official directory or the vendor, rather than trusting the existing copies. Remove anything you do not use. Abandoned plugins are a common way in.
- Restore from a known-clean backup. Choose a backup taken before the earliest sign of trouble in your logs, not just "the latest one". Restore content, then re-check it with the commands above. If you cannot establish a clean date, rebuild: fresh WordPress, clean plugins, and carefully exported posts and media.
- Clean the database. Check for injected scripts in posts and options, unknown users, and odd entries in
wp_options. This is where a professional often earns their fee. - Re-scan and monitor. Run the checksum commands and your host scanner again, then watch logs for a few weeks. Bring the site back, and ask Google Search Console to review it if you received a security warning.
For general guidance on protecting Windows machines and accounts that touch the site, see Windows support and our article on removing viruses remotely. If your own computer might be the source of the stolen password, read warning signs your computer is hacked.
What not to do
- Do not just delete the one file the scanner found. Backdoors are commonly duplicated, and the original entry point is still open.
- Do not skip password changes because "the site is clean now". Stolen credentials survive a cleanup.
- Do not restore the newest backup blindly. It may already contain the infection.
- Do not rely on a plugin alone. A security plugin or a WAF can help reduce risk, but it is not a substitute for patching PHP or removing the compromise.
- Do not pay a stranger who contacts you claiming they found a problem with your site.
- Do not wipe everything before saving evidence. You lose the chance to learn how it happened.
When to call a professional
Get help if the site handles payments or customer data, if you find unknown admin users and cannot explain them, if the infection returns after cleanup, if your host has suspended the account, or if you simply do not have time to do this carefully. Also consider it if you have no clean backup and cannot rebuild. IT Cares offers remote repair and support from Canada, and our cybersecurity page explains how we approach incident work. We cannot promise any site will never be attacked, but a careful cleanup order sharply reduces repeat infections.
FAQ
Does an unpatched PHP version mean my WordPress site is hacked?
No. It means the server is easier to attack. Whether it was attacked is a question for logs, file checks and scanners, not for the version number alone.
Is this a WordPress vulnerability?
No. The two CVEs published by php.net are in PHP itself. Updating WordPress and plugins does not fix PHP, though you should keep them updated anyway.
Can I patch PHP myself on shared hosting?
Usually not. The host builds the packages. You can choose the PHP branch in the control panel and ask the host to confirm the patched build is available. Some hosts backport fixes without changing the version string, so check their bulletin.
What does wp core verify-checksums actually tell me?
It compares your core files with the official checksums for your WordPress version. It shows modified or extra core files. It does not check plugins, themes, uploads or the database.
Should I restore from my latest backup?
Only if you are confident it predates the compromise. Use your logs to find the earliest suspicious activity and pick a backup before that date. Then patch and rotate credentials before going live.
Do I need to change the salts and keys?
Yes, after any suspected compromise. Refreshing them logs everyone out and invalidates stolen session cookies. It does not replace changing passwords.
How do I know the cleanup worked?
Checksums verify, no unknown admins or PHP files in uploads, the host scanner is clean, no new odd cron events, and logs stay quiet for several weeks. No method gives a perfect guarantee.
Is a WAF enough protection?
A web application firewall may help block some attacks, but it is not a fix for a vulnerable PHP build. Patch first, and treat a WAF as an extra layer.