What matters first: The file is writable by WordPress on many Apache sites, so plugins, permalink saves, security tools, deployment scripts and malware can all modify it.
What this symptom actually tells you
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.
Capture evidence before changing anything
- 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.
Most common causes
- Permalink regeneration: WordPress rewrites its marked section after settings changes.
- Security or cache plugin: A legitimate plugin manages redirects, headers or access rules.
- Deployment automation: A release replaces the file from a template.
- Malware persistence: A loader repeatedly injects redirects or PHP handlers.
Safe diagnostic and repair sequence
- Identify the responsible process before changing permissions.
- Move legitimate rules into a controlled deployment source where appropriate.
- Remove malicious code and the loader or task that writes it.
- Set the least writable model compatible with required WordPress operations.
How to choose between the likely causes
Do not treat Permalink regeneration and Security or cache plugin as interchangeable. WordPress rewrites its marked section after settings changes. By contrast, a legitimate plugin manages redirects, headers or access rules. Use two checks to separate them: Save successive versions with timestamps and hashes; and separate WordPress marker blocks from directives added outside them. Those observations usually show whether the next safe move is to identify the responsible process before changing permissions or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not overwrite .htaccess with a generic WordPress sample before preserving custom security, multilingual or application routes.
How to verify the repair
- The file remains stable through permalink saves, cron and deployment.
- Only documented rules are present.
- No malicious redirect or handler appears in server responses.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.