Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
71 detections
Filters
Last updated
All Time
Detection languages
21
18
17
9
3
Contributors
62
3
3
2
1
Categories
24
20
19
12
11
Platforms
65
6
5
3
Products / Services
35
23
23
13
7
MITRE Techniques
50
21
19
15
13
CVEs
71
71
64
58
49
IDS Classtypes
8
1
IDS Protocols
9
Detects attempts to exploit the WordPress wp2shell vulnerability (CVE-2026-63030/CVE-2026-60137) by correlating the identification of a vulnerable WordPress version (6.9.0-6.9.4 or 7.0.0-7.0.1) via response banners with anomalous Batch REST API requests utilizing the 'author__not_in' parameter.
Detects creation of PHP web shell files or plugin directories under WordPress wp-content/plugins using the wp2shell_<hex> naming convention, associated with the wp2shell WordPress Core RCE exploitation chain.
Detects a POST to the WordPress REST API batch endpoint whose request body embeds a nested /wp/v2/users call granting the administrator role, consistent with the wp2shell exploit chain where a forged customize_changeset/parse_request replay temporarily assumes an existing admin's identity to pass current_user_can('create_users') and create a new administrator account without any preceding authenticated login. To reduce false positives from legitimate onboarding of administrator accounts, this rule now requires either the absence of an authenticated WordPress session cookie on the request, or a newly created username matching the randomized/generated wp2shell naming pattern (wp2_*, w2s_*).
Detects discovery and SUID/SGID enumeration commands (whoami, hostname, id, uname, cat /etc/passwd, find -perm) executed by a shell spawned from a WordPress plugins directory by a web server process.
This rule detects unauthenticated HTTP requests to the WordPress REST API batch endpoint (/wp-json/batch/v1). Such requests are characteristic of attempts to exploit the wp2shell vulnerability (CVE-2026-63030), where attackers leverage the batch API to execute unauthorized actions without proper authentication headers (Cookie or Authorization).
Detects potential exploitation attempts targeting WordPress sites, specifically identifying unauthenticated REST API batch requests that attempt to forge posts with post_status 'parse' and post_type 'request' while including self-referential post_parent cycles. This pattern is associated with recent vulnerabilities enabling remote code execution.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects attempts to perform error-based SQL injection against WordPress instances associated with the wp2shell exploit chain. The rule monitors for the use of MySQL functions EXTRACTVALUE or UPDATEXML within query parameters that are typically targeted by the exploit (author_exclude, author__not_in) or when interacting with the batch REST endpoint.
Detects the wp2shell post-exploitation cleanup pattern where a shell spawned by a web server process determines its current working directory, matches it against a wp-content/plugins path using the specific `case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac` one-liner shape, and recursively deletes that directory to remove the deployed web shell plugin. This is tightened to require the exact case-statement/one-liner construction executed by a shell that is a child of a web server process, rather than any generic recursive delete under wp-content/plugins, which would also fire on legitimate WordPress plugin uninstall hooks that remove their own plugin directory. Absence of the plugin directory afterward should not be treated as evidence the host is clean.
Detects creation of PHP web shell files or plugin directories under WordPress wp-content/plugins using the wp2shell_<hex> naming convention, associated with the wp2shell WordPress Core RCE exploitation chain.
Detects a POST to the WordPress REST API batch endpoint whose request body embeds a nested /wp/v2/users call granting the administrator role, consistent with the wp2shell exploit chain where a forged customize_changeset/parse_request replay temporarily assumes an existing admin's identity to pass current_user_can('create_users') and create a new administrator account without any preceding authenticated login. To reduce false positives from legitimate onboarding of administrator accounts, this rule now requires either the absence of an authenticated WordPress session cookie on the request, or a newly created username matching the randomized/generated wp2shell naming pattern (wp2_*, w2s_*).
Detects [embed] shortcode content submitted to WordPress that references invalid or anonymous local post IDs, used in the wp2shell chain to forge oEmbed cache database rows as a render-time write primitive.
Detects [embed] shortcode content submitted to WordPress that references invalid or anonymous local post IDs, used in the wp2shell chain to forge oEmbed cache database rows as a render-time write primitive.
Detects a WordPress admin plugin ZIP upload to wp-admin/update.php?action=upload-plugin only when correlated with high-risk context: the observed wp2shell_ plugin naming convention, evidence of a just-created/unfamiliar administrator account (wp-admin/user-new.php activity in the same capture), or the upload occurring immediately after REST API batch-route/SQLi anomalies (wp-json/batch/v1, author__not_in) tied to CVE-2026-63030 and CVE-2026-60137. Routine plugin uploads by established administrators without these correlating indicators are excluded.
Detects the WordPress REST API batch-route confusion technique (CVE-2026-63030) via a malformed nested sub-request path combined with the co-occurring parse_path_failed/block_cannot_read/rest_batch_not_allowed error marker pattern.
Detects the creation of a WordPress administrator account via the REST API using username prefixes associated with the 'wp2shell' exploit (e.g., 'wp2_' or 'w2s_'). This activity is indicative of an attacker attempting to establish persistence on a compromised WordPress site.
Detects the execution of sendmail via a shell (sh, bash, dash) spawned by a web server process (Apache, Nginx, httpd) where the process working directory matches the wp2shell plugin pattern (wp2shell_<hex>). This is indicative of remote code execution or web shell activity associated with the wp2shell vulnerability, where the attacker uses sendmail for exfiltration or command output delivery.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects web server processes (Apache, Nginx, PHP-FPM) spawning a system shell to execute compound commands containing discovery utilities (like id, whoami, hostname, uname, or find) within a 'wp-content/plugins' directory. This behavior is indicative of post-exploitation activity following a remote code execution vulnerability, such as those associated with the wp2shell attack pattern.
Detects the wp2shell post-exploitation cleanup pattern where a shell spawned by a web server process determines its current working directory, matches it against a wp-content/plugins path using the specific `case "$d" in */wp-content/plugins/*) cd / && rm -rf "$d";; esac` one-liner shape, and recursively deletes that directory to remove the deployed web shell plugin. This is tightened to require the exact case-statement/one-liner construction executed by a shell that is a child of a web server process, rather than any generic recursive delete under wp-content/plugins, which would also fire on legitimate WordPress plugin uninstall hooks that remove their own plugin directory. Absence of the plugin directory afterward should not be treated as evidence the host is clean.
Detects a WordPress-context web server process spawning a non-shell interpreter or downloader (curl|bash, python -c, wget/curl via sh -c) to retrieve second-stage tooling post-exploitation.
Page 2 of 4