A hacked WordPress site. A redirect loop. Two investigations.

The incident was real. The next fault needed its own diagnosis.

Spidrweb was engaged to investigate a compromised WordPress installation and support its recovery. The recorded findings included suspicious PHP files and administrator accounts that were not authorised. This was a security incident requiring investigation and remediation.

After that work, a page began returning a “Too Many Redirects” error. Given the recent compromise, it was understandable to suspect that something malicious remained. But timing alone could not explain the behaviour.

The follow-up investigation traced the loop to a site-specific interaction between an SEO plugin’s category rewrite rules and the existing permalink configuration. The security incident and the redirect failure belonged in the same recovery story, with different evidence and different completion checks.

This account is based on the technical incident report and recorded redirect tests. Client and operational details have been anonymised. It describes the work and its verification limits at the time recorded, rather than certifying the website’s present security state.

What supported treating the site as compromised

The investigation found unexpected PHP files in the installation, including a nested plugin directory, alongside unauthorised WordPress administrator accounts. Together, these findings supported a compromise response rather than treating the initial error as an ordinary application fault.

A filename or location alone is not enough to classify every unfamiliar file as malware. The useful work is to inspect the code and its context, compare it with trusted components, and account for who should have access. Likewise, an unfamiliar administrator needs checking against legitimate ownership and support arrangements.

The report records removal or quarantine of suspicious files and removal of the identified unauthorised administrators. It does not establish the original intrusion method or the first date of compromise. A component being reviewed or quarantined should not be presented as the proven route in.

Restore a trusted baseline, then state its scope

WordPress core integrity checks initially failed, identifying missing or inconsistent core files. The core administration and includes directories were replaced from the corresponding trusted release while preserving site-specific content and configuration.

Core checksum verification subsequently passed. That established that the checked core files matched the expected release at the time of verification. It did not independently validate every plugin, theme, upload or database record.

That boundary matters. WordPress core is one part of an installation, and a positive result should not be expanded into “the whole website is clean”. The official WP-CLI core checksum documentation describes the check’s specific purpose.

Review access as well as files

Removing suspicious code addresses only part of a compromise if privileged access remains available. The response also included reviewing administrators, resetting administrator credentials and rotating WordPress authentication salts.

Salt rotation invalidates existing WordPress authentication cookies. It is one part of access recovery, alongside reviewing accounts and the other credentials or integrations that may provide access. The plugin inventory and theme files were also reviewed, with selected components removed or quarantined.

Plugin integrity verification could not be established for every component. That gap needed to remain visible: an unavailable checksum is neither a clean result nor proof of malicious modification. Where automated verification is unavailable, trusted distribution packages and manual review may be needed.

WordPress’s incident guidance provides a broader recovery framework. The work recorded for this incident should be assessed on its own evidence, rather than assuming every recommended check was completed.

A database integrity pass answers a different question

The database integrity check passed. That was a positive structural result, but the report did not confirm completion of a comprehensive review for injected content.

A database can be structurally sound while containing an unwanted script, an unauthorised setting or content altered by an attacker. The integrity of the storage and the legitimacy of what it contains are separate questions.

The remaining review therefore included looking for suspicious content, unexpected administrative changes and potential persistence. The report also did not establish whether data had been accessed or extracted. The absence of a confirmed finding could not be treated as proof that no exposure occurred.

Then a page redirected back to itself

The later operational fault was specific and reproducible: a normal page returned HTTP 301 with a destination identical to the requested address. Following that instruction simply caused the browser to request the same page again.

The response included X-Redirect-By: Yoast SEO. That was a useful lead, and inspection of the generated rewrite rules and plugin implementation explained the mechanism.

The same redirect was reproduced by requesting the origin directly. That established that the observed origin response was not created solely by the edge service. Some command-line requests also received HTTP 403; these were treated separately, and a browser-style user agent was used to reproduce the redirect behaviour.

Different status codes were evidence about different requests. Combining them into one vague “site down” diagnosis would have obscured the application fault.

The rule was broader than the page it was meant to handle

The site used category-based post permalinks and an SEO setting that removed the category prefix. The generated category rules included a broad pattern, (.+)$, mapped to wpseo_category_redirect, ahead of the normal page rule.

For the affected page, the pattern captured the path and the category redirect logic reconstructed the same address. That explained the loop. Checks of the expected page, its permalink and other redirect configuration helped narrow the investigation.

A temporary category-base change followed by a rewrite flush did not remove the conflicting rule, so the original setting was restored. This was a useful failed test: it showed that changing the stored option alone did not correct the generated behaviour.

The evidence supported a configuration-specific rewrite diagnosis. It did not establish that the attacker introduced the rule, or that a particular plugin update caused the historical change.

Correct the confirmed fault with a narrow workaround

A small WordPress must-use plugin filtered out the specific broad category-redirect rule during rule generation. The rewrite rules were regenerated and inspected; the conflicting rule was absent and the normal page rule remained available.

The correction left the SEO plugin enabled and retained the established post permalink structure. It avoided editing third-party plugin files directly. The important point was the scope: one identified rule was corrected to address one demonstrated failure.

This was a site-specific compatibility workaround, not a general setting for other WordPress sites. It also needed documentation and regression checks after future changes to the SEO plugin or permalink configuration. A custom workaround remains a maintenance responsibility.

Technical background: WP-CLI’s rewrite flush documentation.

What the recorded tests actually confirmed

The affected page had previously returned a self-referencing 301. The other two URLs were additional category checks, not three independently demonstrated redirect failures.

The successful page response also contained WordPress metadata consistent with the intended page. That strengthened the evidence for request resolution, while still leaving rendered content and interactive journeys to test.

What remained outside those results

The direct-origin requests checked response behaviour. They were not public TLS validation or a substitute for testing the visitor’s full route. A previously cached permanent redirect could also persist in a browser or intermediary after the origin changed.

The follow-up plan included testing public URLs in a fresh session, representative posts and pages, navigation, forms and other important functions. Security follow-up included the remaining files, accounts, writable areas, database content and persistence mechanisms.

These are separate acceptance criteria. A successful core check, a working page and a full incident closure describe different levels of assurance.

Beyond the fix: make the next decision clearer

The lasting value of this investigation is the separation of evidence. Suspicious files and unauthorised accounts justified a security response. A reproducible self-redirect justified a rewrite investigation. Neither finding answered every question about the other.

A practical recovery record should show what was observed, what changed, which checks passed and what remains open. Preserve an incident copy and relevant logs where available, use trusted sources for restoration, and keep application testing alongside security review.

For a business, that creates a clearer conversation about returning to service and ongoing care. It also prevents an understandable desire for reassurance from turning a limited test result into a promise the evidence cannot support.

The redirect was resolved at the origin in the recorded tests. The overall security recovery still required wider verification. Keeping both statements visible is part of doing the job properly.