WordPress Security Review Skill

Overview

Systematic security code review for WordPress themes, plugins, and custom code. Core principle: Scan for critical vulnerabilities first (SQL injection, XSS, authentication bypass), then authorization issues, then hardening opportunities. Report with line numbers and severity levels.

When to Use

Use when:

• Reviewing PR/code for WordPress theme or plugin security
• User reports suspected hack, malware, or security breach
• Auditing before public release or security certification
• Checking authentication, authorization, or capability checks
• Investigating suspicious code or backdoors

Don't use for:

• Performance-only reviews (use wp-performance-review)
• General PHP code review not specific to WordPress
• Server/infrastructure security (focus is on code)

Code Review Workflow

1. Identify file type and apply relevant checks below
2. Scan for critical vulnerabilities first (SQLi, XSS, RCE, auth bypass)
3. Check authorization issues (missing capability checks, IDOR)
4. Note hardening opportunities (security headers, configuration)
5. Report with line numbers using output format below

OWASP Top 10 WordPress Mapping

File-Type Specific Checks

Plugin/Theme PHP Files (functions.php, plugin.php, *.php)

Scan for:

• $_GET, $_POST, $_REQUEST without sanitization → CRITICAL: Input validation
• $wpdb->query() with string concatenation → CRITICAL: SQL injection
• echo, print without escaping → CRITICAL: XSS vulnerability
• Missing wp_verify_nonce() in form handlers → CRITICAL: CSRF
• Missing current_user_can() before privileged actions → CRITICAL: Auth bypass
• eval(), assert(), create_function() → CRITICAL: Code execution
• unserialize() with user input → CRITICAL: Object injection
• include, require with user input → CRITICAL: LFI/RFI

Database Operations

Scan for:

• $wpdb->prepare() not used with variables → CRITICAL: SQL injection
• esc_sql() used instead of prepare() → WARNING: Prefer prepare()
• LIKE queries without $wpdb->esc_like() → WARNING: Wildcard injection
• Direct table creation without dbDelta() → INFO: Schema management

AJAX & REST Handlers

Scan for:

• wp_ajax_nopriv_* without rate limiting → WARNING: Abuse potential
• Missing permission_callback in REST routes → CRITICAL: Auth bypass
• 'permission_callback' => '__return_true' → WARNING: Public endpoint
• Missing nonce in AJAX actions → CRITICAL: CSRF vulnerability

File Operations

Scan for:

• file_get_contents(), file_put_contents() with user paths → CRITICAL: Path traversal
• move_uploaded_file() without validation → CRITICAL: Arbitrary upload
• Missing MIME type validation → WARNING: Upload bypass
• unlink(), rmdir() with user input → CRITICAL: Arbitrary deletion

Authentication & Sessions

Scan for:

• Custom authentication instead of wp_authenticate() → WARNING: Security bypass
• wp_set_auth_cookie() without proper validation → CRITICAL: Auth bypass
• Session handling outside WordPress → WARNING: Session fixation
• Plain text password storage → CRITICAL: Credential exposure

External Requests

Scan for:

• wp_remote_get() with user-supplied URL → CRITICAL: SSRF
• Missing URL validation before requests → WARNING: SSRF potential
• allow_redirects => true with external URLs → WARNING: Open redirect

Cron & Scheduled Tasks

Scan for:

• Cron hook name same as internal do_action() in callback → CRITICAL: Infinite recursion (DoS)
• wp_schedule_event() without wp_next_scheduled() check → WARNING: Duplicate events
• Missing wp_clear_scheduled_hook() on deactivation → WARNING: Orphaned events
• Long-running cron without set_time_limit() → WARNING: Timeout issues
• Cron callbacks without try-catch → WARNING: Silent failures

Detection pattern for infinite recursion:

// Check if any cron hook name matches a do_action() call in its callback
// Example: wp_schedule_event( time(), 'hourly', 'my_hook' );
//          add_action( 'my_hook', 'callback' );
//          function callback() { do_action( 'my_hook' ); 

...