Someone's Been Using Our Website, It Wasn't Us!
We noticed something odd this week. A Google search for "fusion event services" returned our website as expected — but one of the results underneath it was showing what appeared to be Thai gambling promotions. In Thai. On our domain. That was unexpected.
If you've ever seen something like this and assumed the site had been hacked in some dramatic, obvious way — think defaced homepage, skull and crossbones, ransom message — the reality is actually far less cinematic and considerably more annoying. The site itself looked completely fine when we loaded it. No visible changes, no missing content, no warning messages. It rendered perfectly. Which, it turns out, was entirely the point.
What Actually Happened
What we were looking at is a technique called cloaking. The malicious code that had been planted on our server was designed to detect who was asking for a page. If a real human visitor loaded the site in a browser, they'd see the normal Fusion Event Services website exactly as intended. But if a search engine crawler — Google, Bing, and so on — sent a request, the server would serve up something completely different: thousands of dynamically generated pages promoting Thai online gambling and slot machines, all indexed under our domain name, all invisible to us during normal use.
The end goal is straightforward. By hijacking a legitimate domain (ours, in this case) and feeding search engines thousands of spam pages under it, the people behind this gain search engine credibility they haven't earned. Our established domain — with years of genuine content and real traffic behind it — becomes a vehicle for their gambling spam. Clicks from Google go to fusioneventservices.co.uk/th/[whatever-keyword], which then redirects real visitors silently to a gambling site. Nobody benefits except the people running the scam. We get the reputational damage and the mess to clean up.
How They Got In
This part is worth explaining properly because it's not about us having a weak password or ignoring updates for years. It was a specific, known vulnerability in a third-party extension we had installed on the site.
Our website runs on Joomla, a popular content management system. Alongside it we had an extension called JCE (Joomla Content Editor) — a widely-used, well-regarded plugin that replaces Joomla's built-in text editor with something considerably more capable. JCE is genuinely good software, used on hundreds of thousands of sites worldwide.
In early June 2026, a critical vulnerability was publicly disclosed — CVE-2026-48907 — affecting every version of JCE up to and including 2.9.99.4. The severity rating was the maximum possible: CVSS 10.0. What made this particularly nasty is that it required no login whatsoever. An attacker didn't need our admin password, didn't need to guess any credentials, didn't need to trick anyone into clicking anything. They could simply send a crafted HTTP request to a specific endpoint on any Joomla site running an unpatched version of JCE, and the extension would allow them to upload and execute arbitrary code on the server.
We were running JCE 2.9.99. The patch was released on the 3rd of June. The attack on our server appears to have occurred on the 11th of June, eight days later. In internet security terms, that is not a long window at all.
What They Left Behind
Digging into the server, we found two things that didn't belong there.
The first was a webshell — a PHP file sitting inside our images folder with a random 16-character hex filename: 830e312ed51eb31e.php. This is the attacker's persistent access point. Once uploaded, it gave them the ability to run any command on the server via a simple HTTP request, completely bypassing normal authentication. The file itself was wrapped in layers of obfuscation — fake-looking class names designed to resemble legitimate framework code, with the actual malicious payload hidden inside a base64-encoded blob that only decoded at runtime. A surface scan of the file would look almost plausible if you didn't know what you were looking at.
The second was the actual spam infrastructure itself: a directory called /th/ (Thai content) containing a single PHP file almost 4MB in size. Inside it: an enormous embedded array of Thai gambling phrases, page title variations, promotional slogans, and bonus offer descriptions, all used to dynamically generate unique-looking spam pages on demand. The file also pulled in a remote tracking script from a Cloudflare R2 storage bucket and redirected real human visitors to an external gambling site. Every time a search engine crawled any URL under /th/, it got a freshly generated gambling page. Every time a real person clicked a search result, they were silently redirected.
The webshell was created at 04:25 on the 11th of June. The spam infrastructure was dropped five hours later at 09:33, when the attacker came back via the webshell and set everything up in a single automated session. By that point, the site had been serving spam to search engine crawlers for weeks before we noticed via a routine Google search.
The Scale of It
Once we started digging through the server logs, the picture became considerably larger than one bad actor with a grudge.
Across just 14 days of retained log history, we found 39 distinct IP addresses that had attempted the exact same JCE exploit against our server, generating roughly 33,000 individual exploit attempts between them. These weren't humans sitting at keyboards — they were automated scanning tools running continuously, probing every Joomla site they could find for the vulnerable endpoint.
The most persistent single source made 14,438 requests to the exploit endpoint over the retained log window and was still actively scanning at the time we found it. Another IP had made 14,194 attempts across a concentrated three-day period. A third had been running continuously for essentially the entire 14-day window we could see.
CISA (the US Cybersecurity and Infrastructure Security Agency) had already added CVE-2026-48907 to their Known Exploited Vulnerabilities catalogue by this point — meaning it was already being actively weaponised at scale across the internet. The window between "patch released" and "automated tools actively exploiting unpatched sites" was measured in days.
What We Did About It
Once we understood what we were looking at, the remediation was methodical.
First, we immediately neutralised both malicious files — removing execute permissions so they couldn't run even if requested — and confirmed there were no additional backdoors or webshells elsewhere on the server by sweeping the entire web root for suspicious patterns.
We patched JCE to version 2.9.99.7 — the current release — which correctly validates and rejects the malicious profile import that the exploit relies on. Then we rotated every credential associated with the site: admin panel password, database password, server login, and the Joomla session secret key.
We then went through every other site we operate on the same and related servers, checking for the same vulnerable extension. We found one other installation with an older version of JCE on a server we'd been meaning to decommission — that one was disabled entirely while we rationalise the infrastructure.
Finally, we extended our log retention from 14 days to 90 days going forward, and configured automated intrusion detection across three categories:
- Known exploit endpoints — a single request to any recognised attack path results in an immediate permanent block on all ports and protocols. One strike.
- Aggressive scanning — any IP generating requests for non-existent pages is permanently blocked across all ports. The automated scanners that use noisy, fast probing effectively ban themselves the moment they start.
- SSH brute-forcing — same permanent all-ports block for repeated failed login attempts.
The practical effect: any automated tool that probes this server for vulnerabilities permanently cuts off its own access before it can gather useful information. The approach that works against unprotected servers — blast thousands of requests as fast as possible — is precisely what triggers an instant permanent ban here.
The Broader Picture
This wasn't a targeted attack on Fusion Event Services specifically. Nobody sat down and decided they wanted to compromise our website in particular. This is mass exploitation at scale — automated tools scanning vast swathes of the internet for sites running known-vulnerable software, exploiting them the moment they're found, and moving on.
The lesson isn't really about anything we did wrong in a dramatic sense. It's simply that the window between "vulnerability publicly disclosed" and "automated tools actively exploiting it across the internet" is now measured in days, not weeks or months. The practical takeaway, both for us going forward and for anyone else running a CMS-based website: third-party extensions need the same update discipline as the core platform. JCE is good software, well maintained, and the patch was released promptly. The gap was simply that we hadn't applied it yet.
The spam pages have been removed from Google's index. The site is clean, patched, and now considerably better defended than it was before any of this started. Every cloud, and all that.
Fusion Event Services provides technical production services across South East England. If you've spotted anything odd on our site or have questions about this incident, you're welcome to get in touch via our normal contact channels.