ClickFix Malware Across 30+ WordPress Sites: Incident Report

More than 30 WordPress and WooCommerce sites contained the same ClickFix-style infection pattern. A visitor might see only one fake verification screen, but the code behind it was spread across several parts of each website.

Some malicious code was hidden in PHP files. More was stored in the WordPress database. Another piece was called from the active theme, while a PHP setting could load a malicious file before WordPress even started.

That is why deleting one suspicious file or clicking “remove” in a scanner is not enough. If any one of the other hiding places survives, it can bring the malicious behavior back.

Wordfence is useful for detecting known malicious patterns, changed files, suspicious code, and dangerous content in WordPress options. Those alerts can provide an excellent starting point.

But a scan result is a snapshot, not proof that the whole environment is trustworthy. Running the scanner alone does not preserve evidence, determine how access was obtained, rebuild every affected component, rotate hosting credentials, inspect shared infrastructure, or retest more than 30 sites after cleanup.

This comparison refers specifically to running a scanner by itself. It does not describe a managed incident-response service in which security professionals investigate and clean the environment.

The infection was resilient because it did not depend on one file. Each layer offered another way to store, call, or reload the malicious behavior.

01

Obfuscated PHP files

Hidden loaders and encoded server-side logic on disk.

02

WordPress database

Base64-encoded script content stored in options records.

03

Theme functions.php

An unauthorized call ran during normal WordPress page handling.

04

PHP .user.ini

A startup instruction could load a malicious file before WordPress.

↓Any surviving layer could load the chain again

ClickFix is a social-engineering technique that presents a fake error, CAPTCHA, or verification step and attempts to persuade a person to copy and run a command. In this incident, compromised WordPress sites acted as part of the delivery surface for that visitor-facing behavior.

The report therefore uses “ClickFix-style infection” for the observed website delivery pattern and describes the PHP and database artifacts separately as malicious loaders, injections, and persistence mechanisms. This avoids treating ClickFix as the name of a single server-side payload.

1. 01

   Distributed PHP loaders

   Several installations contained unexpected or modified PHP files whose meaningful behavior was concealed through layered encoding, generated strings, and obfuscated control flow.

2. 02

   Database-hosted script content

   Base64-encoded script fragments and related loader data were present in affected WordPress options records, allowing malicious content to persist outside the visible theme and plugin files.

3. 03

   Theme-level invocation

   The active theme’s functions.php contained an automated call connected to the malicious chain, giving it an execution opportunity during normal WordPress request handling.

4. 04

   PHP startup persistence

   A .user.ini directive caused an injected PHP component to load automatically before normal application handling, creating a persistence path outside the ordinary WordPress lifecycle.

5. 05

   Visitor-facing ClickFix behavior

   When the configured conditions matched, the compromised site could present a fake verification or recovery flow intended to persuade a visitor to execute a command on their own device.

6. 06

   Redundant recovery paths

   Because multiple layers could reintroduce or reload the behavior, a single-file cleanup could leave the environment capable of reinfection.

The compromised page presented a familiar-looking verification flow rather than an obvious malware warning. Its purpose was to transfer execution to the visitor by persuading that person to open a system interface and paste a command.

The reconstruction below preserves the observable layout and social-engineering pattern while removing the client domain, command content, attacker infrastructure, and other operational details.

The affected estate should be treated as a coordinated compromise rather than 30 isolated website infections. Repeated artifact structure across sites, multiple execution layers, and the use of configuration outside WordPress all raise the likelihood that the attacker had access to a shared control point, reusable credential, common deployment path, or shared vulnerable component.

That pattern increases both cleanup complexity and reinfection risk. A site cannot be considered restored merely because its public pages stop displaying the malicious behavior at one moment in time.

The mapping below uses MITRE ATT&CK vocabulary to describe behavior, not to identify a threat actor or claim evidence that was not retained. Technique confidence is stated separately from the underlying incident finding.

Base64 is encoding rather than encryption. Its presence alone is not proof of malware, because legitimate software may store encoded values. Here it became relevant because the decoded structure correlated with unauthorized PHP loaders, theme changes, and visitor-facing behavior across multiple sites.

WordPress stores settings and extension data in its options table, so malicious content placed there can survive replacement of a theme file and can be retrieved during later requests. The database therefore required targeted review and cleanup rather than a file-only malware scan.

PHP can be configured to parse a named file automatically before the requested script. A malicious .user.ini instruction at the site or parent-directory level can therefore run before WordPress, bypass theme-focused cleanup, and affect multiple applications under the same directory hierarchy.

A similar infection across more than 30 sites makes a shared cause more plausible than unrelated compromises happening at the same time. That is a prioritization signal, not proof of one specific vector.

The investigation should compare timestamps and access records across the full estate before naming the root cause. Restoring clean files without closing the common access path would leave every site at risk of reinfection.

• Reused or compromised hosting-panel, SSH, SFTP, deployment, or administrator credentials
• A vulnerable plugin, theme, management agent, or other component deployed across the fleet
• Compromise of a shared hosting account, parent directory, automation system, or backup source
• Unsafe cross-site filesystem permissions or insufficient account isolation
• A compromised administrator workstation, browser session, API token, or password manager entry
• An infected deployment package, staging source, or restoration image reused across sites

This public report does not publish client-specific hashes, filenames, domains, or payloads. Instead, the checks below describe indicator classes that site owners and administrators can compare with their own environment without assuming that every encoded value or changed file is malicious.

Preserve a backup, timestamps, logs, and representative artifacts before changing anything. If a visitor-facing lure is active, restrict public delivery first and investigate from a trusted administrative device. Never paste a command supplied by the suspicious page.

1. 01

   Preserve evidence

   Capture timestamps, hashes, logs, database exports, configuration files, and representative malicious artifacts before destructive cleanup.

2. 02

   Contain delivery

   Temporarily restrict affected sites, block confirmed attacker infrastructure where appropriate, and prevent visitors from receiving the malicious flow.

3. 03

   Secure shared access

   Rotate control-panel, SSH, SFTP, database, WordPress, deployment, API, and CDN credentials; revoke sessions and remove unknown keys.

4. 04

   Rebuild trusted application files

   Replace WordPress core, plugins, and themes from verified sources. Do not rely on manually deleting only the visible encoded lines.

5. 05

   Remove database persistence

   Back up the database, identify the unauthorized options records, remove the malicious values in a controlled transaction, and verify application behavior.

6. 06

   Remove startup and theme triggers

   Restore functions.php from a known-good source and remove unauthorized .user.ini directives, including inherited configuration in parent directories.

7. 07

   Close the enabling condition

   Patch or remove vulnerable shared components, correct isolation and permissions, and address the access path supported by the available evidence.

8. 08

   Retest the full fleet

   Validate each site independently, then monitor the common environment long enough to cover cache expiry, scheduled execution, deployments, and normal traffic.

• Preserve a pre-cleanup backup and record timestamps and hashes for representative artifacts.
• Inventory WordPress core, active and inactive plugins, themes, must-use plugins, drop-ins, uploads, cache directories, and unexpected PHP files.
• Replace application packages from verified vendor or WordPress.org sources instead of editing suspicious files in place.
• Review the options table for unauthorized encoded values, suspicious autoloaded records, injected external resources, and deleted-plugin remnants.
• Restore the active theme’s functions.php and other modified theme files from a trusted source, then reconcile legitimate customizations separately.
• Review .user.ini, php.ini, .htaccess, web-server configuration, parent directories, scheduled tasks, and PHP process configuration for hidden loaders.
• Inspect wp-config.php, index files, mu-plugins, uploads, cron events, administrator accounts, application passwords, sessions, and API tokens.
• Rotate WordPress salts and all credentials whose trust cannot be preserved; avoid reusing one replacement secret across the fleet.
• Clear WordPress, object, opcode, reverse-proxy, CDN, and browser caches so removed content cannot continue to execute.
• Apply security updates and correct the verified enabling condition before returning the site to normal service.

This incident cannot be closed by deleting one obfuscated file or removing one visible browser script. The filesystem, WordPress database, active theme, PHP startup path, identities, shared infrastructure, and recovery sources all require a documented trust decision.

The most important unresolved question is the common access path. Until it is identified or the plausible shared paths are neutralized, the fleet remains exposed to reinfection even when individual sites appear clean.

This sample intentionally withholds client identifiers, attacker infrastructure, live payloads, and executable commands. A client report would include controlled evidence references, ownership, timestamps, remediation status, and a signed-off retest record for each affected asset.