Mixed-Case PHP .htaccess Deny Rule Research

Artifact class Restrictive .htaccess access control

Evidence confidence High

Risk assessment High

Start with the problem you are seeing

Could this match the problem on your WordPress site?

This entry is useful when PHP endpoints fail across multiple nested directories after unexpected .htaccess files appear. The retained directives deny PHP access recursively, although no server request log linked them to a specific visitor report.

Observed in this investigation

The investigation retained repeated .htaccess directives designed to deny access to PHP files across nested directories.

Possible warning signs

Visitors or administrators may receive 403 responses when requesting affected PHP endpoints.
Legitimate scripts in child directories may stop working until the directives are reviewed.

These signs are investigation leads, not proof of this artifact by themselves.

Questions this research can help answer

Why are PHP files returning 403 errors across several WordPress folders?
Can one .htaccess rule affect nested directories recursively?

Evidence boundary: The access-control effect follows from the directives; a specific failed request was not retained in the evidence set.

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.

Ask me to investigate your site See how my malware cleanup works

Research focus: Forensic analysis of a FilesMatch rule covering mixed-case PHP extensions while allowing only index.php through a second rule.

Summary

This WordPress malware research entry documents restrictive .htaccess access control evidence observed during one anonymized client investigation. The narrow topic is Mixed-Case PHP Deny Rule with an index.php Exception: the page records the exact artifact, identifiers, and visible control flow instead of repeating a general malware-removal article.

The combination can block direct access to many PHP files while leaving index.php reachable. This could be used for access control abuse, but the repository does not prove recursive distribution or the exact server effect.

Investigation context

Anonymized investigation with one code screenshot and a supplied .htaccess excerpt. The report date is retained from the original investigation notes. Broader cleanup guidance remains in the WordPress malware removal guide; this entry is limited to what the supplied code and screenshots support.

Observed artifact

The observed .htaccess contained a broad PHP deny rule and index.php exception.

Editor showing mixed-case PHP FilesMatch denial and an index.php allow rule — The rule denies many PHP capitalization variants and then allows index.php. The image confirms this file's contents, not recursive placement or the cause of a particular error page.

Confirmed findings

The first FilesMatch pattern includes php, PHP, Php, PHp, pHp, pHP, phP, PhP, php5, php7, php8, and suspected.
The first block uses Deny from all.
A second FilesMatch block allows index.php.

Technical analysis

How the index.php exception changes the rule

The following code keeps the identifiers and control flow needed for defensive verification while removing secrets, complete payloads, and operational request instructions.

Redacted defensive excerpt

<FilesMatch '.(py|exe|phtml|php|PHP|Php|PHp|pHp|pHP|php7|php8|suspected)$'>
  Deny from all
</FilesMatch>
<FilesMatch '^(index.php)$'>
  Allow from all
</FilesMatch>

This excerpt is intentionally incomplete. It should be used for code search, baseline comparison, and incident review—not copied into a live site.

Analyst assessment

The severity reflects the capability visible in this artifact and its position in the investigated WordPress environment. It is not a claim about campaign prevalence, a particular vulnerability, or an outcome that the retained evidence does not show.

Indicators of compromise

Higher-confidence indicators

Mixed-case PHP extension sequence
suspected extension in FilesMatch
Broad deny followed by index.php-only allow

Contextual indicators

.htaccess
FilesMatch
403 response
index.php

Contextual indicators are not proof of infection by themselves. Confirm them through trusted-file comparison, neighboring code, database provenance, request logs, or the distinctive combinations listed above.

What this evidence does not establish

The number and locations of copies were not retained.
The evidence does not identify the process that wrote the rule.
No server log ties a specific 403 or 500 response to this file.
No associated dropper was confirmed.

Artifact-specific remediation

Preserve representative configuration and record its path.
Replace malicious rules with directory-appropriate trusted configuration.
Search recursively for the exact mixed-case sequence.
Investigate any files that the exception continued to expose.

For a complete response sequence, use the broader malware-removal guide or the WordPress malware-removal service when hands-on incident response is appropriate.

Recurrence verification

Repeat the recursive rule search after scheduled tasks.
Confirm expected PHP endpoints behave normally under clean configuration.
Monitor .htaccess creation in writable directories.

Browse the WordPress malware research hub.

Methodology and privacy note

This analysis is based on retained code, screenshots, paths, and notes from an anonymized WordPress client investigation. Confirmed findings are limited to visible or supplied evidence; professional interpretation is labeled as analyst assessment. Screenshots were reviewed for client identifiers, account paths, usernames, email addresses, credentials, tokens, database details, and unrelated records. Sensitive or operational material remains outside the public page, and every public code block is a redacted defensive excerpt.

Mixed-Case PHP Deny Rule with an index.php Exception