Plugin Security Will Sink WordPress
🔗 **Source:** [Plugin Security Will Sink WordPress](https://justinferriman.com/plugin-security-will-sink-wordpress)
> [!note]+ Document Notes
> tags: [wordpress-security, plugin-ecosystem, platform-risk, ai-threats, wordpress-governance]
> author: Justin Ferriman
> source: justinferriman.com
> reference: https://justinferriman.com/plugin-security-will-sink-wordpress
> date created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
>
> # 🏷️ Title: Plugin Security Will Sink WordPress
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Roger Montti's Search Engine Journal piece on WordPress 7.0 AI API keys (the stated inspiration).
- Patchstack vulnerability exploitation data (cited via SEJ).
- Emdash, SimplyStatic Studio, and Loveable as named alternatives or comparison points.
## 📝 Summary
- A former WordPress product founder (LearnDash) argues that plugin-driven security problems, supercharged by AI-era attacks, threaten WordPress's survival.
- It matters because the author frames plugin insecurity not as a technical nuisance but as a business and market-share threat — the ecosystem's greatest strength turned into its biggest liability.
- Key stakeholders: WordPress leadership (Matt Mullenweg by name), plugin developers, hosts, the .org plugin repo team, security vendors (Patchstack), and competitors (Emdash, Loveable, static-site tooling).
- Risks and tradeoffs: the author admits he's not a developer, so the piece asserts the threat and a leadership gap without proposing technical solutions; his suggested fix (AI-hardened repo review) he concedes may be too costly.
- Bottom line: WordPress is at an "inflection point." Without real leadership on plugin security in the AI era, the author predicts continued market-share loss — and he's personally moving simple sites to static and AI-native hosts.
## 📖 Main Content
- The core argument is a business case, not a code case. The author repeatedly disclaims technical expertise ("I'm not a developer") and positions himself as someone who recognizes "business threats and opportunities."
- Premise 1 — plugins are WordPress's chronic security weak point. Even his own company (LearnDash) had "security scares." No plugin is immune.
- Premise 2 — historically the community handled this well, with "reasonable speed and minimal negative outcomes." That's the load-bearing concession: the system *worked* until now.
- Premise 3 — AI changes the threat model. He cites the SEJ article (Roger Montti) and Patchstack's claim that high-impact vulnerability exploitation now takes "just five hours." AI lets attacks "adapt, optimize, and move forward" beyond old automated scripts. WordPress 7.0's AI API keys add a fresh attack surface.
- Premise 4 — the response is inadequate. He sees the issue still "punted to hosts and plugin devs" and the project treating it as "business as usual." He wants "real leadership," "think tanks resulting in coded solutions," and floats tightening repo listing criteria with AI-based code verification (while conceding cost).
- Conclusion — without change, WordPress keeps losing market share and its "insecure site" reputation worsens. He nods to competitors (Emdash) for at least trying, and to his own migration to SimplyStatic Studio and Loveable.
- Contested/uncertain claims: the "five hours" figure is second-hand (SEJ → Patchstack); the market-share causation is asserted, not evidenced; "business as usual" is the author's perception ("from my perspective"). He hedges throughout ("I'm not sure," "maybe they are already").
- Terms to define: *Patchstack* (a WordPress vulnerability database/security vendor); *the repo* (the WordPress.org plugin directory); *static site* (pre-rendered HTML with no server-side execution, shrinking the attack surface); *Loveable* (an AI app-building/hosting tool); *Emdash* (a competing platform that publicly criticized WordPress).
### 🗒️ Notes
- Opening hook reframes plugin security as the platform's "biggest 'black eye'" and potential "downfall."
- Author credibility move: five years out of the WordPress product space, ex-LearnDash, so he speaks as an operator who lived the security pain, not a current insider.
- The historical-competence concession is genuinely important — he's not claiming WordPress was always broken, he's claiming the AI era breaks a previously-working model.
- "Five hours" exploitation window is the single hardest data point and it's twice-removed from source.
- The fix he most wants isn't a specific fix — it's *leadership and forums* ("these are the types of conversations I'd like to see happening").
- Repo-gate proposal: assess listing criteria; AI hardening to "monitor and verify the code of any plugin submitted and hosted there." He immediately discounts feasibility on cost.
- Competitor framing is double-edged: he praises Emdash for trying while admitting their approach "isn't really the 'WordPress way'."
- Personal-exit signal: he "won't host another WordPress site in the traditional sense," preferring static (SimplyStatic Studio) or AI-native (Loveable). This is the lived-behavior evidence behind the market-share thesis.
- Closing is hedged-optimistic ("cautiously optimistic"), pins priority-setting on Matt, references the WP Engine lawsuit as a distraction risk, and promises a one-year revisit for "clear market signals."
## 📚 References
- [Justin Ferriman — Plugin Security Will Sink WordPress](https://justinferriman.com/plugin-security-will-sink-wordpress)
- [Search Engine Journal — Roger Montti (WordPress 7.0 AI API keys, stated inspiration)](https://www.searchenginejournal.com/)
- [Patchstack (WordPress vulnerability intelligence, cited via SEJ)](https://patchstack.com/)
- [Simply Static / SimplyStatic Studio](https://simplystatic.com/)
- [Lovable (AI app builder, "Loveable" in source)](https://lovable.dev/)
## 🗣️ Paraphrase
- WordPress's longstanding plugin-security problem used to be manageable because the community patched fast — but AI-driven attacks (faster, smarter, and aimed at new surfaces like 7.0's AI API keys) break that old equilibrium, and treating it as "business as usual" will cost the project market share.
- The author, openly a non-developer, can't prescribe the technical fix; what he wants is leadership that funds real solutions (even AI-assisted repo code review) instead of punting to hosts and plugin devs — and absent that, he's personally migrating to static and AI-native hosting.
## 📰 Newsletter
- Heads up, WordPress folks: ex-LearnDash founder Justin Ferriman dropped a sharp opinion piece arguing plugin security — our beloved ecosystem's superpower — could become the thing that sinks the ship in the AI era.
- His worry isn't theoretical: he points to Patchstack data (via Search Engine Journal) suggesting high-impact vulns now get exploited in roughly five hours, and to WordPress 7.0's new AI API keys as fresh bait.
- He's refreshingly honest that he's not a dev and can't hand you the patch — his ask is *leadership*: real working groups and coded mitigations, maybe even AI-assisted code review for the plugin repo, instead of forever punting to hosts and plugin authors.
- Worth a read if you sit anywhere near plugin review, hosting defaults, or .org security policy. Pair it with Patchstack's annual state-of-WordPress-security report for the hard numbers behind his vibe-check.
- Community angle: he's quietly voting with his feet (SimplyStatic Studio, Lovable) — a useful signal for anyone tracking why builders drift off the platform.
## ✅ Action Items
#### DevRel
- Developer advocacy: publish a clear, current "what WordPress is actually doing on plugin security in the AI era" explainer to counter the "business as usual" perception the author names.
- Education: run office hours / workshops for plugin authors on AI-era threat modeling and fast-patch hygiene.
- Developer experience: ship secure-by-default plugin scaffolds and a pre-submission self-check so authors catch issues before review.
- Developer marketing: tell the security-investment story publicly; the gap here is narrative, not just code.
- Community management: open a moderated channel for the "what is being done?" question the author keeps asking.
- Internal/external/cross-project: create a feedback loop between Patchstack-style vendors, hosts, and plugin authors with named owners.
#### OSPO
- Policy & Governance: define decision rights for plugin-repo security criteria so the issue stops being "punted."
- License Compliance: keep compliance scanning adjacent to security scanning in any new repo gate.
- Security Management: stand up formal vuln intake, embargo policy, and (aspirationally) signing/attestations for repo-hosted plugins.
- Software Inventory: pursue SBOM coverage for popular plugins so exploit blast-radius is knowable in five-hour windows.
- Developer Support: fund consultation hours and legal guardrails for authors handling disclosures.
- Community Engagement: explore upstream funding for security tooling rather than relying on volunteer goodwill.
- Strategic Alignment: tie plugin-security KPIs to the market-share thesis and report them to project leadership.
#### Community
- Maintainers: run governance/release-hygiene clinics focused on rapid coordinated patching.
- Contributors: create a "security first issue" onboarding rotation for the plugins team.
- Sponsors: publish transparent budgets for any funded security review program.
- Ecosystem: run cross-project incident drills and coordinated-disclosure dry runs.
#### WordPress
- Core: triage where Core can shrink plugin attack surface (capabilities, nonce/REST hardening defaults) given AI-accelerated exploitation.
- Core Performance: ensure any added security scanning doesn't regress build/review throughput; set a perf budget for the gate.
- Core AI: define responsible-AI guardrails specifically for WordPress 7.0 AI API key handling — the new surface the author flags.
- **Core Program Team:** coordinate the cross-team plugin-security initiative so it has a single owner and cadence.
- Mobile: review telemetry for plugin-driven vulnerabilities surfaced through app flows.
- Playground: build reproducible vulnerable-plugin labs for education and regression testing.
- Community: add an AI-security track to WordCamp speaker mentorship.
- Training: ship a learning path on secure plugin development for the AI era.
- Marketing: counter the "insecure site reputation" with evidence-backed narrative.
- Support: close knowledge-base gaps on what to do when a plugin vuln is exploited fast.
- Design: audit the UX of security tooling — the author says it's "not very user friendly" vs Loveable.
- Documentation: examples-first secure-coding patterns in DevHub.
- Polyglots: translate security guidance so locale coverage doesn't leave sites exposed.
- Accessibility: keep WCAG review in any new author-facing security tooling.
- **Meta:** prototype the author's core idea — tighten plugin-repo listing criteria and pilot AI-assisted code verification for submitted/hosted plugins; publish feasibility + cost findings so the "too expensive" assumption is tested, not assumed.
- CLI: add `wp` commands/scaffolds with secure defaults and a local security smoke test.
- **Hosting:** build a cross-host plugin-security checklist and shared telemetry so the problem isn't only "punted to hosts" — make the punt productive with coordinated defaults (WAF rules, virtual patching, auto-update posture).
- Tide: expand automated scoring toward security signals with a false-positive review loop, and surface scores to plugin authors.
- Openverse: n/a beyond standard ingestion hygiene.
- Themes: mirror any plugin-security gate improvements in theme review.
- **Plugins:** the center of gravity — raise review throughput on security checks, add provenance/signing checks, assign security liaisons, and publish the criteria so the author's "what is being done?" has a public answer.
#### The WPCC
- Programs: fund maintainer stipends earmarked for security-critical plugins.
- Projects: run a documentation sprint on AI-era plugin threat models.
- Funding experiments: matched grants for plugins that pass enhanced security review.
### FAIR
- Technical independence: provenance and signature checks on plugin metadata fit FAIR's local-verification model directly.
- Policies and covenants: anti-capture and funding-transparency covenants for any security-review body.
- Productized governance artifacts: a plugin-security scorecard and operator agreement hosts/repos can adopt.
## 🧪 Hypotheses
- H1: AI-assisted attacks measurably shorten the exploit window for high-impact WordPress plugin vulnerabilities relative to pre-AI baselines.
- H2: Plugin vulnerabilities are a material driver of WordPress market-share change (not merely correlated with it).
- H3: Tightening plugin-repo listing criteria with automated/AI code review reduces the rate of shipped high-severity vulnerabilities.
- H4: Builders of "simple sites" are migrating to static and AI-native hosts specifically because of perceived security burden, not only cost or features.
- H5: Public communication of WordPress security investment reduces the "insecure site reputation" independent of underlying vulnerability rates.
## 📊 Methodology
- H1: time-series analysis of Patchstack/CVE disclosure-to-exploitation intervals, segmented before/after observable AI-tooling adoption; controls for vuln severity and plugin install base.
- H2: regression of market-share metrics against vulnerability incidence with lagged terms; triangulate with builder-migration surveys.
- H3: a controlled pilot — A/B a stricter repo gate on a plugin cohort, measure post-listing severe-vuln rates and review latency.
- H4: stated-preference + revealed-preference survey of recent platform-switchers (why they left), coded for security vs cost vs AI features.
- H5: brand-perception survey pre/post a public security-investment campaign, holding vuln rate roughly constant.
### ❓ 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" figure population-wide or limited to a specific severity/exploit class?
- Who owns plugin-repo security criteria, and what's the decision process to change them?
- Does AI-assisted repo review actually cost more than the market-share it would protect?
- Are static/AI-native exits a trickle or a trend with real volume?
### 🔮 Future Research
- A reproducible benchmark for "time-to-exploit" on WordPress plugins, published openly.
- Cost-modeling of AI-assisted plugin code review at repo scale (the feasibility question the author hand-waves).
- A causal study linking specific security incidents to measurable market-share movement.
- Comparative teardown of how Emdash/Loveable handle the extensibility-vs-security tradeoff that the plugin model creates.
### 💡 Implications
- Practice: plugin authors and hosts should assume shorter patch windows and pre-coordinate disclosure/auto-update posture.
- Policy: the repo's listing criteria become a security control surface, not just a quality one.
- Security: the new AI API key surface in 7.0 needs first-class secret-handling guidance now, not after incidents.
- Education: secure-coding and threat-modeling content moves from "nice to have" to onboarding-critical for plugin devs.
- Funding: security review is a public good for the ecosystem — it likely needs funded stewardship, not volunteer-only effort.
### 🧠 Learning Styles Assessment
- Reading level estimate: roughly Flesch-Kincaid grade 8–9 (conversational, short sentences, first-person, frequent contractions). Flesch Reading Ease likely in the 60s (fairly easy).
#### 👀 Visual learners
- Present: none — pure prose, no charts, diagrams, or screenshots.
- Improve: a time-to-exploit trend chart, a before/after AI-attack diagram, a plugin-repo review flow.
#### 🔊 Aural learners
- Present: none.
- Improve: a 3-minute audio summary or TTS of the argument and the one-year-revisit promise.
#### 🗣️ Verbal learners
- Present: strong — analogies ("black eye," "heads in the sand"), plain-language framing, defined stakes.
- Improve: a short glossary (Patchstack, the repo, static site, AI API keys).
#### 🧩 Kinesthetic learners
- Present: none.
- Improve: a checklist for "audit your plugins for AI-era risk," a sandbox vulnerable-plugin lab.
#### 🧠 Logical learners
- Present: a clear premise→conclusion spine, though several links are asserted.
- Improve: a decision tree for repo-gate options; KPIs tying security to market share.
#### 🧑🤝🧑 Social learners
- Present: implicit — references community sentiment and competitor social-media comments.
- Improve: a discussion prompt or moderated Q&A on "what is being done?"
#### 🧘♀️ Solitary learners
- Present: reflective, first-person framing supports solo reading.
- Improve: a self-check ("is your site's plugin posture AI-era ready?").
#### 🌿 Naturalistic learners
- Present: none.
- Improve: lifecycle/ecosystem framing — plugin "supply chain" as an environment with feedback loops.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: section sub-headings ("What Should We Do?", "The Inflection Point") give structure if marked up as real headings.
- Improve: confirm semantic heading levels and a single H1 on the published page.
#### Keyboard navigation
- Present: standard article, likely keyboard-reachable.
- Improve: visible focus and skip-to-content on the live site (not verifiable from text).
#### Contrast and readability
- Present: not assessable from plain text.
- Improve: verify 4.5:1 body-text contrast on the published page.
#### Text resizing and reflow
- Present: not assessable from text.
- Improve: confirm reflow at 200% zoom with no clipping.
#### Media and captions
- Present: n/a — no media in the source.
- Improve: if an audio version is added, ship a transcript and avoid autoplay.
#### Forms and interactions
- Present: n/a — no forms in the content.
- Improve: label any comment form with inline validation.
#### Standards reference
- Map gaps to WCAG 2.2 AA: 1.4.3 (contrast), 1.4.10 (reflow), 2.4.6 (headings/labels), 2.4.7 (focus visible) — all to verify on the live page, not the text.
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: limited — US-centric WordPress-economy framing, no multi-region examples.
- Improve: note how plugin-security burden lands differently on under-resourced/global sites.
#### Inclusive language
- Present: mostly neutral; some jargon ("the repo," "AI API keys") undefined.
- Improve: a plain-language gloss for non-developer readers (whom the author explicitly addresses).
#### Neurodiversity support
- Present: short paragraphs and named sub-sections aid scanning.
- Improve: more frequent headings and a TL;DR up top.
#### Representation
- Present: thin — names Matt Mullenweg and the author; community is an abstraction.
- Improve: quote a range of voices (hosts, plugin authors, security researchers, smaller-site owners).
#### Psychological safety
- Present: generally respectful; frames criticism at the project, not individuals (mostly).
- Improve: the WP Engine-lawsuit aside risks a personal jab; a neutral "leadership bandwidth" framing would be safer.
### ✅ Logical Validity
#### Strong reasoning
- Inductive (well-grounded): "even LearnDash had security scares; no plugin is immune." Personal operating experience supports the premise that plugin vulnerabilities are endemic. Strengthen by adding incidence data.
- Causal (plausible, partially evidenced): AI changes "speed, scale, and sophistication," supported by the second-hand Patchstack "five hours" figure. Reasonable mechanism; would be stronger with first-party data and a pre-AI baseline.
- Honest scoping: the repeated "I'm not a developer" disclaimer correctly limits the argument to a *business* claim, which is internally consistent — he's arguing the threat and the leadership gap, not the patch.
- Revealed-preference evidence: his own migration to static/AI-native hosting is real behavioral data for the "people will leave" sub-claim (n=1, but it's lived, not hypothetical).
#### Fallacies
- Asserted causation (¶8, "this approach that will ultimately lead to WordPress losing even more market share"): market-share loss is attributed to the security posture without isolating other causes (AI site-builders, pricing, the WP Engine saga). Fix: cite migration data or label it as a prediction.
- Appeal to second-hand authority (¶9, the "five hours" figure routed SEJ → Patchstack): not fallacious per se, but the chain is uncited and unverified here. Fix: link Patchstack's primary report.
- Anecdote-as-trend (¶21, "I won't host another WordPress site"): a single operator's choice is offered as a market signal. Fix: present it as one data point, pair with aggregate switcher data.
- Hasty generalization risk (¶18, competitor social-media comments "largely the same"): self-selected critics on a competitor's post aren't a representative sample. Fix: treat as sentiment, not evidence.
- Solution hand-wave (¶14–15): proposes AI repo-hardening, then immediately concedes "likely not feasible given how expensive," leaving the central fix unfalsified and unscoped. Fix: cost-model it or frame strictly as "a conversation worth having."
#### Tone of voice
- Conversational, candid, self-deprecating ("Remember how I said I'm not a developer?"), and earnest. Mild exasperation ("No time for that nonsense," "heads in the sand") balanced by a deliberately hopeful close ("Cautiously Optimistic"). Reads as a concerned former insider, not a hit piece.
### 🛡️ DARVO Analysis
- Deny: not applicable as classic DARVO. There's mild minimization-in-reverse — he *amplifies* the problem rather than denying it. The closest thing to denial is the project's posture he describes ("business as usual"), which he's criticizing, not enacting.
- Attack: low. The pointed line is the WP Engine-lawsuit aside aimed at Matt ("Hopefully, he's not too distracted with his WPEngine lawsuit") — a jab at leadership focus, but not an attack on an accuser or whistleblower.
- Reverse victim/offender: not present. The author doesn't recast an accused party as the victim; he positions WordPress sites/owners (and himself) as those bearing the risk.
- Emotional cues/rhetoric: "black eye," "downfall," "increasingly embarrassing," "heads in the sand" raise stakes; the optimistic coda softens them. No credibility-undermining of named opponents beyond the lawsuit aside.
## 🎯 Conclusion
- Bottom line: a non-developer ex-founder argues that AI-accelerated plugin attacks turn WordPress's extensibility strength into an existential, market-share-eroding liability — and the project's "business as usual" response and absent leadership are the real failure. The threat case is plausible and honestly scoped; the causal and solution claims are asserted more than evidenced.
- Next steps for readers: treat the "five hours" and market-share claims as hypotheses to verify against Patchstack primary data; if you touch plugin review, hosting defaults, or .org policy, use this as a prompt to publish what *is* being done and to pilot the repo-gate idea with a real cost model; if you run simple sites, weigh the static/AI-native exit the author already took.
## 🔄 Refactor Appendix — Plugin Security Will Sink WordPress
> Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4).
> Defaults: 3 Literature, 1 Permanent.
### 📚 Literature Atoms (H3)
#### [H1] 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 the Search Engine Journal article.
- The hardest data point in the piece; load-bearing for the whole AI-era threat case, but twice-removed from source.
**Tags**: #xref
**Highlight**: [view highlight](readwise://)
<!-- atomicity: 1 idea ✓ -->
#### [H2] 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 sentiment from competitor (Emdash) social-media comments.
- Crystallizes the thesis: the plugin ecosystem flips from asset to liability.
**Tags**: #xref #aphorisms
**Highlight**: [view highlight](readwise://)
<!-- atomicity: 1 idea ✓ -->
#### [H3] 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
**Highlight**: [view highlight](readwise://)
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] Extensibility is a security liability without governed review
**Claim** (one sentence, Courtney's voice): An open extension marketplace converts a platform's core strength into systemic risk unless someone owns and funds security review of what ships.
**Evidence pointer**: [[#H2]]
**Scope & conditions**: Holds for plugin/extension ecosystems with low listing barriers and decentralized patching; breaks where extensions are sandboxed or centrally vetted.
**Links**:
- [[WordPress plugin ecosystem]] — because applies-in WordPress repo governance
- [[Supply-chain security]] — because extends to package/registry threat models
- [[Platform market-share risk]] — because evidence-for the "strength becomes weakness" claim
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Verify Patchstack's "five hours" figure against their primary report. — https://patchstack.com/ #fleeting #inbox
- [F2] Track whether WordPress 7.0 AI API key handling gets first-class secret-management guidance. #fleeting #inbox
### → Things 3 (max 2 actions)
- [ ] Pull Patchstack's latest exploitation-window data and check the "five hours" claim — research #things
- [ ] Draft a one-pager on what the WordPress project is actually doing on plugin security in the AI era — content #things
```
Processed: Plugin Security Will Sink WordPress
- Literature atoms: 3 / 5 cap
- Permanent candidates: 1 / 3 cap
- Fleeting items: 2
- Things 3 actions: 2 / 2 cap
- Konik tags used: [#xref, #aphorisms]
- Triage callouts populated: [Cross Reference, inline aphorism]
- Quality gates: [verbatim ✓, atomicity ✓, link annotation ✓, YAML hygiene ✓, Konik triage ✓, view-highlight markers ✓]
- Override conditions triggered: none
```
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/Plugin Security Will Sink WordPress.md|Plugin Security Will Sink WordPress by justinferriman.com]]
## Highlights
- AI is fundamentally changing the speed, scale, and sophistication of attacks against WordPress sites. Instead of automated scripts, AI can adapt, optimize, and move forward with attacks in ways that we haven't seen before. By way of example, Patchstack (cited from the SEJ article) suggested that exploitation from high-impact WordPress vulnerabilities is just five hours now. ([View Highlight](https://read.readwise.io/read/01kw1yfry837ktfr7ba6tp8jcj))
- Note: The hardest data point (Patchstack via SEJ, so twice-removed): ~5 hours from disclosure to exploitation in the AI era.
- Tags: platform-risk, atom/literature/h1
- This threat has always existed in WordPress, sure, but not like this. It's going to get worse if nothing is done to improve it. What I want to know is *what is being done* currently? Because from my perspective, it looks like the issue still gets punted to hosts and plugin devs. ([View Highlight](https://read.readwise.io/read/01kw1yfx5dtjkkmcgpftjj02td))
- Note: The governance diagnosis: no central ownership — security keeps getting punted to hosts and plugin devs.
- Tags: wordpress-governance, atom/literature/h3
- Something I found interesting was reading the comments on their social media when they came after WordPress. The sentiments were largely the same, and leading the way was the growing downside of the plugin ecosystem. What is often cited as WordPress' greatest strength is being seen as its most glaring weakness. ([View Highlight](https://read.readwise.io/read/01kw1yfv7wj7tkqa9nn1pqqvzq))
- Note: The thesis crystallized: the plugin ecosystem — WordPress's greatest strength — is flipping into its most glaring weakness.
- Tags: plugin-ecosystem, atom/literature/h2