Logs Week: who and how broke my Joomla website

Real access.log data over two days — 1,199 requests, 279 unique IPs, and dozens of attacking bots.

Every day, your website processes hundreds of requests. Some of them are search engine bots, some are real visitors. But there is a third category: automated scanners and exploit bots that methodically probe your site for vulnerabilities. I decided to dig into my site's access logs and break down exactly who is trying to gain access and how. Spoiler: the picture isn't pretty.

Analysis period: August 27–28, 2026. The site runs on Joomla 6, the server is protected by a basic .htaccess (blocking WP paths, hidden files, POST without referrer). A BitSight bot (USA) was previously blocked — more on that below.

The Big Picture

Over two days — 1,199 requests from 279 unique IPs. Of those:

• ~100 requests — legitimate search bots (Yandex, Google, Bing, ClaudeBot)
• ~260 requests — me (admin panel, content editing)
• ~840 requests — everything else: scanners, bots, junk

Most attackers receive a 403 (htaccess block) or 404 (file not found). No attack succeeded — but that doesn't mean you can relax.

Attack Type #1: Backup and Archive Hunting

IP: 94.154.35.236
Requests: 35 over two days
Method: HEAD (checks if a file exists without downloading it)

The most persistent visitor. At roughly one-hour intervals, this bot sends HEAD requests to files like /backup.xz, /archive.xz, /krim-web.ru.xz, /bitrix/backup.xz, /administrator.xz, /wp.xz, /joomla.xz, and so on. A dictionary of several dozen words.

Goal: find a site or database archive carelessly left on the server. If such a file exists, the bot will download it, and the entire contents of your site will be in the attacker's hands.

Result: 35 times it got a 403 — .htaccess blocks requests to .xz files. The bot keeps coming back.

How to protect yourself: block requests to archives (.xz, .tar, .gz, .zip, .sql, .bak) via .htaccess. Check that there are no forgotten backups in public directories on the server.

Attack Type #2: RCE via SP Page Builder

IPs: 176.234.229.85 and 103.59.161.106
Requests: 16 + 19 = 35
Method: POST

This is the most dangerous category. Both bots use the exact same exploit with a User-Agent of sppb-rce-poc — literally "Proof of Concept for RCE in SP Page Builder." RCE (Remote Code Execution) means executing arbitrary code on your server.

The attack targets the endpoint /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon. If the SP Page Builder component is a vulnerable version, this request can be used to upload a PHP shell to the server and gain full control.

One bot (176.234.229.85) sent 16 POST requests with different payloads in 2 seconds. The second (103.59.161.106) sent 19 requests in 4 seconds. This is automated fuzzing: brute-forcing exploit variants.

Result: 404 — the SP Page Builder component is not installed on the site, the endpoint doesn't exist. But if it had been — the consequences could have been catastrophic.

How to protect yourself: update SP Page Builder to the latest version. Remove unused extensions. Use a WAF or admin protection plugin.

Attack Type #3: JCE Scanning

IPs: 176.234.229.85, 86.104.22.88, 107.174.33.101
Requests: 3–4 from each IP

Several bots check for the presence of JCE editor files:

• /plugins/editors/jce/jce.xml — editor configuration
• /administrator/components/com_jce/jce.xml — component configuration
• /plugins/system/jcemediabox/js/jcemediabox.js
• /plugins/system/jce/css/content.css

JCE is a popular editor for Joomla. Its history includes several critical vulnerabilities (especially in versions before 2.8.x). By checking for the jce.xml file, the bot determines whether JCE is installed, and if so — applies the corresponding exploit.

One bot (107.174.33.101), after checking for JCE, immediately sent a POST request to /index.php?option=com_jce — a direct exploitation attempt.

How to protect yourself: update JCE to the current version. If you don't use it — remove it completely, don't just disable it.

Attack Type #4: Telegram Bot Backdoors

IP: 107.174.33.101
Request: GET /tmp/tg_xiga857_59d1735a843dc59e7b075f12d96b3311.xml.php

The most alarming request in the entire observation period. The bot visited the homepage (200), immediately followed by a POST to com_jce (404), and then looked for a file named tg_ + hash + .xml.php in the /tmp/ directory.

This isn't just scanning. This is searching for an already-installed backdoor. If your site has already been compromised (through an old JCE vulnerability, SP Page Builder, or anything else) — attackers leave a PHP file disguised as XML in /tmp/, which allows them to control the server via a Telegram bot. Such a backdoor can exist for months undetected.

How to check:

• find /tmp -name "*.php" -o -name "*.xml.php"
• Check uploads/, images/, media/ for suspicious PHP files
• Verify Joomla core file hashes against official ones

Attack Type #5: WordPress Scanners

IP: 134.199.175.172
Requests: 13
Pattern: /wp/wp-admin/install.php, /blog/wp-admin/install.php, /shop/wp-admin/install.php...

The bot tries 13 common WordPress installation paths: /wp/, /blog/, /shop/, /old/, /new/, /cms/, /backup/, and so on. If it finds an incomplete WP installation, it can create an admin account.

Another bot (89.163.146.197) looked for txets.php — with a typo in the User-Agent (Mozlila instead of Mozilla). Copy-paste enthusiasts.

How to protect yourself: make sure there are no files in the site root that don't belong to Joomla. A 404 is fine, but it's better not to give bots a reason to come back at all.

Attack Type #6: Path-Traversal and Config Hunting

IPs: 45.38.18.22 (path-traversal) and 103.77.106.45 (SFTP config)

Path-traversal (45.38.18.22): the bot tries nested paths like /images/images/images/images/cache.php — if there's a misconfigured path on the server, it can escape the DocumentRoot.

SFTP scanner (103.77.106.45): looks for files /sftp-config.json and /.vscode/sftp.json. If a developer works through VS Code with the SFTP plugin and accidentally committed the config, an attacker gets access to the FTP/SFTP server.

How to protect yourself: check your .gitignore, .htaccess (block .vscode/, .env, sftp-config.json), and ensure path-traversal doesn't work on your server.

Attack Type #7: MCP Scanners (New)

IP: 2a10:3c0:100:0:1:1:0:5 (IPv6)
UA: python-httpx/0.28.1

A fresh trend — scanners looking for open MCP servers (Model Context Protocol). Requests: POST /mcp and GET /sse. If an MCP server is running, the bot will try to execute actions through it.

How to protect yourself: if you don't use MCP — block the corresponding endpoints via .htaccess.

Who Doesn't Attack?

Not all bots are evil. Useful bots over two days:

These bots are useful (or at least harmless). No need to block them.

What About BitSight?

In the previous session, I blocked the BitSight bot (USA) via .htaccess — it was methodically brute-forcing dictionary paths and flooding the logs. Result: for August 27–28 — zero requests from BitSight. The block worked perfectly, the bot left and hasn't returned.

Final Blocked IPs Table

Key Takeaways

1. Bots never sleep. In two days, over 10 different attackers with different vectors hit a site with moderate traffic. This is the norm, not the exception.
2. The most dangerous attack is RCE via SP Page Builder. If the component had been installed with an outdated version, the site would have been compromised in seconds.
3. Backdoor hunting in /tmp/ is a sign that attackers are counting on already-hacked sites. Check your server.
4. A basic .htaccess blocks ~80% of the noise. Blocking WP paths, hidden files, and archives significantly reduces the load and log noise.
5. IP blocking works, but it's whack-a-mole. Better to close attack vectors than specific IPs.

What You Can Do Right Now

Minimum Joomla site security checklist:

• Remove unused components (SP Page Builder, JCE if not needed)
• Update everything installed to the latest versions
• Check /tmp/ and uploads/ for suspicious PHP files
• Configure .htaccess (block archives, hidden files, WP paths)
• Protect the admin panel — lock down the admin area with a secret key so bots can't even reach the login forms

It's exactly for that last point that I created the Safe Admin Pro plugin. It adds a secret key to the admin panel URL — without the correct key, access to /administrator is impossible, and attempts are logged with country detection and auto-ban. No bot will see the login form, be able to brute-force passwords, or exploit admin-level vulnerabilities.

The logs above show: bots are knocking on /administrator/components/, looking for JCE, trying com_jce — all of this happens inside the admin area. If the admin panel is locked behind a key — they won't even know what's in there.