8,900 hostile requests, none of them dangerous: reading a Next.js site's own edge log

A team that builds small business sites read 28 days of its own edge logs and found the most-requested URL on a Next.js application was /wp-admin/install.php, hit 518 times, on a site that has never run WordPress and contains no PHP ^[1][2][3][4]. That inverts the usual framing: the loudest traffic against a modern Node app is not a vulnerability problem, it is a cost and log-noise problem.

Over the window the site absorbed roughly 8,900 targeted malicious requests, about 318 a day, from 373 distinct addresses, all of them on cloud, hosting or VPN networks and none residential, according to the write-up published on dev.to ^[5][6][7]. That works out to about 24 requests per address ^[1] and roughly 13 an hour across the whole site ^[2]. Every one of them resolved to a 404 or a 403 ^[8].

The most persistent single target was /.env, requested 228 times before counting the dozen spelling variants the same bot cycles through ^[9]. The author puts the whole /.env hunt at 64% of targeted traffic ^[10]. Against the 8,900 total that implies roughly 5,700 requests, about 25 times the 228 logged for the exact path ^[4], so the variants would have to be carrying nearly all of it. Treat the 64% as an estimate rather than a count. For scale, the loudest single URL, /wp-admin/install.php, is 5.8% of the total ^[3].

The useful observation in the piece is about instrumentation rather than attackers: a climbing blocked-request counter does not show the site is well defended, it shows the site is not running the software the bots assumed ^[11]. That distinction moves the traffic from the security budget to the operations budget. At 318 requests a day, all terminating in a 404 or 403 ^[5][8], the consequence is log volume, retention and alert fatigue, not capacity or compromise.

The requests that can hurt this stack do not announce themselves. They are well-formed requests to real endpoints, shaped by knowledge of the framework, leaving log lines that look almost legitimate ^[12]. The write-up names two. React2Shell, CVE-2025-55182, is a CVSS 10.0 unauthenticated remote code execution in React Server Components, disclosed in December 2025, exploited in the wild within days and added to the US CISA Known Exploited Vulnerabilities catalog ^[13]. A default Next.js app built for production was exploitable with no code change by the developer: one crafted request, code execution, no login ^[14]. No application configuration closes it, edge and WAF rules are a stopgap, and the only reliable fix is the patched release ^[15]. Next.js issued a related advisory, CVE-2025-66478 ^[16]. The second, CVE-2025-29927, let an attacker skip authorization logic living in Next.js middleware by sending an internal header the framework trusted without checking its origin ^[17].

The countermeasures described are deployment choices, not detection. Secrets are injected as runtime environment variables, nothing sensitive is written to a web-reachable path and nothing is baked into the container image, so the /.env hunt fails because the file is not on the served filesystem ^[18]. The edge rejects requests carrying a wrong or missing host, which is how a blind scanner arriving with an IP address and no correct hostname is turned away ^[19]. Dependencies are scanned on every build and kept minimal, with a rehearsed release step intended to close the gap between advisory and patch in hours rather than weeks ^[20]. Unneeded features are left disabled and content is served under a strict content security policy that blocks inline and third-party scripts ^[21].

Two things to watch. First, whether that hours-not-weeks patch claim survives contact with the next 10.0, since it is the only stated defence against the class of flaw that matters ^[15][20]. Second, this is a single unnamed site with no published raw data ^[1][22], so the ratios are indicative, not a benchmark: read your own logs before assuming your /.env share is 64%.