# Plugin Security Will Sink WordPress > [!question] Lingering Questions > - What, concretely, is the WordPress project doing on plugin security right now — and where is it documented? (The author's central, unanswered question.) > - Is the "five hours" exploitation-window figure population-wide or limited to a specific severity/exploit class? It's twice-removed from source (SEJ → Patchstack). > - Does AI-assisted repo review actually cost more than the market-share it would protect, or is "too expensive" an unexamined assumption? > [!tip] Article Ideas > - A "what WordPress is actually doing on plugin security" explainer that answers the author's central question with evidence, not vibes. #articleseed > [!link] Cross Reference > - [[3. Resources/Permanent Notes/An Open Marketplace Turns Extensibility Into Liability Without an Owned Security Layer]] — this Literature note's own permanent candidate; already promoted from this exact source > - [[3. Resources/Permanent Notes/A Timed Review Window Trades Update Speed for Supply-Chain Safety]] — WordPress.org's actual 24-hour review-window policy change is the closest real answer yet to this author's "punted to hosts and devs" complaint > - [[3. Resources/Permanent Notes/Supply-Chain Defense Tracks Bad Actors Not Bad Code]] — the defensive mechanism an owned security layer would need > - [[3. Resources/Permanent Notes/AI Finds Exploit Chains Faster Than Humans Can Audit Them]] — the attacker-side mirror of this piece's exploitation-window claim > [!quote] Vocabulary > - *Patchstack* — a WordPress vulnerability-intelligence vendor; source of the "five hours" exploitation figure (cited secondhand via Search Engine Journal) > - *the repo* — the WordPress.org plugin directory, treated here as a security control surface, not just a quality gate ## Bib capsule Justin Ferriman (ex-LearnDash founder), "Plugin Security Will Sink WordPress," justinferriman.com, 2026-06-25. ## Author's thesis A former WordPress product founder argues plugin-driven security problems, supercharged by AI-era attacks, threaten WordPress's survival as a platform. The piece is explicitly a business case, not a code case — the author repeatedly disclaims developer expertise and argues the threat and the leadership gap, not a technical fix. ## Key arguments 1. Plugins are WordPress's chronic security weak point, and the community historically handled this "with reasonable speed and minimal negative outcomes" — that concession matters: the system *worked* until AI changed the threat model. 2. AI collapses the exploitation window (Patchstack via SEJ: "just five hours" for high-impact vulnerabilities) and WordPress 7.0's new AI API keys add fresh attack surface. 3. The response is inadequate — security still gets "punted to hosts and plugin devs" with no visible central leadership, and the author is voting with his feet (migrating simple sites to static/AI-native hosting). ## Claim atoms ### AI collapses the WordPress vulnerability exploitation window > [!quote] ID:rw_manual_01 > exploitation from high-impact WordPress vulnerabilities is just five hours now. **Context & use**: ¶9, citing Patchstack via Search Engine Journal. The hardest data point in the piece; load-bearing for the whole AI-era threat case, but twice-removed from source — unverified here. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ### WordPress's greatest strength is now its glaring weakness > [!quote] ID:rw_manual_02 > What is often cited as WordPress' greatest strength is being seen as its most glaring weakness. **Context & use**: ¶18, summarizing competitor (Emdash) social-media sentiment. Crystallizes the thesis — the plugin ecosystem flips from asset to liability. This is the line the existing Permanent note is built on. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### Security gets punted to hosts and plugin developers > [!quote] ID:rw_manual_03 > it looks like the issue still gets punted to hosts and plugin devs. **Context & use**: ¶13, the author's diagnosis of the leadership/ownership gap. Names the governance failure mode — no central owner for plugin security. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> ## Permanent candidates - [[3. Resources/Permanent Notes/An Open Marketplace Turns Extensibility Into Liability Without an Owned Security Layer]] — already exists, sourced from this exact doc; captures claim atoms 1 and 2 together (the exploitation-window collapse + the strength-becomes-weakness framing, as a governance-ownership problem). - No further Permanent candidate for the "punted to hosts and devs" atom on its own — it's a restatement of the ownership gap already captured in the linked note, not a distinct claim. ## Processing checklist - [x] Verbatim quotes preserved from the source deep-read - [x] Atomicity markers present on all three atoms - [x] Checked for an existing Permanent note before drafting a new one — found one, linked instead of duplicating - [ ] Verify the Patchstack "five hours" figure against its primary report - [x] Connect into the relevant MOC(s) ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — plugin-repo security as a fleet-wide control surface - [[3. Resources/MOCs/Open Source Governance MOC]] — the "who owns this" question is a governance-decision-rights problem, not only a technical one - Source doc: [[3. Resources/Readwise/Articles/Plugin Security Will Sink WordPress]]