Start with the problem you are seeing
Could this match the problem on your WordPress site?
This research is relevant when a WP Security Helper directory exists on the server but routine wp-admin views do not account for it, or user listings appear incomplete. The code altered both plugin-list and user-query behavior.
Observed in this investigation
- The supplied plugin code filtered plugin metadata and changed user-query behavior inside WordPress administration.
Possible warning signs
- The plugin may be absent from the normal Plugins screen despite existing on disk.
- An administrator may see an incomplete or selectively altered user list.
These signs are investigation leads, not proof of this artifact by themselves.
Questions this research can help answer
- Why is WP Security Helper present in hosting files but missing from WordPress?
- Can one plugin hide both itself and selected users from wp-admin?
Evidence boundary: Unexpected list behavior warrants investigation, but comparison with filesystem and database evidence is still required.
Seeing one of these signs on your site?
I can investigate the files, database records, users, and server evidence, explain what is confirmed, and help plan a safe cleanup.
Research focus: Forensic analysis of the WP Security Helper artifact, whose PHP hooks alter WordPress plugin visibility, user queries, and displayed user counts.
Summary
This entry documents a plugin artifact identified as WP Security Helper during one anonymized WordPress investigation. A file-manager screenshot confirms the wp-security-helper directory. The supplied PHP registers WordPress hooks that alter the plugin inventory and the administrator user list, including its query, returned results, and displayed count.
The useful research topic is the artifact’s concealment structure, not a general claim that every similarly named security plugin is malicious. The screenshot alone does not prove hiding behavior; that conclusion comes from the supplied code.
Investigation context
The directory appeared among normal plugin folders in wp-content/plugins. The supplied main file used a WordPress-style plugin header and the class name WP_Security_Helper, then registered several obfuscated hook and method names.
This page narrows its scope to those administrative-view changes. Broader advice about evaluating suspicious plugins belongs in the known fake and malicious WordPress plugins guide.
Observed artifact
The retained file-manager view shows a directory named wp-security-helper. Other installed plugin names are visible only as path context and are not implicated by this finding.

Confirmed findings
- The supplied plugin code declares the class
WP_Security_Helper. - Its constructor registers
pre_get_users,users_list_table_query_args,wp_count_users,get_users, andall_pluginscallbacks. - On the administrator Users screen, the visible query logic restricts results to the current user’s ID.
- The
adjust_user_countmethod replacestotal_userswith1when that count exists. - The supplied concealment excerpt removes the current plugin basename from the plugin array under a request condition.
Technical analysis of the WP Security Helper hooks
User-list manipulation
Several different hooks target the same administrator surface. Query arguments are restricted, returned user objects are filtered, and the count is changed separately. Using all three layers can make the Users screen present a narrower view than the underlying database actually contains.
The code does not create a user in the retained sample. It changes visibility. That distinction matters: a discrepancy should prompt database and capability review, but it is not proof that this artifact created any account.
Plugin-list concealment
The all_plugins callback receives WordPress’s plugin inventory and removes the current file’s basename when its gate is satisfied. The exact request key is represented by malformed or escaped characters in the supplied draft, so this public analysis does not reconstruct or normalize it.
Redacted defensive excerpt
register callbacks for:
administrator user query
user-table query arguments
displayed user count
returned user results
plugin inventory
on the Users screen:
restrict visible results to the current user
replace the displayed total with one
under a request condition:
remove this plugin basename from the plugin inventory
This is an inert control-flow summary. It omits the operational request condition and the truncated portion of the original sample.
Analyst assessment
The combined hook set is consistent with deliberate administrative concealment. A legitimate plugin may filter users or the plugin list for a documented product reason, but the simultaneous use of obfuscated strings, self-removal, user-query restriction, result filtering, and count manipulation is not explained by the visible plugin metadata.
The available evidence supports describing the artifact as a fake or unauthorized plugin found during the investigation. It does not establish who installed it, how long it was present, or whether another component used the hidden view to protect a separate account.
Indicators of compromise
Higher-confidence indicators
- Plugin identity
WP Security Helper - Directory
wp-content/plugins/wp-security-helper/ - Main filename
wp-security-helper.php - Class name
WP_Security_Helper - The combined method set
filter_user_query,modify_user_table_args,adjust_user_count, andfilter_user_results - An
all_pluginscallback that removes its own plugin basename
Contextual indicators
pre_get_userswp_count_usersget_usersall_plugins- A mismatch between visible users and a direct database or trusted command-line query
These hooks are legitimate WordPress extension points and are not proof of malware by themselves. The distinctive identity and combined behavior provide the stronger signal.
What this evidence does not establish
- The screenshot does not show the WordPress Plugins screen or prove that the directory was hidden there.
- The sample does not show administrator creation, password changes, or credential collection.
- The truncated code prevents a complete review of every branch.
- No vulnerable plugin, affected version, or initial compromise route was confirmed.
- No campaign attribution, prevalence, or client outcome is supported by the retained evidence.
Artifact-specific remediation
Preserve the directory and relevant logs before modification when investigation history is required. Verify the plugin against the site’s approved deployment inventory. If it is unauthorized, remove the complete directory rather than only changing the visible hook registrations.
Review users through a path that does not rely solely on the potentially filtered dashboard: compare the database, a trusted command-line query, and administrator capabilities. Search for the class and method set across plugins, themes, and must-use plugins. Then use the broader hidden-administrator investigation guide for account review without assuming this sample created an account.
Recurrence verification
- Confirm that
wp-content/plugins/wp-security-helper/does not return after normal traffic and scheduled tasks. - Recheck the Plugins and Users screens after the artifact is removed.
- Compare dashboard user counts with a trusted database or command-line count.
- Monitor file changes and plugin activation records for the same directory, class, and method names.
Related malware research
- HTTP-header-gated PHP loader
- Functions.php credential logger using a fake PNG file
- Compact Extension Vox MU-plugin artifact
Methodology and privacy note
This analysis uses one privacy-reviewed screenshot and a truncated PHP sample from an anonymized investigation. The screenshot supports the path finding only. Code-supported behavior is separated from analyst assessment, and the public excerpt omits the request gate and incomplete malicious implementation.