Fake Googlebots and PHP scanners: what hit four new sites in 48 hours

In 48 hours of server logs, four new sites received 50,644 requests. 18,283 of them (36.1 percent) asked for WordPress files, .env files and other paths that never existed there. Only 155 of those probes used a crawler's name. The 146 that named a crawler with a published IP list all came from outside that list, and requests from listed crawler addresses never asked for such a path.

By the Crawlerpeek editorial team · Updated · How we check

Why we looked now

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They fix CVE-2026-109618 and CVE-2026-109619, two flaws rated critical (CVSS v4.0 9.2) that can allow unauthenticated remote code execution. Wiz Research, which disclosed them, calls them PHP2Shell. The four sites in this log, this one included, run neither PHP nor WordPress, which makes them a clean place to watch what scanners send to every new host. If you run PHP, the patch section is the part that matters.

The numbers

MeasureValue
Window19 Oct 2026 16:07 UTC to 21 Oct 2026 16:00 UTC
Requests to the four hosts50,644 from 2,307 IP addresses
Probe requests (paths that never existed)18,283 (36.1 percent) from 423 IP addresses
Probes from the busiest single IP address26.2 percent of all probes
Probes from the busiest ten IP addresses63.6 percent
IP addresses that sent only one or two probes192
Probe requests from listed crawler IP addresses0

Probe volume by day: 3,079 on 19 October (from 16:07 UTC), 11,809 on 20 October and 3,395 on 21 October (until 16:00 UTC). One address alone sent 4,785 probe requests on 20 October, 4,565 of them for /wordpress and /wordpress/. Scanners are fast: one site was opened during the window, and its first probe arrived 5 seconds after its first logged request. We cannot see how they found it; public certificate transparency logs, which list every newly issued TLS certificate, are one common source.

What they asked for

GroupRequestsIP addressesTypical paths
WordPress and PHP9,438410/wp-admin/install.php, /wp-login.php, /xmlrpc.php, /wp-includes/wlwmanifest.xml under many folder names
Secrets and config files8,62644/.env and variants, /.git/config, /.aws/credentials, /firebase.json, /web.config
Debug and API endpoints21928/graphql, /actuator/env, /swagger.json, /debug/vars

Most addresses in the WordPress group sent only a few requests: /wp-admin/install.php was requested 1,091 times by 265 addresses, /wp-login.php 156 times by 48. Three addresses, though, sent 4,276 of the group's 9,438 requests, all for /wordpress and /wordpress/. The secrets group is the opposite: fewer addresses, many paths each. /.env alone drew 111 requests from 36 addresses, and paths under /.git/ 420 requests from 37. 1,573 probes were POST requests, the rest GET. 10,806 got a 404, 7,461 a redirect (308), mostly from http to https or to the address without a trailing slash, and 7 got the normal home page because only the query string looked like a probe.

Requests that only borrowed a crawler's name were rare

For each request that named a crawler in its user agent, we checked the IP address against the operator's published list. Of 6,795 such requests, 261 (3.8 percent) came from outside the list.

Name in the user agentIn the operator's listOutside the listOutside the list and a probe
Googlebot4,3467746
OAI-SearchBot1,5674120
GPTBot3703118
Applebot15700
Bingbot693519
ChatGPT-User203519
PerplexityBot and Perplexity-User54224
  • All 261 requests outside the lists came from just three IP addresses. None of them had a reverse DNS name on an operator's domain. One, a hosting provider's address, rotated through six crawler names.
  • 146 of those 261 requests were probes, sent by two of the three addresses. 118 of the probes asked for secrets and debug paths such as /graphql, /.env.development, /actuator/env and /swagger.json.
  • Requests from addresses on the published lists never matched a probe pattern.
  • For ChatGPT-User and Perplexity, requests carrying the name were more often fake than real here, but the totals are small.
  • Most probes did not pretend to be a crawler at all: 14,346 looked like a browser and 2,637 came from tools and HTTP libraries such as curl or Python.
  • 533 requests named ClaudeBot, Claude-SearchBot or Claude-User. We did not check these against an IP list, so they are left out of the table; 9 of them were probes.

How to check a crawler in your own logs

A user agent is only a claim. Google documents two ways to verify Googlebot, and other operators publish similar lists: compare the IP address with the published ranges, or run a reverse DNS lookup and confirm it with a forward lookup. Google's crawler overview links its lists. This script checks one address against one list:

# verify_crawler.py: is this IP address in the operator's published list?
import ipaddress, json, sys, urllib.request

LISTS = {
    "googlebot": "https://developers.google.com/static/search/apis/ipranges/googlebot.json",
    "bingbot": "https://www.bing.com/toolbox/bingbot.json",
    "gptbot": "https://openai.com/gptbot.json",
    "oai-searchbot": "https://openai.com/searchbot.json",
    "chatgpt-user": "https://openai.com/chatgpt-user.json",
    "perplexitybot": "https://www.perplexity.ai/perplexitybot.json",
    "perplexity-user": "https://www.perplexity.ai/perplexity-user.json",
    "applebot": "https://search.developer.apple.com/applebot.json",
}

bot, ip = sys.argv[1].lower(), ipaddress.ip_address(sys.argv[2])
req = urllib.request.Request(LISTS[bot], headers={"User-Agent": "verify-crawler"})
prefixes = json.load(urllib.request.urlopen(req))["prefixes"]
nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix")) for p in prefixes]
print("in list" if any(ip in n for n in nets if n.version == ip.version) else "NOT in list")

Run it as python3 verify_crawler.py googlebot 66.249.66.1. Google's list covers its common crawlers; special crawlers and user-triggered fetchers have their own lists on the same page. The DNS route needs no script:

host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Both answers must agree: the name ends in googlebot.com, google.com or googleusercontent.com, and the forward lookup returns the same address. To find probes in an nginx or Apache access log in the default combined format, and the addresses that sent them while calling themselves Googlebot (behind a CDN or proxy, the first field is the proxy's address unless you log the client IP):

grep -cE '"(GET|POST|HEAD) [^"]*(wp-login\.php|xmlrpc\.php|wp-admin|/\.env|/\.git/)' access.log

grep -E '"(GET|POST|HEAD) [^"]*(wp-login\.php|xmlrpc\.php|wp-admin|/\.env|/\.git/)' access.log \
  | grep -i googlebot | awk '{print $1}' | sort | uniq -c | sort -rn

If you run PHP: what to do this week

  • Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your Linux distribution's patched package. The PHP project says vendors received the fixes in advance.
  • Check the PHP that serves web requests, not only php -v. The command-line binary can differ from PHP-FPM or the Apache module; on Debian or Ubuntu, dpkg -l 'php*' | grep -E 'fpm|libapache2-mod-php' lists what is installed.
  • Restart every PHP-FPM pool or the web server after the update so no worker keeps running the old code.
  • PHP 8.1 and older get no fix from the PHP project. Minimal source backports exist for 7.4, 8.0 and 8.1. Moving up is the lasting fix; 8.2 itself reaches end of life on 31 December 2026, so 8.3 or newer gives you more time.
  • On shared or managed hosting, check your provider's status page or ask which PHP build your site runs.
  • If you cannot update today, the PHP project lists interim settings such as session.upload_progress.enabled=0 and request-size limits. It says they are not a substitute for updating.

Sources: the PHP 8.5.12 release page, the advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, and Google Cloud's bulletin, which gives the affected range as PHP 5.4 through 8.5.11. Reports differed on 21 October about whether attacks are already happening.

Did we see PHP2Shell attempts?

Nothing we could attribute to it. The probes on 21 October asked for the same WordPress and secret paths as the two days before. That is weak evidence either way: our sites run no PHP, so there is nothing for these flaws to attack, and our access logs record no request bodies. A server that does run PHP would see a different picture.

How we measured

  • Source: the JSON access logs of the web server (Caddy) in front of four new sites on one server, including this one. Duplicate lines were removed. The logs are kept for 7 days and no IP address is published here.
  • A probe is a request whose URL (path and query string) matches a fixed list of patterns for files and endpoints that none of the four sites has: WordPress and PHP files, secrets and config files, debug and API endpoints. We checked the list against the four sitemaps; it matches none of their pages.
  • IP lists were downloaded once, on 21 October 2026, after the window: Google's crawler, special-crawler and user-triggered-fetcher lists, Bing's, OpenAI's three lists, Perplexity's two and Apple's. A crawler address that left a list before that day would count as outside it. Reverse DNS lookups for the addresses outside the lists were run the same day.
  • User-agent groups are based on substrings: a crawler's name, a tool or library name, or a browser-style Mozilla/ string.
  • Limits: 48 hours, one server, four small new sites. Older or larger sites will see other numbers, and probe traffic changes from day to day.

Follow-up questions

Should I block requests for wp-login.php if I don't run WordPress?

If the file does not exist they end in a 404, so they cannot do harm on their own. Blocking them at the proxy only saves a little work. What matters is that no forgotten PHP file, backup or .env file is reachable.

Can I block fake Googlebots without hurting my rankings?

Yes, if you check the IP address against Google's published list or with a confirmed reverse DNS lookup before you block. Never block by user agent alone, and never block addresses on the list.

Is my site affected by PHP2Shell if it does not run PHP?

Not by these two flaws. Check what else runs on your domains, though: a WordPress blog on a subdomain, a hosted shop, phpMyAdmin or an old admin tool may run PHP even when the main site does not.

See how your own site does.Run the checker

Keep reading