In short: A website malware scanner mainly finds known patterns in files or in the delivered page. New and obfuscated code, backdoors in the database, foreign accounts, cron jobs and SSH keys often stay invisible. “Nothing found” therefore does not mean “clean”. A check becomes reliable only through the combination of scanner, comparison with the original, review of database and system, and behavior monitoring.
The deceptive calm after the green checkmark
After PHP2Shell, many operators did the obvious thing: they ran a scanner. An online service checks the home page, a security plugin searches the web directory, and the result is green. That seems to answer the question of whether anything happened before the patch.
The problem lies in the principle. Most scanners compare content with patterns of known malware. For the vulnerabilities CVE-2026-109618 and CVE-2026-109619, however, there are no published, confirmed indicators of compromise; detection relies on behavioral analysis. A scanner cannot look for traces that nobody knows. At best it finds general malware that was loaded after a break-in, provided it follows known patterns.
That does not make scanners worthless. It only means that their result has to be put in the right perspective. Which signs count beyond scanners is described in Am I already compromised?.
Website malware scanners: three designs
| Design | What it sees | What it doesn't see |
|---|---|---|
| External scanner (online service) | delivered pages, included scripts, redirects, blocklists | files, database, accounts, anything delivered only under conditions |
| Scanner in the CMS (plugin or extension) | files in the web directory, partly database content, comparison with core files | system level, cron jobs, SSH; runs in the possibly compromised system |
| Scanner on the server (signature-based) | all readable files, also outside the web directory | unknown and obfuscated patterns, database, accounts, behavior |
External scanners are useful for spotting visible consequences, such as redirects or entries on blocklists. But many hacks deliver their spam or redirect content only to certain visitors, for example search engines or mobile devices. The scanner then sees a clean page.
Scanners in the CMS have more insight, but a fundamental problem: they run in the same system they are supposed to check. Code with sufficient rights can influence their results, hide files or disable the scanner. Server scanners work outside the application but remain dependent on patterns.
What scanners fundamentally miss
Regardless of design, there are areas that a file or page scanner can hardly cover:
- New or individually obfuscated code: Any variant that looks different from known patterns slips through.
- The database: Scripts in content, changed settings, triggers and foreign accounts. More on this under Checking the database for injected code.
- Access: additional admin accounts, SSH keys, database users, accounts in the hosting panel.
- System services and cron jobs: Mechanisms that regularly reload malicious code.
- Inconspicuous changes to legitimate files: a single extra line in a core file that looks harmless.
- Data that has left: Whether credentials or customer data were copied is shown by no scanner.
What creates certainty instead
More security comes from combining kinds of checks that work differently:
- Comparison with the original: It finds every change to known files, regardless of patterns. The procedure is described in Comparing CMS core files with the original.
- Targeted search for anomalies: PHP files in upload folders, recently changed files, obfuscated code, executable files in temporary folders.
- Review of accounts and system services: Compare users, keys, cron jobs and services with the known target state.
- Log analysis: Requests for unknown files, clusters of errors, unusual logins.
- Behavior monitoring: Web server processes that start a shell, unexpected outgoing connections, new files in sensitive folders.
The last category is the most important when there are no known traces. It does not ask what malicious code looks like but what it does. A web server process that suddenly starts a shell stands out, no matter how the triggering code is obfuscated.
Run a server scanner from a clean system over a read-only copy instead of on the suspicious server itself. That way injected code cannot influence the result.
How to use scanners sensibly
Scanners have their place, as one tool among several. An external scanner is suitable as a regular check of visible consequences, for example weekly. A scanner in the CMS reports known malware and modified core files in everyday operation. A server scanner complements the search for known patterns across the whole file system.
What matters is how you handle the result. A finding is a clear item to investigate and justifies a full examination, because rarely only one file is affected. An empty result, by contrast, is only a statement about the patterns checked. In your documentation, note which scanner ran when and with which version, and do not write “system clean” but “no known patterns found”.
For management this means: a green checkmark does not replace a review by someone who looks at files, database, accounts and behavior together. After an incident with possible code execution, as conceivable with PHP2Shell, this review should take place.
If a scanner does report a finding, quick but orderly action is called for. Do not delete the reported file immediately using the scanner function. First secure the file and logs so that it can be clarified how it got onto the server. How a complete cleanup works is described in the service Having malware and webshells removed.
How does PHP SOS help?
- We combine scanners with comparison against the original, targeted search and analysis of accounts, services and logs.
- We examine suspicious systems via secured copies so that results are not influenced by the compromised system.
- We honestly label every result as documented, probable or unknown.
- With security monitoring for web servers we continuously monitor the behavior of your servers, not just known patterns.
Frequently asked questions
Is my website clean if the malware scanner finds nothing?
Not necessarily. Scanners mainly find known patterns. New or well-obfuscated code, backdoors in the database, foreign accounts, cron jobs and SSH keys often remain undiscovered. An empty result is one building block, not an acquittal.
What is the difference between an external scanner and a plugin scanner?
An external scanner calls up the website from outside and sees only what is delivered. A plugin scanner runs inside the CMS and can read files, but runs in the same system that may be compromised. Both have their own blind spots.
Are there scanner signatures for PHP2Shell?
There are no published, confirmed indicators of compromise for PHP2Shell. Scanners therefore cannot search specifically for verified PHP2Shell traces. Detection relies on behavioral analysis and on looking for general signs of compromise.
Which scanner is the best?
The question is misleading. More important than any particular product is the combination of different kinds of checks: comparison with the original, search in files and database, review of accounts and system services, and monitoring of behavior.