# 227 – Maciek Palmowski on Testing Secure WordPress Hosting > [!question] Lingering Questions > - What are the exact Patchstack report figures (host counts, plugin list, sample size)? The episode gives numbers from memory, not from the report itself. > - What is a vendor-neutral technical definition of "WordPress aware" security tooling? Needed before the buyer question in the episode is usable without vendor capture. > [!tip] Article Ideas > - A publishable one-pager: "questions to ask a WordPress host about their security stack" — directly usable in procurement conversations. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Generic Hosting Security Cannot See WordPress-Specific Attack Semantics]] — the same "WordPress aware" distinction, already in the vault from a related source > - [[3. Resources/Permanent Notes/Patch-to-Exploit Speed Makes Route-Aware Detection Part of Patching]] — corroborates this episode's five-hours-to-exploitation figure > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] > [!quote] Vocabulary > - **"WordPress aware"** — Palmowski's term for a security control (WAF, scanner) tuned to WordPress-specific request semantics, as opposed to generic PHP/web attack signatures. ## Bib capsule WP Tavern podcast episode #227, Maciek Palmowski (security researcher who ran a hosting-security beta test) discussing whether marketed "secure WordPress hosting" holds up under actual penetration testing. ## Author's thesis Hosts that market "secure hosting" frequently fail penetration tests their own marketing implies they'd pass — not for lack of security tools, but because those tools are misconfigured or not WordPress-aware. Update speed alone can't substitute for detection, because exploitation now begins within hours of disclosure and half of disclosed vulnerabilities ship with no patch at all. ## Key arguments (≤3) 1. **The headline result is stark**: roughly 80% of test attacks passed through hosts advertising secure hosting. 2. **The mechanism is configuration, not tooling**: hosts with identical security products scored differently because of how those products were configured and operated. 3. **The exploitation window has collapsed**: vulnerabilities are used ~5 hours after disclosure, and half of last year's disclosed vulnerabilities had no patch at time of publication — making patch speed alone an inadequate defense. ## Claim atoms ### Most attacks pass hosts advertising secure hosting > [!quote] ID:rw_01kyq6rgdwgez2kcxxe90dxs9v > we were quite surprised because we saw, if I remember, that 80% of the attacks went through. 80% of the attacks. The headline number from the beta test. Note the hedge ("if I remember") — this is a recalled figure, not one read from a written report. ### Configuration outperforms tooling in host security outcomes > [!quote] ID:rw_01kyq6rqpcf55gd8fvnt2fvg8t > it's not about the tools that you are using, it's how you are using them Explains why hosts with identical security stacks scored differently — the mechanism finding, and the one that generalizes furthest: it applies to any security control procured as a product. ### Exploitation begins five hours after disclosure > [!quote] ID:rw_01kyq6s7keed5htafanbkwpz64 > we already saw that vulnerabilities are being used after around five hours after kind of being published. So five hours. Citing the prior year's State of WordPress Security Report. Undercuts "update weekly" guidance still repeated in mainstream WordPress security advice. ### Half of disclosed vulnerabilities have no patch available > [!quote] ID:rw_01kyq6sj5stjr0dtcepayx0ke2 > from all the vulnerabilities that were discovered last year, 50% weren't patched at the moment of publishing about it. 50%. The more serious of the two numbers — prompt updating cannot protect against a fix that doesn't exist yet. Points at maintainer capacity, not user behavior. ### Ask hosts whether anything is WordPress aware > [!quote] ID:rw_01kyq6svhh3srmeakfcc6ga9ep > One of the best questions you can ask is just, is there any solution in your security stack that is WordPress aware? The practical takeaway — directly usable in procurement. Follow-up: ask which product, then verify independently. ## Permanent candidates - **Security controls are configurations, not purchases** — promoted below; not covered by an existing note. - The "WordPress aware" buyer question and the patch-timing findings are already substantially covered by two existing Permanent notes ([[3. Resources/Permanent Notes/Generic Hosting Security Cannot See WordPress-Specific Attack Semantics]], [[3. Resources/Permanent Notes/Patch-to-Exploit Speed Makes Route-Aware Detection Part of Patching]]) — connect rather than duplicate. ## Processing checklist - [x] Ported from existing deep-read (Refactor Appendix) - [x] Checked for duplicate Permanent notes — found two, linked instead of recreated - [x] Connected into MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] - [ ] Locate the actual Patchstack State of WordPress Security report for exact figures ## Metadata - Source: [[3. Resources/Literature Notes/227 – Maciek Palmowski on Testing Secure WordPress Hosting]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — direct fit: hosting-security procurement and evaluation - [[3. Resources/Permanent Notes/Generic Hosting Security Cannot See WordPress-Specific Attack Semantics]] — evidence-for; this episode is a second independent source for the same "WordPress aware" distinction - [[3. Resources/Permanent Notes/Patch-to-Exploit Speed Makes Route-Aware Detection Part of Patching]] — evidence-for; corroborates the hours-not-weeks exploitation window with a different vendor's telemetry