HiveProtect.ai » English » blog » WordPress Attacks and PHP2Shell: What HiveProtect Blocked

WordPress Attacks and the PHP2Shell Vulnerability: What HiveProtect Blocked on Our Sites

HiveProtect shield stopping arrows that symbolize WordPress attacks

On October 21, 2026, two critical PHP vulnerabilities were made public under the name PHP2Shell. On a vulnerable server, they can be used to take control of the engine that runs WordPress. The bots did not wait for the official announcement: as early as October 18, our own sites were receiving WordPress attacks modeled on this combination. HiveProtect stopped them all.

We protect our own WordPress sites with HiveProtect. So we opened our logs and added it all up: here is the typology of WordPress attacks we received, what HiveProtect blocked, and how. To keep our rules effective, we do not publish their thresholds or signatures.

WordPress attacks: more than 448,000 requests blocked in 3 days

From October 20 to 23, in the middle of the PHP2Shell news, our sites protected by HiveProtect blocked more than 448,000 requests. More than 425,000 were turned away before they even reached our servers, by filtering rules placed upstream to lighten their load. The rest reached our servers, where HiveProtect took over.

Over a full week, from October 16 to 23, HiveProtect stopped 46,325 requests on our servers, more than 6,600 a day. These are not visitors who took a wrong turn: 36,293 came from attackers already banned by HiveProtect, almost all of them refused by the web server itself, before PHP even started; 8,928 came from addresses reported by the HiveShield shared list; and 1,104 were attacks detected in the request itself by the firewall.

What HiveProtect blocked on our servers in 7 daysBar chart: from October 16 to 23, 2026, HiveProtect blocked 46,325 requests on our servers: 36,293 came from attackers already banned, 8,928 from addresses reported by the HiveShield shared list, and 1,104 were attacks detected by the firewall. What HiveProtect blocked on our servers in 7 days October 16–23, 2026 · 46,325 requests blocked Attackers already banned by HiveProtect 36,293 Addresses from HiveShield’s shared list 8,928 Attacks detected by HiveProtect’s firewall 1,104 Source: logs from our servers and HiveProtect

That is only the visible part. Over a month, our sites also answered “page not found” more than 7,800 times to outside visitors coming from more than 3,000 IP addresses: real readers who landed on an outdated link, but also bots that test pages one by one to spot a poorly protected site.

The seven families of attacks stopped by HiveProtect

In 72 hours, from October 19 to 22, HiveProtect unmasked and reported more than 350 attacking addresses on our sites. The chart below sorts their 403 reports by type; behind these reports, we distinguish seven families of attacks.

72 hours: attackers unmasked by HiveProtectBar chart of the 403 reports issued by HiveProtect from October 19 to 22, 2026: 129 for secret files and admin access points, 96 for user account enumeration, 81 for scanner bots and suspicious identities, 41 for the search for backdoors, 39 for attempts to break out of the site folder, and 17 others. 72 hours: attackers unmasked by HiveProtect October 19–22, 2026 · 403 reports, by family Secret files and admin access points 129 User account enumeration 96 Scanner bots and suspicious identities 81 Search for backdoors 41 Attempts to break out of the site folder 39 Other: bursts, injections, miscellaneous 17 Source: HiveProtect reports from our own sites

1. The scouts: taking stock of the site

Most WordPress attacks begin with some scouting, which specialists call reconnaissance. The bot requests dozens of pages that do not exist, or files specific to one plugin or another, to learn what is installed and in which version.

How HiveProtect stops it: a human visitor does not request a whole string of missing pages. In October, we added a rule to HiveProtect dedicated to this sweep. Tested on a month of real traffic before it went live, it would have turned away 48 IP addresses, 29 of which no other rule had yet spotted, without affecting any visitor, customer, or search engine bot.

2. The hunt for secret files

This is the family that triggered the most alerts: forgotten backups, configuration files, development tool folders, and admin access points. A single file of this kind left in the wrong place can hand over the keys to the database.

How HiveProtect stops it: no legitimate visitor has any reason to request these files on a WordPress site. Over the period, none was served, and the addresses requesting them were banned as soon as their intent was established.

3. User account enumeration

Before trying to guess a password, you first need to know a username. In 72 hours, we recorded 777 requests aimed at listing the accounts on our sites. One of the campaigns was particularly well organized: sixteen successive waves, two to four IP addresses at a time, located in different countries and disguised as recent browsers.

How HiveProtect stops it: in this campaign, every address was refused and banned on its very first request targeting accounts; its subsequent requests ran up against the web server itself. The outcome: no account name was obtained, and the campaign’s fifty addresses were shared with our other sites.

4. The search for backdoors

Some bots look for traces of an earlier hack, for example a malicious file planted by another attacker and left in place. On an already compromised site, that file hands them control directly.

How HiveProtect stops it: on a healthy site, these files do not exist; asking for them gives away the intent, and the address is turned away before it can go any further.

5. Attempts to break out of the site folder

This is the family tied to the news. A WordPress vulnerability made it possible to force a site to load a file located elsewhere on the server; combined with PHP2Shell, it could be used to run code. Since mid-September, we have counted 4,220 requests of this type on our sites, sent from 47 addresses. None of them was served.

How HiveProtect stops it: a web address has no reason to leave the site folder to go fetch other files on the server. On October 18, HiveProtect stopped the attack modeled on PHP2Shell on its very first attempt, then banned the attacker.

6. The impostors

Many bots lie about their identity: they pass themselves off as a browser, a major search engine, or an artificial intelligence service. Others come from servers rented by the hour in data centers, a profile that is rare among real readers.

How HiveProtect stops it: it does not trust what the visitor declares. It verifies bots that claim to belong to a major search engine and takes into account the real origin of the connection. During the period, six of these servers were turned away on their very first request.

7. Coordinated assaults

Some campaigns are orchestrated: several addresses hit a site at the same moment, then the operation moves on to the next site a few minutes or a few hours later, to go unnoticed.

How HiveProtect stops it: this is the role of HiveShield, HiveProtect’s shared list. An address caught red-handed on one site is reported, then refused on the other protected sites: in 7 days, this list alone blocked 8,928 requests on our servers.

And what about password attempts?

One family stayed quiet: password attempts. The two bursts spotted earlier in the month, on October 17, were refused without a single login succeeding.

PHP2Shell: how HiveProtect cut off the attack

On its own, the PHP2Shell vulnerability is hard to exploit. The simplest method is to combine it with a file inclusion vulnerability, like the WordPress one mentioned above. This is the kind of attack our sites received, and HiveProtect cut it off at three levels:

  • From the very first attempt: the inclusion request is refused by the HiveProtect firewall, before WordPress processes it.
  • As close to the server as possible: the attacker is banned immediately. The attacker’s subsequent requests are refused by the web server itself and no longer even reach PHP: the attack can no longer succeed.
  • On every site: the attacker’s address is reported to HiveShield, which shares it with the other protected sites.

The result: none of these attempts succeeded on our sites. This is the whole strength of defense in depth: several barriers, each capable of stopping the attacker.

HiveProtect’s barriersDiagram in six layers: the attacker’s request, then the web server that refuses attackers banned by HiveProtect before PHP even runs, HiveProtect’s early firewall, the HiveProtect firewall that analyzes every request, WordPress, which only receives filtered traffic, and the site and its data, protected. HiveProtect’s barriers The path of a hostile request to the site ! The attacker’s request It has to cross every HiveProtect barrier. 1 Web server Attackers banned by HiveProtect are refused here, before PHP even starts. Stop PHP2Shell 2 HiveProtect early firewall HiveShield shared list, scanner bots, secret files: stopped before plugins load. 3 HiveProtect firewall Every request is analyzed before WordPress; the attacker is banned and reported. 4 WordPress It only receives filtered traffic. 5 The site and its data Protected.

This is not the first time PHP has been targeted: we previously described how HiveProtect blocked the CVE-2024-4577 attack.

Why these attacks failed: what HiveProtect does

  • It refuses early: the earlier a hostile request is stopped, the less chance it has of hitting a vulnerability, whether already known or not.
  • It bans for the long term: an address that has shown its intent does not get a second chance, and the ban is applied as close to the server as possible.
  • It shares the information: thanks to HiveShield, what one site learns quickly benefits all the others.
  • It unmasks impostors: fake bots and suspicious connections are recognized, whatever they claim.

All of these protections are detailed in the HiveProtect features, and our article “WordPress Attacks Never Sleep” shows how these campaigns follow one another every day.

What you can do today

  • Install a WordPress firewall that bans attackers instead of merely slowing them down, and that shares what it learns.
  • Keep PHP, WordPress, your theme, and your plugins up to date, and delete the plugins you no longer use.
  • Do not leave any backup or configuration file in a folder that can be reached from the web.
  • Use a custom login address and unique passwords.

To install and configure HiveProtect, the documentation and the Help Center explain each step in detail.

In summary

In the middle of the PHP2Shell news, our sites protected by HiveProtect blocked more than 448,000 requests in 3 days, and HiveProtect stopped more than 46,000 requests on our servers in one week, spread across seven families of attacks. Against PHP2Shell as against everything else, HiveProtect’s logic does not change: refuse early, ban for good, and share the information.

Your site receives the same WordPress attacks, whether you see them or not. Discover the HiveProtect plans and protect your site today.