* My exact OpenCart version: 3.0.3.2
* Deployed locale or live: Live
* Installed/Used Template/Theme: so-emarket
* Servertype : Cenots 7.9
* php-Version: 7.2
* MySQL-Version: Mariadb 10.11.9
* Website is not behind cloudflare proxy
We are noticing some strange mysql query execution with our open cart website. And this particular query is not getting closed. It will kept running and multiple same queries will get executed at random time. This will induce load in the server and causing the website slow and not responding. I am attaching the full query. This is found to be really suspicious for me it is found to be a kind of attack. I have already enabled apache mod_security OSWAP rules but some how the query is being triggered via website url.
Currently I have to check the mysql process list regularly and kill the query using kill command in order to keep the website live for customers.
Attachments
???Suspicious full query
Consider upgrading the site to Opencart 3.0.4.1 (NOT Opencart 4 in any version) and then upgrading to php 8
Search brute force attack => use google to search "OPENCART forum brute force attack", for some solutions.
viewtopic.php?t=225771
DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.
https://www.youtube.com/watch?v=zXIxDoCRc84
I have enabled mysql query trace in Opencart so crack down the source. What I understand is there is some brute force happening via "Search" option in the website home page. See the screen shots attached.
Can this be search settings be tweaked ? to prevent this from happening ? Can we limit number of characters in search ?
Code: Select all
catalog/controller/product/search.php
Code: Select all
$search = isset($this->request->get['search']) ? trim($this->request->get['search']) : '';
if ($search !== '') {
// length cap
if (mb_strlen($search, 'UTF-8') > 64) {
$search = mb_substr($search, 0, 64, 'UTF-8');
}
// allowlist characters
if (!preg_match('/^[\p{L}\d\s\-.]+$/u', $search)) {
$this->response->addHeader('HTTP/1.1 400 Bad Request');
return;
}
}
P.s i haven't tested but in theory should work
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
Thank you very much for the update. I am running open cart which has Apache as web server. It is a VPS with this opencart website alone. Mod_security rules with OWASP is already enabled. But it is not blocking the malicious search
Seems odd that you have a search that would respond with anything but a 404 page not found if it were via the search.
Since both of those relate to a specific up address you should just block the ip via htaccess or your server control panel.
It would also be advisable to check the host of that ip and block the whole block of ips.
You also need to check if you have been hacked. That sql appears to be looking for malicious code within your products. Have you checked your database tables?
DISCLAIMER:
You should not modify core files .. if you would like to donate a cup of coffee I will write it in a modification for you.
https://www.youtube.com/watch?v=zXIxDoCRc84
Our website is an international website and we are getting orders across the globe. The owner of the website don't want to block country wide as well.
>> Seems odd that you have a search that would respond with anything but a 404 page not found if it were via the search.
It is supposed to do that. But it is not happening
Code: Select all
Order Deny,Allow
Deny from 154.217.125.142
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
You can email me for paid assistance and I can help you to secure it properly.nisamudeen97 wrote: ↑Tue Aug 12, 2025 12:46 amHi,
Thank you very much for the update. I am running open cart which has Apache as web server. It is a VPS with this opencart website alone. Mod_security rules with OWASP is already enabled. But it is not blocking the malicious search
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
A hosted IP, good luck going that route.JNeuhoff wrote: ↑Tue Aug 12, 2025 6:06 pmThe first thing you should do is to block the IP-address 154.217.125.142 in your .htaccess, see below.
Code: Select all
Order Deny,Allow Deny from 154.217.125.142
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
I have done what "khnaz35" has suggested. It has done the fix. I have also enabled detailed logging of what is being "searched" on search box. I could see there is heavy bruteforce. See the full log attached. Do you think if it is bots doing these kind of searches? I can see it is coming from random IP's, So blocking via htaccess is not practical. And fail2ban also wont work as there is not failed attempts. Mod_security is also unable to identify this. Around 400+ bruteforce searches in 4 hours.
Is there any solution to stop this ?
Attachments
search detailed log
Assuming you are using Apache Save as something like this in
/etc/modsecurity.d/zz-smartsearch-antispam.conf
Code: Select all
# --- SmartSearch anti-spam / abuse (OpenCart) provided by Khnaz35@gmail.com ---
# Assumes OWASP CRS is loaded first; IDs chosen to avoid CRS ranges.
# 0) Always init IP collection so rate-limits work
SecAction "id:4020000,phase:1,pass,nolog,initcol:ip=%{REMOTE_ADDR}"
# 1) Block obvious spam artifacts seen in your logs:
SecRule ARGS:(filter_name|filter_tag) "@rx (?i)(?:[【】]|https?://|(?:^|[^a-z0-9_])@|t\.me|telegram|66seo\.cc|77seo\.cc|88seo\.cc|6666599\.com)"
"id:4020001,phase:2,deny,log,status:403,msg:'SmartSearch spam: brackets/URLs/handles/domains in filter_*'"
# 2) Kill common ad/SEO spam tokens from the samples
SecRule ARGS:(filter_name|filter_tag) "@rx (?i)(?:facebook\s*ads?|google\s*(?:ads|adsense|adwords)|seo|sem|开户|推广|群发|谷歌|抖音|youtube)"
"id:4020002,phase:2,deny,log,status:403,msg:'SmartSearch spam keywords in filter_*'"
# 3) Over-long search strings (tune threshold to your catalog)
SecRule ARGS:(filter_name|filter_tag) "@gt 100"
"id:4020003,phase:2,deny,log,status:403,t:length,msg:'SmartSearch: query too long (>100 chars)'"
Make sure that Apache: enable mod_remoteip and set RemoteIPHeader X-Forwarded-For plus RemoteIPTrustedProxy.
Don't forget to reload your service after you make the changes in mode security rules.
Remember the golden rule always make a backup and test thoroughly if something doesn't work so you can roll back
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
Well OpenCart isn't vulnerable to SQL injection by default so you must be using a search extension that doesn't sanitise its inputs?nisamudeen97 wrote: ↑Mon Aug 11, 2025 6:17 pmWe are noticing some strange mysql query execution with our open cart website.
UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk
When you look at those vietnamese, simplified chinese and traditional chinese lines, It actually looks more like spam than hacking/brute force attempts.nisamudeen97 wrote: ↑Tue Aug 12, 2025 10:11 pmHi,
I have done what "khnaz35" has suggested. It has done the fix. I have also enabled detailed logging of what is being "searched" on search box. I could see there is heavy bruteforce. See the full log attached. Do you think if it is bots doing these kind of searches? I can see it is coming from random IP's, So blocking via htaccess is not practical. And fail2ban also wont work as there is not failed attempts. Mod_security is also unable to identify this. Around 400+ bruteforce searches in 4 hours.
Is there any solution to stop this ?
Since these languages are multibyte character languages, better use mb_strpos in that smartsearch module.
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
Don't think so, all of these queries are non malicious, apart from the odd one with quotes in them, these are not attacks, this is pure spam.khnaz35 wrote: ↑Wed Aug 13, 2025 1:39 pmTo me it appears to be a bot-driven attack, where the target website is being leveraged as a testbed (or "box") for automated payload execution. The request patterns suggest that script kiddies are employing automated tools—most likely using Playwright (a browser automation framework)—to run headless browser-based payload.
So yes its a Spam bot/boy-driven attack.
Got a burning question at 3 AM that even Google shrugs at? There’s a not-so-secret inbox that might just have your answer: khnaz35@gmail.com
Breathe in some nature while you're at it. It’s cheaper than therapy.
Feel free to sling a bear my way via PayPal @ khnaz35@gmail.com
Users browsing this forum: Semrush [Bot] and 19 guests