Drupal, Joomla, Magento Security: The Vulnerabilities Nobody Checks
WordPress gets all the security attention — but Drupal, Joomla and Magento have their own critical vulnerabilities. A breach on Magento means exposed credit cards. The stakes are enormous.
- Each CMS has files and endpoints exposed by default: CHANGELOG.txt (Drupal), configuration.php.bak (Joomla), /app/etc/local.xml (Magento) — visible without any admin access
- External audits (without back-office access) can detect most of these vulnerabilities — exactly as an attacker would during initial reconnaissance
- Orilyt's Batch 1 and 2 will add CMS-specific security tests — Joomla, Magento, PrestaShop, Drupal, OpenCart, all external, all automatic
WordPress absorbs all the attention in web security. Vulnerable plugins, outdated versions, brute-force attacks on wp-admin — everyone talks about it constantly. Meanwhile, Drupal, Joomla and Magento continue running government sites, university portals and e-commerce stores without anyone seriously auditing their security.
The stakes are enormous. A vulnerability on Magento potentially means exposed credit card numbers. On Drupal, it's government data at risk. On Joomla, it's customer databases within reach. Drupalgeddon in 2018 affected hundreds of thousands of sites — and similar patterns still exist today.
What makes the situation even more concerning: most of these vulnerabilities are detectable without any admin access, simply by looking at what the server exposes publicly. That's exactly what an attacker does during the reconnaissance phase. And it's what Orilyt is going to automate for your next audit.
Drupal — the enterprise giant's weak spots
Drupal powers ministries, universities and Fortune 500 companies. Its reputation for robustness is deserved — but it creates a false impression of automatic security. In reality, several attack vectors are accessible from the very first external reconnaissance.
Drupal keeps a CHANGELOG.txt file at the root that reveals the exact installed version. An attacker only needs this information to target specific CVEs. This file should be deleted or restricted in production.
The /update.php script allows updating the database after a Drupal upgrade. Left accessible without protection, it can be triggered by anyone — a classic vector for database schema manipulation.
The default administration path /user/login is easily identifiable. Combined with version detection via the meta generator tag (often present on default installations), this provides all the information needed for a targeted attack.
The Drupalgeddon case (SA-CORE-2018-002) remains emblematic: remote code execution without authentication, massively exploited within hours. The initial vulnerability was an SQL injection flaw — but it was the version exposure that allowed attackers to target unpatched sites with surgical precision.
Joomla — the forgotten middle child
Joomla occupies an uncomfortable position in the CMS ecosystem: popular enough to be an attractive target, ignored enough that its vulnerabilities go unnoticed. Millions of sites still run on Joomla 3.x — a branch that reached end of life in December 2023.
During updates or migrations, backup files of the main configuration are sometimes left accessible. configuration.php.bak — or configuration.php.old, configuration.bak.php — can contain database credentials in plain text.
Joomla's administration interface is accessible at /administrator/ by default. No path change is suggested during installation. This path is scanned first by automated attack bots.
Joomla often exposes its exact version via the meta generator tag. Worse: leaving debug mode enabled in production (configuration.php: $debug = 1) causes sensitive information to be displayed in error pages — server paths, SQL queries, session variables.
Joomla extensions are a major and often underestimated attack vector. Unlike WordPress which has a centralized repository with reporting systems, the Joomla ecosystem counts thousands of third-party extensions, many of which are no longer maintained. Known CVEs exist for extensions still widely deployed.
Magento — where money meets risk
Magento (Adobe Commerce) is the reference e-commerce CMS for high-volume stores. It's also one of the most lucrative targets for attackers. Magecart attacks — injecting malicious JavaScript into the checkout to capture card data — have affected thousands of Magento stores.
Magento 1.x exposed a downloader at /downloader/ allowing extension installation. Magento 2.x has its installation wizard at /setup/. These endpoints, left accessible after installation, are direct entry points for attackers.
The file /app/etc/local.xml (Magento 1) or /app/etc/env.php (Magento 2) contains database credentials, encryption keys and other secrets. A misconfigured server serving this file directly exposes the entire store's data.
Magento allows customizing the admin path during installation, but many deployments keep /admin/ or /index.php/admin/. Security patch management is also a problem: merchants often delay updates out of fear of breaking customizations, leaving critical CVEs unpatched for months.
Magecart attacks perfectly illustrate the reality of the risk: an attacker doesn't need admin access to cause catastrophic damage. A simple JavaScript injection into the checkout form — made possible by an unpatched version or vulnerable extension — is enough to exfiltrate all payment data.
PrestaShop and OpenCart — the e-commerce underdogs
PrestaShop and OpenCart don't get the same media coverage as Magento, but they power hundreds of thousands of online stores. Their vulnerabilities are all the more dangerous because they're rarely audited.
PrestaShop normally renames the admin folder during installation, but /admin-dev/ is sometimes left in place in development environments deployed to production. The files /app/config/parameters.php and /config/settings.inc.php contain database credentials.
OpenCart keeps /admin/ as the default path in most installations. More critically: config.php and admin/config.php files contain the absolute server path, database credentials and secret keys — and are sometimes readable directly from the browser on misconfigured servers.
A known SQL injection pattern affects several versions of OpenCart, particularly in product filtering modules. These vulnerabilities are documented and public PoCs exist — making exploitation trivial for any script kiddie with access to a search engine.
Why external audits catch what internal tools miss
The vast majority of CMS security tools require admin access or the installation of a monitoring plugin. This approach has a fundamental blind spot: it presupposes that the attacker cannot see what the tool doesn't look at.
An external audit tests what an attacker sees from the outside. No installation, no access, no dependencies. The server responds or it doesn't — and that response reveals everything.
The same HTTP requests as an offensive security scanner: looking for CHANGELOG.txt, testing /administrator/, requesting /app/etc/env.php. If an attacker can do it, the tool must do it.
The CMS version is often exposed in meta tags, HTTP headers, README files or versioned assets. Knowing the version without admin access is the first step of any targeted attack.
External auditing doesn't replace a thorough pentest — but it detects the low-hanging fruit that attackers look for first. In 80% of real intrusions, the entry point was publicly accessible information that nobody had thought to check.
Orilyt's multi-CMS security roadmap
Orilyt currently audits mainly WordPress sites. The next step — already in development — is to extend these capabilities to the most widely used CMS on the web. The approach remains the same: all external, all automatic, all actionable.
Joomla (configuration.php.bak, unprotected /administrator/, meta generator version), Magento (/downloader/, /setup/, /app/etc/local.xml), PrestaShop (/admin-dev/, parameters.php). These tests check exposure of the most dangerous files and endpoints.
Drupal (CHANGELOG.txt, update.php, version detection), OpenCart (exposed config.php, /admin/ without additional protection), Ghost (version in assets, exposed API endpoints). Tests combining CMS detection + sensitive file checks + header analysis.
All these tests will be available in the same Orilyt report you already know — with FIA recommendations (Fact, Impact, Action) ready to present to your clients. No extra configuration, no access required.
The blind spot you can close today
Non-WordPress CMS security is a massive blind spot in the web industry. Joomla, Magento or Drupal site owners often have a false sense of security because their CMS is "less targeted" than WordPress. This is dangerous reasoning: attackers adapt to the target, not the other way around.
For freelancers and agencies, this blind spot is an opportunity. Proposing a security audit to a Magento client who has never checked whether /app/etc/env.php is accessible — that's delivering immediate, demonstrable, tangible value. It's also potentially saving them from a catastrophe.
Orilyt will make these checks automatic. While waiting for Batches 1 and 2, existing WordPress tests already cover patterns common to all CMS: security headers, SSL, redirects, IP reputation. A complete audit remains an excellent starting point.