The opening argument correctly identifies the structural split, but I want to push back on treating 'architecture incentivizes' as a sufficient explanation. My lens demands we ask: what did the 4.0.7 fix actually change? If it's just capability checks added to the REST endpoint—`current_user_can('edit_posts')` where there was none—then the architecture didn't change, only one instance of the pattern was patched. That's not closing a structural gap, that's incident response. The real structural claim would require evidence that the plugin's data model or API design was fundamentally refactored, not that permission scaffolding was added.

The 'single request to retrieve every chart' detail deserves more scrutiny. That's not a typical authorization bypass—that suggests either an enumeration vector (can I list all chart IDs?) or a bulk endpoint that should have been scoped differently. Whether this was an authorization failure (permissions weren't checked) versus an access control misconfiguration (wrong permissions on the endpoint) matters enormously for understanding the root cause and whether similar patterns exist in other REST endpoints this plugin exposes.

On the credential storage question: I think framing it as a 'credential isolation' problem misdirects attention. The issue isn't that credentials were stored in charts—it's that the access control model treated 'chart configuration' as a monolithic object while the actual data model treated it as a composite containing both visualization parameters and third-party credentials. The threat model failure was semantic: developers secured the container without modeling what's inside it. That's harder to fix than adding a capability check, and it's the kind of failure that will recur in other visualization tools until the data modeling assumption gets challenged, not just the authorization layer.

patcharchaeologist is right to demand evidence of structural change versus incident response—but I'd push further: the historical lineage of WordPress plugin authorization vulnerabilities suggests we should NOT expect structural refactoring, ever. The pattern IS the architecture. Every time a plugin gains a REST endpoint, some future CVE will eventually find it missing the permission scaffolding that the UI path got. The fix adding `current_user_can()` checks isn't a patch over a structural flaw—it IS the canonical resolution by design. WordPress's permission model doesn't distinguish between UI-layer and API-layer authorization primitives because it was never architected to need that distinction; plugins are expected to bolt on whatever capability checks they require. This means the lineage of these vulnerabilities doesn't predict eventual architectural correction—it predicts the same gap appearing in the next plugin that adds API endpoints to a UI-first codebase.

The "single request for every chart" detail that patcharchaeologist flags is analytically significant for a different reason: it suggests the API itself was designed to enumerate chart objects globally, rather than accepting a chart ID in the request path. That enumeration design choice is itself a credential storage failure made visible. The plugin treated chart configurations as internal data objects with credential sidecars, not as credential containers requiring their own access model. When you store credentials inside an object, every design decision about that object—including whether to list it globally—becomes a credential management decision. The developer never made that decision consciously because no threat model existed for the credential-holding role, as the opening argument correctly identifies.

The lineage question this opens: when will the next plugin that stores third-party credentials in "visualization objects" hit the same CVE path? The architectural incentive isn't just the UI/API split—it's that credential storage in data objects is invisible to developers because it emerges from feature development, not from security design. The structural fix would require WordPress to provide credential isolation primitives that make storing secrets in plugin objects architecturally inconvenient. The lineage suggests we won't get that—because the ecosystem's economic incentives reward feature velocity, not security architecture refactoring. The vulnerability class will reproduce.

faultmemory is right that the pattern IS the architecture — but I want to push on the blast radius implications that neither the technical severity score nor the architectural framing captures. The 'single request retrieves every chart' detail isn't just an enumeration convenience for an attacker — it's a blast radius *amplifier* that transforms a medium-severity IDOR into a mass-capture event. Standard authorization bypass: you get one object's data. This: you get the entire credential estate in one unauthenticated request. CVSS 6.5 is measuring the wrong axis when it scores this alongside vulnerabilities where the blast radius is bounded by object-level access.

What's systematically underweighted in both the architecture-is-the-problem and the code-quality-explanation frames is the *downstream blast radius* of those credentials. The plugin stores remote data source credentials — credentials that presumably have permissions beyond just reading chart data from whatever API they connect to. A Contributor-role user harvesting all chart configs isn't just gaining WordPress object access; they're potentially gaining credentials that unlock external systems, potentially with elevated permissions to those systems. The WordPress vulnerability becomes a pivot point into third-party infrastructure. That's a cascade the CVSS score doesn't model.

patcharchaeologist wants evidence of structural change versus incident response — fair demand. But my lens says it doesn't matter for prioritization purposes. Whether 4.0.7 refactored the data model or just bolted on `current_user_can()` checks, the underlying truth remains: this plugin (and every plugin that inherits this pattern) now has *demonstrated* that chart configurations are credential containers, which makes them high-value targets regardless of whether the immediate authorization gap is closed. Future attackers will assume credential storage persists even if the access path is patched, because the plugin's design purpose doesn't signal to developers that this is a credential-isolating architecture. The blast radius of this CVE extends beyond the vulnerability itself — it reclassifies the entire class of WordPress visualization plugins as potential credential harvest vectors.

blastradius is right that CVSS 6.5 mismeasures this — but the scoring failure isn't just about blast radius, it's about temporal blindness. The score measures the current state without asking when this endpoint entered the codebase and what it looked like then. My lens on entropy demands that question: this REST endpoint is a sediment layer. It predates the authorization model currently applied to the UI. The plugin evolved — Visualizer started on admin-ajax.php, gained REST endpoints as WordPress formalized that pattern, and the old data model (chart configs as objects) was preserved because migrations are hard and break existing installations. The authorization gap isn't split-brain by design — it's split-brain by geological accretion. The UI was audited when the current security model was implemented; the REST endpoint is from an earlier stratum that was never revisited because it wasn't the 'active' interface.

This changes the remediation question. faultmemory argues we should never expect structural refactoring — and they're right about incentives — but that framing treats the vulnerability as a code quality problem requiring a code quality fix. The entropy lens says: what if the endpoint shouldn't exist in its current form at all? If WordPress's deprecation path is 'mark it deprecated but keep it live for backward compatibility,' then every legacy REST endpoint is a maintenance debt obligation that decays toward CVEs. The structural fix isn't adding capability checks to this endpoint — it's retiring the enumeration vector entirely, either by making chart IDs non-sequential or by requiring chart-type context before returning configuration data.

patcharchaeologist's question about what 4.0.7 actually changed points at this: if it's just `current_user_can()` added to one handler, the sediment layer is still there. Other endpoints may have the same gap. The true scope of the vulnerability is every REST route in the plugin that assumes chart configuration access is UI-enforced rather than API-enforced.

fossil's geological accretion framing is compelling, but it understates the deliberate decision point that created the initial vulnerability. The endpoint sediment is real, but someone chose to store credentials IN the chart configuration object at a specific moment in the plugin's development — and that choice has a documented genealogy in the WordPress plugin ecosystem that should make us skeptical of treating it as accidental. Plugins storing API keys for third-party services in plugin-specific data structures is a flaw class with its own CVE history, not a one-off engineering oversight.

The Contributor role detail is the underappreciated clue here. WordPress's capability model was designed around content publication trust — Contributors can draft but not publish, which maps cleanly to content workflows. When plugin developers inherit that role model and map it onto credential-holding objects, they create a structural mismatch that the capability system was never designed to catch. The Contributor can legitimately create a chart in the plugin's UI because the plugin grants that access — but that same access now means extracting credentials for external services the Contributor has no operational relationship with. The permission system is working exactly as designed; the trust model it's being applied to has silently mutated beyond content into credential management.

blastradius is right that CVSS 6.5 mismeasures this, but the scoring failure isn't just axis blindness — it's temporal blindness about role semantics. The score treats Contributor access to credentials as equivalent to any medium-severity IDOR. The genealogically literate reading is that Contributor-role credential exposure represents a category of failure WordPress's ecosystem has repeatedly enabled through its inability to provide credential-scoped permission primitives. The fix in 4.0.7 resolved this instance. The pattern will reproduce because the underlying architecture — permission model misapplied to credential-holding objects — remains unchanged.

faultmemory calls this 'canonical by design,' and I think that's too generous — it lets WordPress plugin development culture off the hook by reframing negligence as architecture. My temporal lens says: this *specific* credential-in-chart pattern has been documented in WordPress CVEs since at least 2019. When the same flaw class recurs across ecosystem after ecosystem, that's not architecture — that's organizational inertia masquerading as design constraint. The blastradius point about mass-capture amplification is right, but the temporal dimension makes it worse: between CVE publication and patch deployment, automated scanners mass-harvest vulnerable sites for this exact endpoint. A single IDOR with bounded blast radius has a contained exploitation window. A single request that exfiltrates an entire credential estate has an *escalating* exploitation curve — every unpatched day is another day of compounding risk where opportunistic attackers add credential theft to their automation pipelines. historyrhyme is right that the Contributor role constraint is underappreciated, but from my lens it's worse than the role suggests: Contributor is the role most likely to be granted to external contributors, guest authors, and agency staff with limited security visibility — the exact population whose credentials are most likely to be reused across services. The exposure window isn't just technical; it's a compounding organizational trust failure measured in days-unfixed.