# Mass Scans for Unpatched PHP: How Automated Attacks Work

> Automated attacks on web servers: how mass scans for unpatched PHP work, why small companies are targets too and what you can do to protect yourself.

Source: https://phpsos.de/en/blog/automatisierte-massenscans/  
As of: 25/10/2026  
Provider: PHP SOS, PHP emergency help and server security. Immediate help via WhatsApp: https://wa.me/491736494914?text=Hello%20PHP%20SOS%2C%20we%20need%20help%20with%20our%20PHP%20server.%20Company%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**In short:** Automated attacks on web servers come in waves: programs search the internet for reachable servers, classify them by external characteristics and try known vulnerabilities such as PHP2Shell in bulk. The size of the company plays no role in this. Protection comes from patched PHP, a small attack surface and monitoring that quickly notices successful hits.

## The trigger: "Who would be interested in our website?"

We hear this question often after PHP2Shell, especially from smaller companies. The honest answer: probably nobody personally. But with vulnerabilities of this kind, that is not necessary either. The attacks are carried out by programs that do not look for names but for opportunities.

The BSI (German Federal Office for Information Security) expected rapid, large-scale exploitation of PHP2Shell. Cloudflare reported attack attempts and that attackers changed their patterns to bypass protection rules. Both fit what regularly happens with critical vulnerabilities in widely used software.

## How automated attacks on web servers work

Automated campaigns usually follow a similar pattern. The following overview describes the phases in general terms, without attack details:

| Phase | What happens | What helps against it |
|---|---|---|
| Searching | programs check large address ranges or public directories such as certificate logs for reachable web servers | few publicly reachable systems, inventory of all addresses |
| Classifying | responses are evaluated: web server, PHP version, CMS, typical paths | hide version information, remove unnecessary files |
| Trying | known vulnerabilities are tested in bulk, often without prior classification | current PHP, restart, WAF as an additional layer |
| Gaining a foothold | on success, a back door is planted, such as a webshell or a cron job | restricted write permissions, no PHP execution in upload folders |
| Exploiting | the server is used, for example for spam, crypto mining, redirects or data theft | monitoring of processes, files and outgoing connections |

The third row is important. Many campaigns do not even bother to classify servers precisely beforehand. They simply try everything that is reachable. That is why inconspicuousness alone does not protect.

### Why attacks come in waves

Automated campaigns rarely run once and then never again. A pattern in waves is typical. The first wave follows shortly after a vulnerability becomes known, often still with immature tools. Further waves come when attackers improve their tools or adapt them to protection rules. With PHP2Shell, Cloudflare observed exactly that: changed attack patterns to bypass the rules.

For you this means: a server that has come through the first wave unscathed is not permanently safe as long as it is unpatched. And a newly set-up server becomes a target from the moment it is reachable. Anyone who has a new TLS certificate issued, for example, makes the name visible in public certificate logs, which scanners also evaluate. A new system should therefore only go online once it has already been updated.

## Why small companies are affected just the same

For automated attacks, it is not the value of an individual target that counts but the quantity. A small business's server offers computing power, a domain with a good reputation, a mail-sending capability and sometimes customer data. For attackers, that is enough.

In addition, smaller companies often have no in-house IT that installs updates immediately. Their servers stay vulnerable longer and therefore appear more often in the scanners' result lists. Anyone who patches first drops out of these lists.

Another point is the supply chain. Many small websites sit on servers of agencies or small hosting providers on which dozens of customer projects run side by side. Such a server is particularly rewarding for attackers, because a single hit affects many websites at once. Your risk then depends not only on your own diligence but also on that of your service provider.

> **Important:**
> Scans in your logs are normal and not evidence of a break-in. A successful attack shows up in other traces: new files, foreign processes, unknown accounts, unusual outgoing connections.

## What you can check yourself

A look at the logs shows how heavily your server is being scanned. The following commands only read and change nothing:

```bash
# The ten addresses with the most requests in the current access log
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Requests answered with "not found", by frequency
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Does the server reveal its PHP version in the header?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
```

Many requests for non-existent paths are typical scan noise. You should become more attentive if such requests are suddenly followed by successful responses, if files you do not know are being called in upload folders, or if the web server user starts processes it otherwise never starts. There are no confirmed indicators specifically for PHP2Shell so far, so the assessment relies on such behavioural anomalies. How to evaluate logs more thoroughly is described in the guide [Evaluating web server logs](https://phpsos.de/en/ratgeber/logfiles-auswerten/). If the third query shows a PHP version, the setting `expose_php = Off` is worthwhile; background is under [Hiding version information](https://phpsos.de/en/blog/expose-php-versionsangaben/).

## The protective layers in the right order

1. **Update PHP and restart:** Without this step, all other measures remain patchwork.
2. **Reduce the attack surface:** Shut down unused websites, test systems and old microsites or put them behind a login.
3. **Rules at the edge:** A web application firewall with a maintained rule set, such as the [OWASP Core Rule Set with ModSecurity](https://phpsos.de/en/blog/modsecurity-owasp-crs/), catches some of the attempts.
4. **Slow down repeated attempts:** Tools such as [Fail2ban](https://phpsos.de/en/blog/fail2ban-fuer-webserver/) block addresses that generate an unusual number of errors. Against distributed scans, this helps only to a limited extent.
5. **Monitor:** Keep an eye on the web server user's processes, new PHP files and outgoing connections so that a successful hit does not go unnoticed for weeks.

## How does PHP SOS help?

- **Mapping the attack surface:** We determine which of your systems are reachable from outside and what they reveal about themselves.
- **Patching and hardening:** We update PHP, restart and reduce version information, write permissions and unnecessary services.
- **Rules and blocks:** We set up WAF rules and blocking mechanisms to suit your application.
- **Ongoing monitoring:** We report conspicuous processes, files and connections before a hit turns into an incident.

What this looks like in continuous operation is described in [Security monitoring for web servers](https://phpsos.de/en/leistungen/security-monitoring/).

## Conclusion

Automated attacks do not ask who owns a server. They only ask whether it is vulnerable. The best answer to that is unspectacular: patch quickly, offer little, look closely. Anyone who does that will still be scanned, but no longer found.


## Frequently asked questions

**Are small companies targets of automated attacks?**  
Yes. Automated scans probe reachable servers without regard to who operates them. Whether a corporation or a small trade business is behind it makes no difference to the software. What matters is whether the server looks vulnerable.

**How do I recognise scans in my logs?**  
Typical are many requests for paths that do not exist on your website at all, often from changing addresses and with conspicuous identifiers. Such entries are normal and not yet evidence of a successful attack, but they show that your server is being probed.

**Does hiding the PHP version help?**  
It makes it slightly harder for scanners to classify your server specifically and is a sensible baseline setting. But it does not protect against attacks that simply try every server. The update remains mandatory.

**Can I prevent scans completely?**  
No. Every publicly reachable server is scanned regularly. The aim is not to prevent scans but to make sure they find nothing: up-to-date software, little attack surface and monitoring that reports anomalies.

## Sources

- [Cloudflare blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [PHP manual](https://www.php.net/manual/de/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [BSI: German Federal Office for Information Security](https://www.bsi.bund.de/)