| Version | Supported |
|---|---|
| 2.x | ✅ Current release |
Do not open a public GitHub Issue for security vulnerabilities.
Please report security issues privately by emailing:
Include in your report:
- A description of the vulnerability
- Steps to reproduce or a proof-of-concept
- The potential impact
- Any suggested remediation if you have one
- Acknowledgement within 72 hours
- A status update within 7 days
- A patch released as soon as practicable, typically within 14 days for critical issues
- Credit in the changelog if you would like it
Metamanager's attack surface to be aware of:
The wp-content/metamanager-jobs/ directories contain JSON files with image file paths and metadata. Each directory has an .htaccess with Deny from all to prevent direct HTTP access. Ensure your web server honours .htaccess files.
The daemons run under systemd as the web-server user detected at install time by metamanager-install.sh (e.g. www-data on Debian/Ubuntu, wordpress or apache on RHEL/AlmaLinux/Rocky). They execute jpegtran, optipng, cwebp, ffmpeg, and exiftool with arguments derived from the job JSON. File paths in job files are written by PHP (which sanitises input) and are not user-controllable from the public web. The service files include NoNewPrivileges=true.
All REST endpoints under /wp-json/metamanager/v1/ enforce WordPress capability checks and nonce validation. A summary:
| Endpoint | Method | Capability |
|---|---|---|
/stats |
GET | edit_others_posts |
/jobs |
GET | edit_others_posts |
/jobs/{id} |
GET | edit_others_posts |
/attachment/{id}/status |
GET | upload_files |
/attachment/{id}/compress |
POST | edit_others_posts |
/compression-status |
POST | upload_files |
All endpoints also validate a X-WP-Nonce header or cookie on every request. The entire API can be disabled, or restricted to a list of allowed IP addresses, from Media → MM Settings → REST API — blocked requests receive 403 Forbidden before any WordPress capability check runs.
All AJAX actions verify nonces via check_ajax_referer() before processing. Re-queue and clear-history require upload_files and manage_options capabilities respectively.
All database queries use $wpdb->prepare() or parameterised inserts with format arrays. No raw SQL is constructed from user input.
The following are in scope for security reports:
- Remote code execution
- Privilege escalation (e.g. non-admin user triggering admin actions)
- Unauthenticated access to job queue data
- SQL injection
- Stored or reflected XSS in admin pages
- Path traversal in daemon scripts
The following are out of scope:
- WordPress core vulnerabilities
- Server misconfiguration (e.g.
AllowOverride Noneignoring.htaccess) - Issues requiring physical server access