Understanding Your Results

Understanding your results

Every scan ends with one of these results:

Result	What it means	What to do
🟢 No signs of PHP2Shell or wp2shell	PHP and WordPress are patched and no traces of an attack were found.	Nothing. Keep weekly scans on.
🟡 Needs review	A few things to confirm, none alarming on their own — e.g. "PHP looks old but may be an OS package — ask your host".	Read them; Ignore what you've confirmed.
🟠 Vulnerable — PHP needs updating	No signs of a break-in, but your server's PHP can be attacked through PHP2Shell.	Send your host the ready-made message.
🟠 Vulnerable — update WordPress	No signs of a break-in, but your WordPress can be attacked through wp2shell.	Click Go to WordPress updates.
🔴 Suspicious	Something needs a closer look today — e.g. an unknown admin, PHP in your uploads folder, PHP2Shell traces in the error log.	Check every High finding.
🚨 Compromised	Strong evidence of an attack — e.g. a known webshell.	Follow If your site is compromised.

How the result is decided:

flowchart TD
    S["Scan finishes"] --> X["Leave out anything<br/>you marked Ignore"]
    X --> C{"Any Critical sign<br/>of an attack?"}
    C -- Yes --> R1["🚨 Compromised"]
    C -- No --> H{"Any High sign<br/>of an attack?"}
    H -- Yes --> R2["🔴 Suspicious"]
    H -- No --> V{"Is PHP or WordPress<br/>a vulnerable version?"}
    V -- Yes --> R3["🟠 Vulnerable"]
    V -- No --> M{"Anything Medium?"}
    M -- Yes --> R4["🟡 Needs review"]
    M -- No --> R5["🟢 No signs"]

Loading

An old PHP or WordPress version on its own is never reported as Compromised — being vulnerable isn't the same as being hacked.

Each finding has a severity:

Severity	Meaning	Examples
Critical	Almost certainly malicious (or PHP that will never be fixed)	A known webshell; a wp2shell_… plugin; a modified file of this scanner; PHP 7.3
High	Very likely bad — check today	Unpatched PHP; recent PHP in uploads/; an unknown admin; a burst of PHP2Shell errors in the log
Medium	Possibly bad, often innocent	Old-looking PHP from an OS package; a must-use plugin changed recently; a role with admin powers
Low	Usually normal, listed so you can confirm	Plugins or themes updated since July 17; wp-config.php edited
Info	Just information	"PHP 8.4.27 includes the PHP2Shell fix"; which temporary protections are on

Getting your host to update PHP

Most site owners can't update PHP themselves. When PHP needs attention, the scanner shows a box called "Your host needs to update PHP" with a ready-made support message that already includes your site address, PHP version and the CVE numbers. Click Copy message and paste it into a support ticket or live chat.

sequenceDiagram
    actor You
    participant S as Scanner
    participant H as Your host
    S->>You: "PHP 8.3.10 is vulnerable to PHP2Shell"
    You->>S: Copy message
    You->>H: Support ticket / live chat
    H->>H: Update PHP to 8.3.36 (or confirm the OS package is patched)
    H-->>You: Done
    You->>S: Scan again
    S->>You: 🟢 PHP includes the PHP2Shell fix

Loading

Can I do it myself? On many hosts, yes: look in your hosting control panel for "PHP version", "Select PHP Version" or "MultiPHP Manager" (cPanel) and choose 8.2 or newer. Test your site afterwards — very old plugins and themes may not work on newer PHP.

Temporary protections your host can set in php.ini until PHP is updated (the scanner shows which ones are on):

Setting	Protects against	Note
session.upload_progress.enabled = 0	CVE-2026-109619	Rarely needed by WordPress sites
memory_limit = -1	CVE-2026-109618	Must be enforced so sites can't override it (php_admin_value[memory_limit] = -1 in the PHP-FPM pool)
fatal_error_backtraces = 0	CVE-2026-109619, PHP 8.5 only
Low post_max_size and max_input_nesting_level	CVE-2026-109618	Limits how big and deep a form submission can be
pm.max_requests = 1 (PHP-FPM)	Both	Each worker handles one request, so no leftover state is reused; costs performance
No RLIMIT_AS / RLIMIT_DATA limits on PHP	CVE-2026-109618	Operating-system memory limits can trigger the bug too

These reduce the risk; they don't remove it — security firms have shown attacks working with them in place. PHP must be restarted after changing them.

Ignoring things that are yours

If a finding is something you know about — your own admin account, your host's must-use plugin, a PHP version your host confirmed is patched — click Ignore next to it.

• Ignored findings no longer count toward the result and never trigger an email.
• They're kept in an "ignored findings" list at the bottom, where Restore brings them back.
• A finding stays ignored when only a date or count in its text changes (e.g. your host updates their must-use plugin again).
• If an ignored file changes, it's flagged again — so an attacker can't hide inside something you once approved.
• The ignore list is signed with your site's secret keys from wp-config.php, so an attacker who only got into the database can't quietly add their own files to it.
• From WP-CLI: wp jat-shell ignore <id> and wp jat-shell ignore <id> --undo.

Caution

Only ignore things you're sure about. If you're unsure, ask your developer or host — or open an issue describing what was flagged (don't post passwords or full file contents).