Back to Articles

Juumla: A Surgical Joomla Scanner for Red and Blue Teams

[ View on GitHub ]

Juumla: A Surgical Joomla Scanner for Red and Blue Teams

Hook

Over 2.5 million websites run Joomla CMS, yet most security teams reach for WordPress-focused tools or bloated web scanners when assessing them. Juumla proves that specialized reconnaissance wins.

Context

Joomla powers approximately 2% of all websites globally, making it the second most popular content management system after WordPress. Despite this ubiquity, security tooling for Joomla lags significantly behind WordPress equivalents. While WordPress has WPScan with a constantly updated commercial vulnerability database, Joomla administrators and security researchers have historically relied on generic web application scanners or aging Perl scripts with inconsistent maintenance.

This gap matters because Joomla’s architecture differs substantially from WordPress. Its extension system, file structure, and version fingerprinting techniques require specialized knowledge. Generic scanners waste time probing for WordPress paths while missing Joomla-specific endpoints. Juumla emerged to fill this niche: a Python-based CLI tool built specifically for Joomla reconnaissance, combining version detection with CVE correlation in a lightweight package suitable for both red team initial access and blue team asset inventory.

Technical Insight

Version Detected

CVE Matching

Sensitive Files

Admin Endpoints

CLI Interface

Target URL Input

Fingerprint Module

Check joomla.xml

Check language files

Check htaccess.txt

Regex Parser

Vulnerability Database

Scan Report

Path Enumeration

System architecture — auto-generated

Juumla’s architecture follows a modular scanning pipeline that prioritizes efficiency over comprehensiveness. The tool begins with passive fingerprinting, making targeted HTTP requests to version-revealing files rather than brute-forcing paths. It checks for administrator/manifests/files/joomla.xml first—the most reliable version indicator—then falls back to language/en-GB/en-GB.xml, htaccess.txt, and other markers specific to different Joomla releases.

The fingerprinting module uses regex patterns matched against HTTP response bodies. Here’s how a simplified version detection might look:

import requests
import re

def detect_joomla_version(target_url):
    version_indicators = [
        {
            'path': '/administrator/manifests/files/joomla.xml',
            'pattern': r'<version>([0-9.]+)</version>'
        },
        {
            'path': '/language/en-GB/en-GB.xml',
            'pattern': r'<version>([0-9.]+)</version>'
        },
        {
            'path': '/htaccess.txt',
            'pattern': r'# @version\s+([0-9.]+)'
        }
    ]
    
    for indicator in version_indicators:
        try:
            response = requests.get(
                f"{target_url}{indicator['path']}",
                timeout=10,
                allow_redirects=False
            )
            if response.status_code == 200:
                match = re.search(indicator['pattern'], response.text)
                if match:
                    return match.group(1)
        except requests.RequestException:
            continue
    
    return None

Once Juumla identifies a version, it cross-references against a local vulnerability database—essentially a JSON or YAML file mapping Joomla versions to known CVEs. This approach trades real-time accuracy for speed and offline capability. The database structure typically looks like {'3.4.0': ['CVE-2015-8562', 'CVE-2015-8769'], '3.9.0': ['CVE-2019-10945']}, allowing instant lookups without API calls.

The tool’s misconfiguration detection layer probes for common security failures: exposed configuration.php files, backup archives (configuration.php.bak, configuration.php~), accessible /administrator login pages without IP restrictions, and directory listing on /images or /media folders. This module operates independently of version detection, making it useful even when fingerprinting fails.

Juumla’s Docker integration deserves special attention. The repository includes not just a containerized scanner but also a deliberately vulnerable Joomla environment for testing. This dual-container approach lets security researchers validate detection signatures against known-vulnerable versions before deploying against production targets:

# Spin up vulnerable Joomla instance
docker-compose up -d joomla-vuln

# Run scanner against local test environment
docker-compose run juumla --url http://joomla-vuln

This testing harness solves a critical problem in scanner development: verifying that detection logic actually works without repeatedly hammering live websites. The vulnerable environment includes specific Joomla versions with known CVEs, allowing contributors to write regression tests for vulnerability signatures.

The codebase emphasizes low memory consumption and minimal dependencies. By avoiding heavy frameworks like Scrapy or Selenium, Juumla remains suitable for resource-constrained scenarios like scanning from a Raspberry Pi or embedding within CI/CD pipelines. The trade-off is reduced sophistication—no JavaScript rendering, no automatic CAPTCHA bypass, no authenticated scanning workflows.

Gotcha

Juumla’s most significant limitation is its vulnerability database maintenance model. Unlike commercial tools with dedicated research teams, Juumla relies on community contributions to update CVE mappings. The repository’s to-do list explicitly mentions database updates as incomplete, meaning recent Joomla vulnerabilities (particularly those disclosed in the last 12-18 months) may not trigger alerts. A Joomla 4.2.0 installation with CVE-2023-23752 (an unauthenticated information disclosure) might scan clean if the database hasn’t been updated.

The tool’s passive scanning philosophy also creates blind spots. Juumla won’t detect vulnerabilities requiring authentication, like privilege escalation bugs in the admin panel or SQL injection in authenticated endpoints. It can’t assess third-party extensions unless explicitly configured, missing a huge attack surface since most Joomla compromises exploit poorly coded plugins rather than core CMS bugs. Component enumeration—identifying installed extensions—exists in competitors like JoomScan but remains absent here. Additionally, the reliance on version fingerprinting fails when administrators harden installations by removing version markers from public files, a common security practice recommended in Joomla hardening guides.

Verdict

Use if: You need rapid Joomla reconnaissance during time-boxed engagements, want a lightweight scanner that runs in CI/CD pipelines or resource-constrained environments, or are building a security training lab and need both scanner and vulnerable target. Juumla excels at identifying obviously outdated Joomla installations and common misconfigurations during initial asset discovery. It’s perfect for bug bounty hunters performing quick triage across multiple targets or blue teams wanting to inventory Joomla versions across an estate without commercial tooling budgets. Skip if: You need comprehensive vulnerability assessment with current CVE coverage, must enumerate installed components and extensions, or require authenticated scanning capabilities. The outdated database means Juumla should augment, not replace, manual testing or tools like Nuclei with actively maintained Joomla templates. For production security assessments where missing a vulnerability has real consequences, combine Juumla’s speed with deeper tools or manual review.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/cybersecurity/0xdsm-juumla.svg)](https://starlog.is/api/badge-click/cybersecurity/0xdsm-juumla)