Attack Analysis: Vulnerability Scanner vs. Multify Proxy
In this article: an analysis of a real vulnerability scanner attack on Multify's proxy infrastructure—what bots look for, how they are blocked on approach, and why the client's site doesn't even know about it.
May 29, 2026, 5:04 PM. Two IP addresses from Côte d'Ivoire connected to the Multify proxy server. Over the next 90 seconds, they tried almost 100 URLs and received 100 rejections.
This is typical vulnerability scanner behavior. Not a targeted attack, but automated reconnaissance. Such scanners operate continuously, crawling millions of websites in search of one thing: an open file with keys, passwords, or configuration, or a known CMS vulnerability. It doesn't matter what the site is built on—WordPress, Drupal, Joomla, or a custom engine. The scanner checks everything using a standard dictionary.
Multify, as a reverse proxy, takes all incoming traffic. The scanner hits Multify's infrastructure, not the client's site directly. Proxy protection is client website protection.
This is not a random set, but a standard dictionary compiled from real leaks. Every file on this list was once found publicly accessible on someone's production server.
What Exactly They Are Looking For
Environment Variables — .env files and their variants. Developers store API keys, database passwords, and payment system tokens in them. One such file gives an attacker full access to the infrastructure without any traces of a breach. According to GitGuardian, in 2024, secrets were found in public repositories more than 12 million times, with .env being among the top three most frequent. A developer adds the file to .gitignore, but on the server after deployment, it remains in the public directory, and no one checks.
CMS and Framework Configs — wp-config.php (WordPress), Joomla configs, Drupal, Laravel, Symfony, Rails files. The scanner doesn't know what the site is built on, so it checks all popular options in a row.
Cloud Keys — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. Exposure means access to a cloud account with all data and potential bills for tens of thousands of dollars.
Encryption Keys — private.key, server.key, rails/master.key. An open private key allows decrypting all traffic or forging signatures.
Logs and dumps — error.log, debug.log, database.sql, dump.sql. Logs often contain user data, file paths, sometimes passwords in plain text.
Infrastructure configs — nginx.conf, docker-compose.yml, web.config. From these, you can learn the internal network topology and find the next entry point.
CMS vulnerabilities — a separate category. As soon as a new CVE is published, scanners start checking all sites, often within a few hours. According to Google Project Zero, the median time from CVE publication to the first attacks is 15 days, but for vulnerabilities with a public PoC, this time has shrunk to a few hours. An example currently in active exploitation: CVE-2026-9082, SQL injection in Drupal Core on PostgreSQL (versions 8.0 to 11.3.9). The vulnerability lies in how Drupal builds SQL queries via JSON:API: an attacker passes an array key with nested SQL in the filter parameter, Drupal inserts it into the query without sanitization. Without authorization, via a regular HTTP request. Result: database dump, admin account creation, in some configurations arbitrary code execution. CVSS 9.8, critical (for comparison: Log4Shell, which brought down half the internet in 2021, received 10.0). The patch was released on May 20, a working PoC appeared on GitHub in less than an hour. On May 22, the vulnerability was added to the CISA Known Exploited Vulnerabilities catalog. In the first 48 hours, more than 15,000 exploitation attempts were recorded on almost 6,000 sites in 65 countries.
The May 29th attack was exactly like that. WAF worked according to OWASP CRS signatures, CrowdSec added both IPs to the blocked list. The client didn't know about it.
The scanner went through all categories at once, in 90 seconds.
Two IPs — one scanner
The scanner launched from two addresses simultaneously. Modern scanners distribute the load across multiple IPs to stay below the threshold of simple rate-limit rules. If the protection triggers on "more than 10 requests per minute from one IP," the scanner simply makes 5 from each. At the same time, the IPs themselves are most often unrelated to the actual attacker — these are rented VPS, compromised servers, or botnet machines around the world. Côte d'Ivoire here is a random geography, not where a person is actually working from.
An interesting detail from the log: the first request from the second IP returned 200 — the scanner first checked the main page, made sure the site was alive, and only then began enumeration. This is a sign of a tool, not random traffic.
How a Proxy Blocks an Attack
WAF
A WAF (Web Application Firewall) is an application-layer firewall. Unlike a network firewall, which looks at IPs and ports, a WAF reads the content of an HTTP request: URL, headers, body. It analyzes each request before it reaches the website.
The rules are based on OWASP Core Rule Set (CRS), an open set of attack signatures supported by the non-profit OWASP Foundation. CRS covers configuration file enumeration, SQL injection, XSS, and other common vectors. Requests to .env, .sql, .key, wp-config.php, and dozens of other extensions are blocked immediately. The WAF doesn't know if the file exists on the server — it blocks by request name, and the scanner is denied before it can learn anything.
CrowdSec
CrowdSec is an open-source behavioral analysis engine. While a WAF processes each request individually, CrowdSec looks at the sequence: what exactly this IP is requesting over the past few minutes.
One request to .env might be a broken link. Ten requests to .env, .env.production, .env.local, .envrc within 30 seconds — that's no longer a user. CrowdSec recognizes this pattern using scenarios (behavioral rules) and blocks the IP. Blocked addresses are added to a shared threat database used by thousands of servers worldwide. A scanner detected on one site immediately becomes an unwelcome guest everywhere.
The scanner processed its standard dictionary in a minute and a half and left empty-handed. The client's website received no malicious requests.
Why it works this way
When a website connects to Multify, all incoming traffic goes through a proxy. The client connected Multify for localization, not for protection. But since the proxy is in front of the website, all of Multify's infrastructure protection automatically extends to it.
Leaks through open files are one of the most common hacking vectors. They occur not due to complex exploits, but due to банаl errors: a developer deployed a project and forgot to remove .env. Placed a test database dump in a public folder. Left a config with passwords on the server. Scanners find such files within a few hours, long before anyone on the team notices the error.
Frequently Asked Questions
Does Multify protect against CVE-2026-9082?
If the client's website runs on Drupal with PostgreSQL, the WAF at the proxy level blocks characteristic request patterns: complex filter parameters to /jsonapi, requests to /user/login?_format=json with non-standard bodies. The scanner does not reach the site. But this is not a substitute for a patch: if the site is directly accessible bypassing the proxy, there is no protection.
Why two IPs, not one?
Modern scanners distribute requests across multiple addresses to stay below the threshold of simple rate-limit rules. CrowdSec looks at behavior, not the number of requests from a single IP, so this technique doesn't help.
Did the scanner learn anything about the client's website?
No. WAF blocks requests by path name before they reach the application. The scanner does not know if the file exists on the server — it receives a denial at the proxy level.
What if the attack is not a scanner, but a targeted hack?
A targeted attack is more complex: the attacker knows the target, uses non-standard vectors, and works slowly so as not to fall into behavioral patterns. WAF and CrowdSec reduce the attack surface, but do not provide a hundred percent guarantee. Critical sites require penetration testing and anomaly monitoring.
Is Côte d'Ivoire important?
No. The geolocation of the scanner's IP is the geolocation of the machine being used, not the attacker. Blocking by country is meaningless: the next attack will come from Brazil, the Netherlands, or Russia.
Protection included with localization
WAF and behavioral blocking work at the proxy level — for every site under Multify, without additional settings on your part.