# Generic Hosting Security Cannot See WordPress-Specific Attack Semantics ## Claim A host's security controls can block generic PHP attacks while missing WordPress-specific exploit paths, so “secure hosting” must name the application-aware layer. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies to hosting claims based on WAFs, malware scanners, isolation, and generic server hardening. - WordPress-aware controls need current knowledge of routes, capabilities, plugins, and platform behavior. - Vendor tests require independent replication because security vendors benefit from the identified gap. ## Evidence [Maciek Palmowski on testing secure WordPress hosting](../Readwise/Articles/%23227%20%E2%80%93%20Maciek%20Palmowski%20on%20Testing%20Secure%20WordPress%20Hosting%20Does%20the%20Marketing%20Match%20Reality.md) reports substantially stronger protection against generic PHP-layer attacks than WordPress-specific plugin exploits under a repeated test method. ## Links - [[Zet · Infra-only defences miss most WordPress attacks]] — provides-foundation: infrastructure visibility doesn't include all application semantics. - [[Patch-to-Exploit Speed Makes Route-Aware Detection Part of Patching]] — applies-in: WordPress routes can carry exploit meaning outside a simple URL match. - [[WordPress's Compatibility-First Culture Is Now Its Binding Security Constraint]] — extends: application-aware defense must compensate for slower compatibility-bound remediation. - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — applies-in: the MOC lists this note under Synthesis additions (2026-08-11 — application-aware hosting).