Website traffic isn’t always a sign of increased interest from customers. For eCommerce websites, a sudden spike in traffic can sometimes indicate something much less welcome: automated bots probing the website for vulnerabilities, outdated software, exploitable endpoints or simply attempting to overload the application.
Recently, we investigated exactly this situation on a long-established Magento eCommerce website. The traffic increase was severe enough to overload the server and cause problems with website performance.
What made the incident particularly interesting was that the bots weren’t simply requesting normal Magento product and category URLs. They were sending thousands of requests containing parameters associated with Joomla and JCommerce, despite the website being a Magento installation.
The Initial Warning Signs
The first indication was an unusually high server load. PHP processes were being triggered at a much higher rate than normal, resulting in slow page loading and, during the worst part of the incident, HTTP 500 errors.
Cloudflare’s analytics showed approximately 1.5 million requests within 24 hours. Most of these requests were handled by Cloudflare, but around 93,000 requests were still reaching the origin server.
The traffic was coming from a large number of different IPv4 and IPv6 addresses and from numerous countries. This immediately made traditional IP-based blocking impractical.
The request patterns also suggested automation rather than normal customer behaviour.
Investigating the Suspicious URLs
The hosting access logs provided the most useful evidence.
During a 30-minute period, more than 11,000 requests were recorded. Every request contained the following parameter:
option=com_jcommerce
The requests included URLs such as:
/index.php?option=com_jcommerce&Itemid=...&pgn=product_info&products_id=...
There were also requests attempting to access functions such as product information, product searches, reviews, shopping carts, account pages and checkout-related URLs.
This was particularly significant because the website was not running Joomla or JCommerce.
In fact, the website had been running Magento since 2014 and had previously used osCommerce. The site owner confirmed that it had never used JCommerce.
We also searched the Magento database for references to com_jcommerce and jcommerce and found no relevant records.
This ruled out the possibility that the current website was generating these links.
A Distributed Automated Attack
The access logs showed just how automated the traffic was.
More than 11,000 different IP addresses generated approximately 11,300 requests during the period analysed. There were thousands of unique URLs and dozens of different browser User-Agent strings.
There was also almost no legitimate referral information.
The most concerning moment came during a short burst of traffic when the request rate approached 100 requests per second. During that period, the server returned more than 1,500 HTTP 500 responses.
This provided a clear correlation between the automated traffic and the server overload.
Rather than a genuine increase in visitors, the website was receiving a distributed flood of requests designed to make the application process large numbers of dynamic URLs.
Why This Can Affect Magento
A request such as:
/index.php?option=com_jcommerce...
doesn’t necessarily get rejected simply because Magento doesn’t recognise the parameter.
If the request reaches the Magento front controller, Magento can still initialise PHP and begin processing the request before determining what to do with it.
Thousands of unnecessary dynamic requests can therefore consume:
- PHP-FPM workers
- CPU resources
- Memory
- Database connections
- Database queries
- Web server resources
The result can be a slow website or, under sufficient load, failed requests and server instability.
Blocking the Traffic Before It Reaches Magento
Once the pattern had been identified, we added a Cloudflare custom security rule targeting the common characteristic shared by the malicious requests:
option=com_jcommerce
The rule blocks requests containing that parameter at Cloudflare’s edge.
This is considerably more effective than attempting to block individual IP addresses. With thousands of source addresses, an IP blacklist would be difficult to maintain and could become obsolete very quickly.
The request can now be stopped before it reaches the Magento application:
Bot → Cloudflare → Block
rather than:
Bot → Cloudflare → Web server → PHP → Magento → Database
We also temporarily enabled Cloudflare’s additional protection while monitoring the traffic and server load.
The Importance of Monitoring
One of the most important lessons from this incident is that website security isn’t simply about installing a security plugin or applying software updates.
Traffic analysis is an important part of website security.
By comparing Cloudflare analytics with the actual server access logs, we were able to establish:
- where the traffic was coming from;
- what URLs were being requested;
- how frequently they were being requested;
- which requests were reaching the server;
- which requests were generating HTTP errors; and
- what common characteristic could be used to block the traffic.
This allowed us to create a targeted rule rather than unnecessarily blocking legitimate customers, search engines or entire countries.
Keeping Magento Websites Secure
Automated exploit scanning and bad bot traffic are realities for established eCommerce websites. A website doesn’t necessarily need to have a known vulnerability for it to be targeted.
Bots continuously scan websites looking for old software, vulnerable extensions, administrative interfaces, forgotten endpoints and unusual URL structures.
For Magento websites, maintaining current security patches, monitoring server logs and using a properly configured Web Application Firewall (WAF) such as Cloudflare can provide multiple layers of protection.
In this case, the key wasn’t simply identifying that traffic had increased. It was understanding what the traffic was actually trying to do.
Once the common pattern was identified, we could block it at the network edge and prevent the unnecessary requests from reaching Magento in the first place.
If your Magento website is experiencing unexplained server load, slow PHP processes or sudden spikes in traffic, don’t assume it’s simply increased customer activity. Analysing the request patterns can reveal automated bots or exploit scanning that needs to be stopped before it reaches your application.
