Reject Requests That Are Malformed Before They Become Application Ambiguity

Enabled by Default With Bounded Limits

The current 1.20.13 defaults provide protection without turning the integrity layer into unlimited request inspection.

Inspect the Whole Filename, Not Just the Last Extension

An upload named like an image does not become safe when an executable extension is hidden earlier in the filename.

The upload check recursively walks WordPress’s uploaded-file name structure and evaluates extension segments after the base name. That lets Aegisify catch a filename such as a benign-looking document or image followed by, or containing, a PHP-family or other configured executable extension. The blocked-extension list is filterable for controlled deployments, but broad relaxation should be approached carefully.

This layer evaluates the filename, not the full content semantics of every uploaded file. It should be paired with WordPress upload restrictions, secure file handling, malware scanning, least privilege, and storage controls. A filename check can remove a direct class of risk without pretending to be complete malware analysis.

Integrity First, Then Threat Analysis

Aegisify separates malformed protocol conditions from application attack patterns so each control has a clear job.

Make Protocol Failures Explainable

The integrity engine returns named reasons instead of collapsing every hard block into a generic firewall event.

Request-target reasons include request_uri_too_long, malformed_percent_encoding, null_byte, and request_target_line_break. Method enforcement reports dangerous_http_method. Header checks can report invalid_header_name, header_line_folding, or too_many_headers.

Framing reasons distinguish conflicting_content_length, invalid_content_length, conflicting_message_framing, transfer_encoding_on_http_1_0, invalid_transfer_encoding, invalid_chunked_coding_count, chunked_not_final, and unsupported_transfer_coding. Upload rejection reports executable_upload with the detected extension.

That specificity improves security operations because teams can separate a malformed client, a proxy compatibility problem, a suspicious upload attempt, and HTTP-framing abuse without lowering the entire control just to make traffic work.

Limits Are Adjustable, but Not Unbounded

Aegisify constrains the two primary size controls so administrators cannot accidentally turn a protocol safeguard into unlimited parsing work or an impractically tiny gate.

The URI ceiling can be configured within 2,048 to 65,536 bytes, with 8,192 as the default. The header-count control is bounded from 20 through 300, with 100 as the default. Executable-upload blocking can be enabled or disabled separately, and developers can filter the blocked extension list when a verified application workflow requires a controlled adjustment.

The engine intentionally reads the raw request target for malformed encoding, null bytes, and line breaks before normalization. That preserves the evidence needed to detect ambiguity that could disappear after decoding or sanitation. For production changes, record the previous value, test the legitimate client that requires the exception, and keep the adjustment as narrow as possible.