← Back to Cybersecurity News Center
Severity
CRITICAL
Priority
0.850
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
A critical vulnerability in the ThemeREX Addons WordPress plugin (CVE-2026-1969) allows any unauthenticated attacker to upload malicious files directly to affected web servers, bypassing all login requirements. Organizations running WordPress sites with the trx_addons plugin prior to version 2.38.5 face immediate risk of full server compromise, including data theft and ransomware deployment. CISA KEV and VulnCheck KEV both list this vulnerability with confirmed active exploitation, meaning attacks are occurring now, not hypothetically.
Impact Assessment
CISA KEV Status
EXPLOITED
Attack Vector
HIGH
Exploitable remotely over the internet
Complexity
HIGH
No special conditions required to exploit
Authentication
HIGH
No credentials needed — anyone can attempt
User Interaction
HIGH
Fully automated — no user action needed
Active Exploitation
CRITICAL
Confirmed in-the-wild by CISA KEV
Affected Product
INFO
ThemeREX Addons (trx_addons) WordPress plugin before version 2.38.5
Are You Exposed?
⚠
You use ThemeREX Addons (trx_addons) WordPress plugin before version 2.38.5 → Investigate immediately
⚠
Affected systems are internet-facing → Increased attack surface
⚠
Actively exploited in the wild (CISA KEV)
✓
You have patched to the latest version → Reduced risk
✓
Systems are behind network segmentation / WAF → Mitigated exposure
Business Context
A successful attack against an unpatched site hands the attacker full control of the web server, enabling theft of customer data, database contents, and credentials, as well as deployment of ransomware or use of the server in further attacks. WordPress sites frequently process customer contact forms, e-commerce transactions, or membership data, making a server compromise a potential trigger for breach notification obligations under GDPR, state privacy laws, or PCI-DSS depending on the site's function. With active exploitation confirmed by CISA, organizations that delay patching face not just technical risk but a demonstrated, ongoing threat.
You Are Affected If
You run the ThemeREX Addons (trx_addons) WordPress plugin version prior to 2.38.5 on any production WordPress instance
Your WordPress site is publicly accessible from the internet
The wp-admin/admin-ajax.php endpoint is reachable without WAF or IP-based access controls blocking unauthenticated external requests
You have not yet applied the patch released in trx_addons version 2.38.5
You applied a patch for CVE-2024-13448 but have not verified the fix was complete or re-validated after subsequent plugin updates
Board Talking Points
Attackers can compromise any of our public-facing WordPress sites running an unpatched ThemeREX plugin without needing a username or password — active attacks are confirmed by CISA.
Security teams should patch all affected WordPress installations to plugin version 2.38.5 or higher within 24 hours, or isolate affected sites until patching is complete.
Failure to patch leaves our web servers open to full takeover, including customer data theft and ransomware, with confirmed real-world exploitation already underway.
Technical Analysis
CVE-2026-1969 affects the ThemeREX Addons (trx_addons) WordPress plugin before version 2.38.5.
The flaw resides in an AJAX action handler that fails to validate file types (CWE-434: Unrestricted Upload of File with Dangerous Type), allowing unauthenticated HTTP POST requests to deposit arbitrary files, including PHP web shells, on the server.
This vulnerability is a failed patch regression: it results from an incomplete fix applied to CVE-2024-13448 , which addressed a prior file upload flaw in the same plugin.
Successful exploitation maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application) for initial access and T1505.003 (Server Software Component: Web Shell) for persistence. CVSS Base Score: 9.8 (Critical), confirmed by NVD assessment. The CVSS vector string is pending publication from authoritative sources; severity is corroborated by CISA KEV listing. The AJAX endpoint requires no authentication, making mass automated exploitation trivial. The vulnerability is listed in both CISA KEV and VulnCheck KEV, confirming in-the-wild exploitation. EPSS score is 0.00074 (22nd percentile) as of data collection, though KEV listing supersedes EPSS as a prioritization signal. Public IOCs (malicious IPs, file hashes, C2 domains) have not been published for this vulnerability as of the data collection date; prioritize detection of the attack vector (unauthenticated file upload) rather than known-bad indicators. Patch: upgrade to trx_addons version 2.38.5 or later.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to senior IR leadership and legal/compliance immediately if forensic evidence confirms a web shell was successfully deployed (HTTP 200 on upload request + PHP file present in wp-content/), any WordPress database containing PII or PHI was accessible from the compromised host, or if attacker-created administrator accounts are discovered — each condition independently triggers breach notification assessment obligations under applicable data protection regulations.
1
Step 1: Containment — Enumerate all WordPress instances running trx_addons prior to version 2.38.5 using your asset inventory. Block unauthenticated multipart/form-data POST requests to wp-admin/admin-ajax.php at the WAF or reverse proxy as an interim measure. Apply D3-PBWSAM (Proxy-based Web Server Access Mediation) at the perimeter to restrict AJAX endpoint access from unauthenticated sessions. (Cite: CIS 1.1 — Establish and Maintain Detailed Enterprise Asset Inventory / CIS 4.4 — Implement and Manage a Firewall on Servers / D3-PBWSAM)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST SI-2 (Flaw Remediation)
CIS 4.4 (Implement and Manage a Firewall on Servers)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Run 'wp plugin list --name=trx_addons --fields=name,version --format=csv' via WP-CLI across all managed WordPress sites, or scan wp-content/plugins/ directories with 'find /var/www -type d -name trx_addons -exec grep -r "Version:" {}/trx_addons.php \;' to enumerate installed versions. For WAF-less environments, use ModSecurity with a custom rule blocking POST to wp-admin/admin-ajax.php where the request body contains 'action=trx_addons' or known upload action strings (e.g., 'trx_addons_uploads', 'trx_addons_save_options'). As a last resort, add 'deny from all' for admin-ajax.php in .htaccess scoped to external IPs while allowlisting your admin IP range.
Preserve Evidence
Before applying WAF rules or any network-layer block, capture a snapshot of current active connections to port 80/443 on affected WordPress hosts using 'ss -tnp' or 'netstat -antp'; preserve web server access logs (Apache: /var/log/apache2/access.log; Nginx: /var/log/nginx/access.log) with timestamps intact. Export a directory listing with timestamps from wp-content/uploads/ and wp-content/plugins/trx_addons/ using 'find /var/www/html/wp-content -name "*.php" -newer /var/www/html/wp-content/plugins/trx_addons/trx_addons.php -ls' to establish a pre-containment file system baseline.
2
Step 2: Detection — Search web server access logs (AU-2, AU-3) for POST requests to wp-admin/admin-ajax.php originating from unauthenticated external sessions with multipart/form-data content and trx_addons action parameters. Enable file system monitoring aligned with D3-SFA (System File Analysis) to alert on creation of .php files in wp-content/uploads/ or trx_addons plugin subdirectories. Alert on PHP process spawning child processes (shell, curl, wget) as a web shell execution indicator. (Cite: NIST AU-2 — Event Logging / NIST AU-3 — Content Of Audit Records / CIS 8.2 — Collect Audit Logs / D3-SFA)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-12 (Audit Record Generation)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
Query Apache/Nginx access logs with: 'grep -E "POST.*admin-ajax\.php" /var/log/apache2/access.log | grep -i "trx_addons"' to surface exploit attempts. For web shell discovery, run 'find /var/www/html/wp-content -name "*.php" -newer /var/www/html/wp-login.php -not -path "*/trx_addons/*" -ls' to flag PHP files created outside the plugin's own directory after the plugin install date. Use YARA with a rule targeting PHP web shell patterns (e.g., eval(base64_decode), system(), shell_exec()) against wp-content/uploads/ — the Laudanum or NeoPI YARA rulesets cover common web shell signatures. For network-based detection, deploy a Sigma rule matching HTTP 200 responses to POST requests at admin-ajax.php from external IPs where the response body size exceeds 0 bytes (indicating successful upload acknowledgment). MITRE ATT&CK T1190 (Exploit Public-Facing Application) and T1505.003 (Server Software Component: Web Shell) are the relevant techniques for detection tuning.
Preserve Evidence
Preserve raw web server access logs before any log rotation occurs — specifically look for HTTP 200 responses to POST /wp-admin/admin-ajax.php containing action parameters associated with trx_addons file handling. Capture PHP error logs (/var/log/php_errors.log or as configured in php.ini) for stack traces that may reveal the upload handler function invoked. Run 'find /var/www/html/wp-content/uploads -name "*.php" -o -name "*.phtml" -o -name "*.php5"' and hash all discovered files with 'md5sum' or 'sha256sum' for integrity evidence. Preserve WAF logs if present, retaining the full URI, POST body, source IP, user-agent, and response code for each request targeting admin-ajax.php.
3
Step 3: Eradication — Update trx_addons to version 2.38.5 or later via WordPress admin or WP-CLI to remediate CVE-2026-1969. Remove any discovered PHP web shells from wp-content/. Apply D3-CRO (Credential Rotation): rotate all WordPress admin, database, and hosting credentials. Audit all WordPress user accounts for unauthorized additions per AC-2 (Account Management) and remove any accounts not present in your authorized account inventory. (Cite: NIST AC-2 — Account Management / CIS 7.4 — Perform Automated Application Patch Management / CIS 5.1 — Establish and Maintain an Inventory of Accounts / D3-CRO)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST SI-2 (Flaw Remediation)
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 7.4 (Perform Automated Application Patch Management)
Compensating Control
Apply the patch via WP-CLI: 'wp plugin update trx_addons --version=2.38.5' and verify with 'wp plugin get trx_addons --field=version'. Because CVE-2026-1969 is a regression from CVE-2024-13448, diff the upload-related functions in the new 2.38.5 plugin files against 2.38.4 using 'diff -rq wp-content/plugins/trx_addons/includes/ <patched_copy>/includes/' to confirm the file upload validation code was actually reinstated. For credential rotation without a password manager, use 'wp user update <user_id> --user_pass=<newpassword>' for all WordPress admin accounts and regenerate the WordPress secret keys in wp-config.php using the WordPress.org secret key generator (https://api.wordpress.org/secret-key/1.1/salt/). Audit WordPress user accounts with 'wp user list --role=administrator --fields=ID,user_login,user_email,user_registered' and flag any accounts registered after the earliest possible exploit date.
Preserve Evidence
Before removing any discovered web shell, preserve a forensic copy: capture the file with 'cp -p <webshell_path> /secure/evidence/' retaining original timestamps, then hash it ('sha256sum'), and record the full directory listing showing creation time. Capture the WordPress database user table snapshot with 'wp user list --all --format=json > user_audit_pre_eradication.json' to document any attacker-created administrator accounts. Export wp-config.php (read-only copy) to preserve database credentials that may need forensic correlation with database access logs. Review MySQL/MariaDB query logs or binary logs for any queries executed via the web shell (look for INSERT into wp_users or option updates to wp_siteurl) — binary log path is typically /var/lib/mysql/mysql-bin.* .
4
Step 4: Recovery — Confirm trx_addons version 2.38.5 or later in the WordPress Plugins panel. Re-scan the server file system using a file integrity monitoring tool per D3-SFA (System File Analysis) to detect residual web shells. Apply D3-FMBV (File Magic Byte Verification) to validate that files in upload directories match declared MIME types and lack PHP executable content. Monitor web server logs (AU-6) and WAF alerts for continued exploitation attempts for at least 72 hours post-remediation. Retain all relevant log data per AU-11 (Audit Record Retention) to support post-incident analysis. (Cite: NIST AU-6 — Audit Record Review, Analysis, And Reporting / NIST AU-11 — Audit Record Retention / D3-SFA / D3-FMBV)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 7.2 (Establish and Maintain a Remediation Process)
CIS 7.3 (Perform Automated Operating System Patch Management)
Compensating Control
Verify the patch with 'wp plugin get trx_addons --field=version' and cross-reference against the trx_addons changelog at wordpress.org/plugins/trx-addons/#developers to confirm 2.38.5 addresses the file upload validation regression. For file integrity validation without a commercial FIM tool, run 'find /var/www/html/wp-content -name "*.php" -newer /var/www/html/wp-content/plugins/trx_addons/trx_addons.php' daily for 72 hours and compare output against your pre-patch baseline hash list. Set up a lightweight cron-based monitor: 'crontab -e' with '*/15 * * * * grep -c "POST.*admin-ajax" /var/log/nginx/access.log >> /var/log/trx_monitor.log' to track continued POST volume against the endpoint. Use WPScan (free tier) with 'wpscan --url https://yoursite.com --enumerate p --plugins-detection aggressive' to confirm no residual vulnerable plugin state.
Preserve Evidence
Capture a post-patch plugin version confirmation screenshot or CLI output and store it as a timestamped remediation record per NIST IR-5 (Incident Monitoring) documentation requirements. Preserve all web server access logs from the 72-hour post-remediation monitoring window — any continued POST requests to admin-ajax.php with trx_addons action parameters after patching may indicate a second attacker or a persistence mechanism not yet eradicated. Generate a final file system scan report from the wp-content/ tree using 'find /var/www/html/wp-content -name "*.php" | xargs md5sum > post_remediation_hashes.txt' and store alongside the pre-eradication baseline for comparison.
5
Step 5: Post-Incident — Review WordPress plugin update workflow. This vulnerability is a failed patch regression from CVE-2024-13448, indicating the prior fix was not validated. Align plugin patching to CIS 7.2 (Establish and Maintain a Remediation Process) with mandatory regression validation before closing CVEs in plugins with prior file upload history. Evaluate unauthenticated AJAX endpoints across your WordPress estate; implement standing WAF rules per CIS 4.4 (Implement and Manage a Firewall on Servers) and D3-EBWSAM (Endpoint-based Web Server Access Mediation). Update your software inventory per CIS 2.1 to reflect the patched plugin version and document the exception process for any instances that cannot be immediately patched. (Cite: CIS 7.1 — Establish and Maintain a Vulnerability Management Process / CIS 7.2 — Establish and Maintain a Remediation Process / CIS 2.1 — Establish and Maintain a Software Inventory / CIS 4.4 — Implement and Manage a Firewall on Servers / D3-EBWSAM)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST SI-2 (Flaw Remediation)
NIST SI-5 (Security Alerts, Advisories, and Directives)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Conduct a lessons-learned session specifically examining the CVE-2024-13448 patch closure record — document why regression testing did not catch the re-introduction of the unauthenticated upload path in versions between 2.x and 2.38.4. Build a standing YARA rule and Sigma detection for unauthenticated PHP file upload attempts via WordPress AJAX (action parameters containing 'upload', 'save', 'import', or 'file') and deploy it as a permanent WAF or ModSecurity rule across all WordPress hosts. Add trx_addons to a monitored plugin watchlist using WPScan's API (free tier, 25 requests/day) with a scheduled weekly check: 'wpscan --url https://yoursite.com --api-token <token> --enumerate vp'. For the AJAX endpoint audit, enumerate all registered unauthenticated AJAX actions with 'grep -r "add_action.*wp_ajax_nopriv" /var/www/html/wp-content/plugins/ --include="*.php" -l' to surface other potential attack surface across your WordPress estate.
Preserve Evidence
Retain the complete incident timeline, all preserved log files, web shell forensic copies, and credential rotation records in a closed incident package per NIST IR-5 (Incident Monitoring) and NIST AU-11 (Audit Record Retention) requirements — minimum 90-day retention recommended given active exploitation status. Document the regression delta between CVE-2024-13448's patch and CVE-2026-1969's re-introduction, including the specific trx_addons PHP functions responsible for file type validation, as this evidence justifies workflow process changes and may be required for regulatory breach notification documentation if PII was accessible on the affected WordPress instance.
Recovery Guidance
Before declaring recovery complete, verify that trx_addons version 2.38.5 is confirmed installed and that the specific file upload validation functions patched in this release are present in the deployed code — do not rely solely on the version number given this vulnerability's regression history from CVE-2024-13448. Monitor web server access logs for POST requests to wp-admin/admin-ajax.php with trx_addons action parameters for a minimum of 72 hours post-patch, as active exploitation confirmed by CISA means automated scanning tools may continue probing patched endpoints. If a web shell was confirmed deployed at any point, treat the entire WordPress hosting environment (database, credentials, adjacent virtual hosts) as compromised and conduct a full credential rotation and lateral movement assessment before resuming normal operations.
Key Forensic Artifacts
Web server access logs (Apache: /var/log/apache2/access.log; Nginx: /var/log/nginx/access.log) — filter for HTTP POST requests to /wp-admin/admin-ajax.php with action parameters containing 'trx_addons', particularly requests from external IPs receiving HTTP 200 responses, which indicate successful AJAX handler invocation and potential successful file upload.
File system scan of wp-content/uploads/ and wp-content/plugins/trx_addons/ for PHP files with extensions .php, .phtml, .php5, .phar — this exploit deposits web shells in the uploads directory (world-writable by design) or plugin subdirectories; use 'find /var/www/html/wp-content -name "*.php" -newer <plugin_install_date> -ls' to surface post-exploitation artifacts.
WordPress database wp_users and wp_usermeta tables — attacker-created administrator accounts are a common post-exploitation persistence mechanism following web shell deployment via unauthenticated upload; export with 'wp user list --role=administrator --format=json' and cross-reference registration timestamps against the earliest confirmed exploit window.
PHP error log (/var/log/php_errors.log or php.ini error_log path) — failed upload attempts and successful but partially broken web shell executions generate stack traces referencing trx_addons upload handler functions, providing evidence of exploit attempts even when the web server access log POST entry alone is ambiguous.
WAF logs and ModSecurity audit log (/var/log/modsec_audit.log) — if WAF was active during exploitation attempts, the full POST body captured in WAF logs may contain the uploaded file content (web shell source), the multipart form-data boundary, and the original attacker filename, all of which constitute primary forensic evidence of the payload delivered via CVE-2026-1969.
Detection Guidance
Primary detection target: unauthenticated POST requests to wp-admin/admin-ajax.php on WordPress servers running trx_addons prior to version 2.38.5.
NIST AU-2 (Event Logging) requires that POST requests to AJAX endpoints, including source IP, authentication state, action parameter, and response code, be captured in web server access logs.
NIST AU-3 (Content Of Audit Records) requires those records establish what occurred, when, where, the source, and the outcome — ensure logs capture the full request URI, action parameter value, session authentication cookies (or absence thereof), and HTTP response code.
Using CIS 8.2 (Collect Audit Logs), confirm logging is enabled across all WordPress-hosting assets and logs are forwarded to your centralized logging platform. Filter for HTTP 200 responses to POST /wp-admin/admin-ajax.php from sessions lacking valid WordPress authentication cookies where Content-Type is multipart/form-data. Flag any request where the action parameter maps to known trx_addons AJAX handlers. Apply D3-SFA (System File Analysis) continuously on the web host: alert on creation or modification of any .php file under wp-content/uploads/ or wp-content/plugins/trx_addons/ — these directories should not contain executable PHP. Apply D3-FMBV (File Magic Byte Verification) to files written to upload directories: verify magic bytes match declared MIME type and flag PHP-executable content regardless of file extension. If EDR is deployed on the web host, alert on the web server process (apache2, nginx, php-fpm) spawning child processes such as /bin/sh, /bin/bash, curl, or wget — this is a high-confidence indicator of web shell execution (MITRE T1505.003 ). Apply D3-LAM (Local Account Monitoring) post-compromise: review local and WordPress-level accounts for unauthorized additions consistent with post-exploitation persistence (MITRE T1190 ). Use NIST AU-6 (Audit Record Review, Analysis, And Reporting) procedures to review log data at increased frequency during active exploitation periods. Any newly created PHP file outside the plugin's expected directory structure is a high-confidence indicator and should be treated as a confirmed compromise pending forensic verification.
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
MITRE ATT&CK Hunting Queries (1)
Sentinel rule: Web application exploit patterns
KQL Query Preview
Read-only — detection query only
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("PaloAlto", "Fortinet", "F5", "Citrix")
| where Activity has_any ("attack", "exploit", "injection", "traversal", "overflow")
or RequestURL has_any ("../", "..\\\\", "<script", "UNION SELECT", "\${jndi:")
| project TimeGenerated, DeviceVendor, SourceIP, DestinationIP, RequestURL, Activity, LogSeverity
| sort by TimeGenerated desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
CA-8
RA-5
SC-7
SI-2
SI-7
CM-2
+5
MITRE ATT&CK Mapping
T1190
Exploit Public-Facing Application
initial-access
Guidance Disclaimer
