## Lingering Questions - Should the WordPress plugin directory require an explicit "credentials are/aren't retained after uninstall" disclosure for any plugin that stores site credentials off-site? - What's the actual root cause behind three security releases in under a month — increased researcher attention, a genuine spike in vulnerability introduction, or ordinary release-cycle cadence? - Is Spacefast's pre-launch leak a one-off communications slip, or a pattern of Automattic-adjacent projects surfacing before their intended announcement? ## Article Ideas - A structured comparison of AI-to-WordPress connector plugins' credential-security models (OAuth vs. Application Passwords vs. custom schemes), building on the WPVibe/Novamira dispute. - A short explainer distinguishing "credentials encrypted at rest and revocable" (what WPVibe's rebuttal addressed) from "credentials auto-revoked on uninstall" (what Cintolo actually challenged). ## Cross Reference - [[Defining a Term to Exclude the Objection Is Not Answering It]] — a related but mechanistically distinct non-answer pattern: that note is about redefining the contested term itself; this issue's WPVibe rebuttal instead answers an adjacent, easier question (encryption, revocability) without addressing the specific behavior challenged (retention after uninstall). - [[WordPress Hosting Security Stack MOC]] — this issue's lead story (WP 7.0.4, third security release in a month) and the AI-agent-credential dispute both belong on this MOC's threat/response tile. ## Fiction & Worldbuilding None. ## Vocabulary - Application Password: WordPress's built-in per-user authorization credential for external API access. - OAuth 2.1: an authorization-delegation protocol; here, the layer between an AI client and a connector service's own server (distinct from the connector-to-WordPress leg). - RCE: Remote Code Execution — a vulnerability class allowing an attacker to run arbitrary code. ## Bib capsule WP-CONTENT.CO / The WP Week Newsletter, issue #285 (https://wp-content.co/newsletter/archive/285/), published 2026-08-18, covering roughly August 12-19, 2026. A weekly WordPress-ecosystem link-roundup newsletter — this note covers only its most durable multi-issue threads, not every item. ## Author's thesis **Q1 — what's it about:** A weekly digest of WordPress-ecosystem news for the week of August 12-19, 2026, led by WordPress's third security release in under a month. **Q2 — how it's developed:** The newsletter reports each thread with attributed, even-handed "X said, Y responded" summarization rather than argument — its own conclusion names the AI-agent-credential-security question (the WPVibe/Novamira dispute) as the most durable thread to track forward, since it's a live, still-unresolved instance of "AI agents need real WordPress access, and the security model for that access is still being worked out." ## Key arguments - WordPress 7.0.4 closes an author-level RCE, the third security release in under a month — a genuinely urgent patch-now signal for any site running Imagick+Ghostscript. - The WPVibe/Novamira dispute surfaces a real, unresolved technical disagreement about whether an AI-connector plugin should auto-revoke stored WordPress credentials on uninstall, not just marketing spin. - A vendor's rebuttal that answers adjacent security properties (encryption at rest, user-initiated revocation) doesn't resolve a specific challenged behavior (no revocation on uninstall) — the newsletter's own reporting shows the critic explicitly restating the unaddressed objection afterward. ### WordPress 7.0.4 closes an author-level RCE via malicious file upload on Imagick/Ghostscript stacks > [!quote] ID:rw_atom1 > "WordPress 7.0.4 is now available, fixing a remote code execution vulnerability that could allow a user with an Author-level account or higher to execute code through a malicious file upload on sites using Imagick and Ghostscript." Lead security item of the issue; concrete, actionable severity and affected-stack detail, and the third security release in under a month (following 7.0.2 and 7.0.3). ### WPVibe stores WordPress Application Passwords server-side even after the connector plugin is uninstalled > [!quote] ID:rw_atom2 > "Cintolo maintained that retaining the credentials on WPVibe's infrastructure after plugin removal creates a security risk and argued that uninstalling should revoke the connection by default." Core of the WPVibe/Novamira community dispute — the credential-lifecycle question that WPVibe's OAuth/encryption-at-rest rebuttal did not directly resolve. ### A vendor's rebuttal can reassure on adjacent points without resolving the actual objection > [!quote] ID:rw_atom3 > "WPVibe developer John Turner joined the discussion, explaining that WPVibe uses OAuth 2.1 between the AI client and its server, while its server-to-WordPress connection uses WordPress's built-in application authorization flow. He said access is limited to the capabilities of the account that authorized the connection, credentials are encrypted at rest, and users can revoke them." Turner's reply answers real, adjacent risk properties (transport auth model, encryption at rest, user-initiated revocation) but leaves the specific challenged behavior — no automatic revocation on uninstall — unaddressed, which Cintolo then explicitly restates. ## Permanent candidates None. The strongest candidate (atom 3, "a rebuttal can reassure on adjacent points without resolving the actual objection") sits close enough in mechanism to the existing [[Defining a Term to Exclude the Objection Is Not Answering It]] that a new Permanent Note would fragment rather than sharpen the pattern — connect to that note instead. No second genuinely distinct, non-obvious claim clears the resonance bar in this issue (the security-release item is a factual report, not a generalizable claim), so per the resonance filter this source yields zero Permanent Notes. ## Processing checklist - [ ] Register under [[WordPress Hosting Security Stack MOC]] - [ ] Track whether WordPress.org's plugin review team acts on the credential-retention-after-uninstall question (per Shameem Reza's open review-process feedback call, noted in this issue) - [ ] Revisit FooPlugins' SEO-recovery outcome (~70% YoY organic-search drop, AI-agent-assisted recovery attempt) in a future issue