claude-plugin-wordpress-manager 1.5.0 → 1.7.1

package/skills/wp-security/references/incident-response.md

@@ -0,0 +1,144 @@
+# Incident Response
+
+Use this file when responding to a suspected or confirmed WordPress site compromise.
+
+## Signs of compromise
+
+- Unknown admin user accounts appeared
+- Core files modified (checksums don't match)
+- Suspicious cron jobs in `wp_options` → `cron` entry
+- SEO spam injected into posts or pages
+- Visitors redirected to malicious sites
+- Google Search Console security warnings
+- Hosting provider notifications about malware
+- Unexpected file changes (new `.php` files in uploads, modified theme files)
+- Unexplained outgoing network traffic
+- Database entries with encoded/obfuscated content
+
+## Phase 1: Containment (immediate)
+
+1. **Change all passwords** — WordPress admin, database, FTP/SSH, hosting panel:
+   ```bash
+   wp user update admin --user_pass=NEW_STRONG_PASSWORD
+   ```
+
+2. **Revoke all sessions** — force all users to re-authenticate:
+   ```bash
+   wp user session destroy --all
+   ```
+
+3. **Regenerate security keys** — invalidates all existing cookies:
+   ```bash
+   wp config shuffle-salts
+   ```
+
+4. **Enable maintenance mode** (if the site is actively harmful):
+   ```bash
+   wp maintenance-mode activate
+   ```
+
+5. **Revoke application passwords**:
+   ```bash
+   wp user application-password delete admin --all
+   ```
+
+## Phase 2: Investigation
+
+1. **Verify core file integrity**:
+   ```bash
+   wp core verify-checksums
+   ```
+
+2. **Find recently modified files**:
+   ```bash
+   find /var/www/html -type f -mtime -7 -name "*.php" -ls
+   ```
+
+3. **Search for common malware signatures**:
+   ```bash
+   grep -rl "eval(base64_decode" /var/www/html/
+   grep -rl "eval(gzinflate" /var/www/html/
+   grep -rl "preg_replace.*e'" /var/www/html/
+   grep -rl "assert(" /var/www/html/wp-content/
+   ```
+
+4. **Check cron jobs for suspicious entries**:
+   ```bash
+   wp cron event list
+   ```
+
+5. **Review access logs** for the attack timeline:
+   ```bash
+   grep "POST" /var/log/apache2/access.log | grep -E "(wp-login|xmlrpc|admin-ajax)" | tail -100
+   ```
+
+6. **Check for unknown admin users**:
+   ```bash
+   wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
+   ```
+
+## Phase 3: Remediation
+
+1. **Remove malicious code** identified in investigation:
+   ```bash
+   # Delete unknown files in uploads
+   find /var/www/html/wp-content/uploads -name "*.php" -delete
+   ```
+
+2. **Reinstall WordPress core**:
+   ```bash
+   wp core download --force --skip-content
+   ```
+
+3. **Update all plugins and themes**:
+   ```bash
+   wp plugin update --all
+   wp theme update --all
+   ```
+
+4. **Remove inactive plugins and themes**:
+   ```bash
+   wp plugin delete $(wp plugin list --status=inactive --field=name)
+   wp theme delete $(wp theme list --status=inactive --field=name)
+   ```
+
+5. **Review database** for injected content:
+   ```bash
+   wp db search "<script" --regex
+   wp db search "eval(" --regex
+   ```
+
+6. **Check `.htaccess`** for malicious redirects — compare against WordPress default.
+
+## Phase 4: Recovery
+
+If a clean backup exists and is more reliable than manual cleanup:
+
+```bash
+# Restore from backup
+wp db import clean-backup.sql
+# Then re-apply only the security hardening steps
+```
+
+Post-recovery hardening:
+1. Apply all steps from `filesystem-hardening.md`
+2. Apply all steps from `wp-config-security.md`
+3. Install a security monitoring plugin (Wordfence, Sucuri)
+4. Set up file integrity monitoring
+
+## Phase 5: Post-incident
+
+1. **Document the timeline** — when the breach occurred, when detected, actions taken
+2. **Identify the attack vector** — vulnerable plugin, weak password, unpatched core
+3. **Update security procedures** — add the missing controls that allowed the breach
+4. **Notify affected users** if personal data was exposed (GDPR, state laws may require this)
+5. **Request Google review** if the site was flagged in Search Console
+6. **Monitor** for re-infection over the following 30 days
+
+## When to engage professionals
+
+- Malware persists after cleanup (re-infection)
+- Database contains encrypted/obfuscated payloads you can't decode
+- Hosting provider requires professional remediation report
+- Legal obligations require forensic analysis
+- Site handles payments or sensitive personal data

package/skills/wp-security/references/user-capabilities.md

@@ -0,0 +1,115 @@
+# User Capabilities Audit
+
+Use this file when auditing and managing WordPress user accounts, roles, and capabilities.
+
+## Default WordPress roles
+
+| Role | Key capabilities |
+|------|-----------------|
+| Super Admin | Multisite: all capabilities across all sites |
+| Administrator | `manage_options`, `install_plugins`, `edit_users`, `delete_users` |
+| Editor | `publish_pages`, `edit_others_posts`, `manage_categories` |
+| Author | `publish_posts`, `edit_published_posts`, `upload_files` |
+| Contributor | `edit_posts` (cannot publish), `read` |
+| Subscriber | `read` only |
+
+## Audit administrator accounts
+
+Best practice: 1-2 administrator accounts maximum.
+
+```bash
+# List all administrators
+wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
+
+# Count administrators
+wp user list --role=administrator --format=count
+```
+
+Flags for review:
+- More than 2 administrators
+- Generic usernames: `admin`, `administrator`, `test`, `user`
+- Email addresses from external domains
+- Accounts not used in 90+ days
+
+## Find dormant accounts
+
+```bash
+# List users who haven't logged in recently (requires user meta tracking)
+wp user list --fields=ID,user_login,user_registered --format=table
+
+# List all users by role
+wp user list --role=subscriber --format=count
+wp user list --role=contributor --format=count
+```
+
+Remove or downgrade dormant accounts:
+```bash
+# Downgrade to subscriber
+wp user set-role <user_id> subscriber
+
+# Delete user (reassign content to admin)
+wp user delete <user_id> --reassign=1
+```
+
+## Custom roles
+
+```php
+// Add a custom role
+add_role('shop_manager', 'Shop Manager', [
+    'read'           => true,
+    'edit_posts'     => true,
+    'publish_posts'  => true,
+    'manage_woocommerce' => true,
+]);
+
+// Remove a role
+remove_role('shop_manager');
+```
+
+## Custom capabilities
+
+```php
+// Grant a capability to a role
+$role = get_role('editor');
+$role->add_cap('manage_custom_settings');
+
+// Remove a capability
+$role->remove_cap('manage_custom_settings');
+
+// Grant to a specific user
+$user = get_userdata($user_id);
+$user->add_cap('view_reports');
+```
+
+## WP-CLI capability management
+
+```bash
+# List all capabilities for a role
+wp cap list administrator
+
+# Add capability to role
+wp cap add editor manage_custom_settings
+
+# Remove capability from role
+wp cap remove editor manage_custom_settings
+```
+
+## Principle of least privilege
+
+Guidelines:
+1. **Content creators** → Author role (can only edit/publish their own posts)
+2. **Content managers** → Editor role (can edit all content, no admin access)
+3. **Plugin managers** → Custom role with `install_plugins` but not `edit_users`
+4. **SEO managers** → Custom role with specific plugin capabilities
+5. **Developers** → Administrator only on staging/development; use deploy pipelines for production
+
+Never give administrator access for tasks that can be accomplished with a lower role.
+
+## Audit checklist
+
+- [ ] Administrator count is 1-2
+- [ ] No accounts with username "admin"
+- [ ] All admin email addresses are verified and current
+- [ ] No dormant accounts (inactive > 90 days) with elevated roles
+- [ ] Custom roles follow principle of least privilege
+- [ ] No unnecessary `unfiltered_html` capability (multisite: `DISALLOW_UNFILTERED_HTML`)

package/skills/wp-security/references/wp-config-security.md

@@ -0,0 +1,129 @@
+# wp-config.php Security Constants
+
+Use this file when securing WordPress configuration via `wp-config.php` constants.
+
+## Security keys and salts
+
+WordPress uses 8 security keys for cookie signing and nonce generation. Regenerate them if compromised:
+
+```php
+// Generate fresh keys at: https://api.wordpress.org/secret-key/1.1/salt/
+define('AUTH_KEY',         'unique-random-string');
+define('SECURE_AUTH_KEY',  'unique-random-string');
+define('LOGGED_IN_KEY',    'unique-random-string');
+define('NONCE_KEY',        'unique-random-string');
+define('AUTH_SALT',        'unique-random-string');
+define('SECURE_AUTH_SALT', 'unique-random-string');
+define('LOGGED_IN_SALT',   'unique-random-string');
+define('NONCE_SALT',       'unique-random-string');
+```
+
+**Check for defaults**: if any key contains `put your unique phrase here`, it must be replaced immediately.
+
+Via WP-CLI:
+```bash
+wp config shuffle-salts
+```
+
+## Database table prefix
+
+Default `wp_` prefix is widely known. Change for new installations:
+
+```php
+$table_prefix = 'wp8x_'; // Custom prefix
+```
+
+**Warning**: changing the prefix on an existing site requires renaming all database tables and updating `usermeta` and `options` entries.
+
+## Debug settings
+
+Production:
+```php
+define('WP_DEBUG', false);
+define('WP_DEBUG_LOG', false);
+define('WP_DEBUG_DISPLAY', false);
+```
+
+Development only:
+```php
+define('WP_DEBUG', true);
+define('WP_DEBUG_LOG', true);    // Logs to wp-content/debug.log
+define('WP_DEBUG_DISPLAY', false); // Don't show errors to visitors
+define('SCRIPT_DEBUG', true);     // Use unminified core scripts
+```
+
+**Risk**: `WP_DEBUG_DISPLAY true` in production exposes file paths and error details to attackers.
+
+## Force SSL for admin
+
+```php
+define('FORCE_SSL_ADMIN', true);
+```
+
+Ensures all admin and login pages use HTTPS.
+
+## Auto-update configuration
+
+```php
+// Enable automatic updates for minor releases (security patches)
+define('WP_AUTO_UPDATE_CORE', 'minor');
+
+// Or enable all automatic updates
+define('WP_AUTO_UPDATE_CORE', true);
+
+// Disable all automatic updates (manage manually)
+define('WP_AUTO_UPDATE_CORE', false);
+```
+
+Recommended: at least `'minor'` for security patches.
+
+## File modification controls
+
+```php
+// Disable theme/plugin editor in admin
+define('DISALLOW_FILE_EDIT', true);
+
+// Disable all file modifications (blocks installs, updates, editor)
+define('DISALLOW_FILE_MODS', true);
+```
+
+## Move wp-config above web root
+
+If your hosting allows it, move `wp-config.php` one directory above the web root:
+
+```
+/home/user/wp-config.php      ← Here (not web-accessible)
+/home/user/public_html/        ← Web root
+/home/user/public_html/wp-admin/
+/home/user/public_html/wp-content/
+```
+
+WordPress automatically checks the parent directory for `wp-config.php`.
+
+## Multisite security
+
+```php
+// Prevent administrators from using unfiltered HTML (important for multisite)
+define('DISALLOW_UNFILTERED_HTML', true);
+```
+
+## Database credentials
+
+Ensure database credentials in `wp-config.php` use a dedicated WordPress user with only the required privileges:
+
+```sql
+GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER
+ON wordpress_db.* TO 'wp_user'@'localhost' IDENTIFIED BY 'strong_password';
+```
+
+Never use the `root` MySQL user for WordPress.
+
+## Verification
+
+```bash
+# Check key constants via WP-CLI
+wp config get WP_DEBUG
+wp config get DISALLOW_FILE_EDIT
+wp config get FORCE_SSL_ADMIN
+wp config get table_prefix
+```