A changing .htaccess file is not automatically malware. WordPress, security plugins, cache tools, hosting control panels and deployment processes can all rewrite it. The key question is which process wrote the change and whether the resulting rules are expected.
Diff the file instead of repeatedly restoring it
Save a trusted copy, then compare each recurrence by content, hash and modification time. Correlate the exact timestamp with plugin actions, permalink saves, deployments, cron and incoming requests.
Classify the rule that keeps returning
- Standard WordPress rewrite blocks.
- Cache or security directives added by known plugins.
- Hosting-managed PHP or access rules.
- Unknown redirects, handlers or injected directives with no legitimate owner.
Trace ownership before deleting the rule
If root files are also being rewritten, compare index.php reinfection. If the unexpected change is part of a broader file set, use integrity-alert triage to separate deployment drift from compromise.
Repair the component that owns the rewrite
- Preserve the suspicious version and relevant logs.
- Identify the plugin, deployment, host process or malicious writer.
- Correct or remove that source rather than fighting the generated file.
- Restore the intended rewrite rules once ownership is understood.
Do not make .htaccess immutable as the first response
That can break legitimate permalink, cache or security updates and still leave the writer active elsewhere.
Verification
The file should remain stable through permalink saves, deployments, cron and normal traffic, or change only in the documented way produced by the legitimate owner. Unexpected redirects or handlers must not return.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
The exact added block, timestamp and process context determine whether this is expected automation or compromise. Making the file immutable before finding the writer can break valid operations.
Save successive versions with timestamps and hashes.
Separate WordPress marker blocks from directives added outside them.
Correlate changes with admin actions, cron, deployments and access logs.
Search code for file writes or the exact injected directive.
What must be verified
- The file remains stable through permalink saves, cron and deployment.
- Only documented rules are present.
- No malicious redirect or handler appears in server responses.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I make .htaccess read-only as soon as I notice it keeps changing?+
Not before identifying what's actually writing to it. Making the file immutable before finding the responsible process can break legitimate operations like permalink regeneration or a security plugin managing redirects, since those need write access to function normally.
Does a changing .htaccess file always mean the site is infected?+
No. WordPress itself rewrites its marked section after permalink settings changes, and deployment automation or security and cache plugins can also legitimately modify the file. The exact added block, its timestamp, and the process context determine whether this is expected behavior or a compromise.
Is it fine to overwrite .htaccess with a generic default WordPress version to reset it?+
No, this can break the site. Doing so risks discarding custom security rules, multilingual routing, or application-specific directives that were added deliberately, so any custom rules need to be preserved before resetting the file.
How do you tell a legitimate plugin's changes to .htaccess apart from malware persistence?+
Legitimate plugin activity typically shows up as recognizable redirect, header, or access-rule blocks correlated with an admin action or scheduled plugin task, while malware persistence tends to repeatedly inject redirect or PHP handler code outside any expected marker block. Correlating changes with admin actions, cron, deployments, and access logs separates the two.