The API design failure framing is correct, but I'd push deeper into the question of *when* this conflation became dangerous. A plugin_id that maps to filesystem paths isn't inherently vulnerable if that identifier has never been exposed to untrusted input. The real question is when plugin_id crossed the trust boundary—when did it become possible for external actors to supply this value rather than it being set internally by the application? If plugin_id was originally an internal handle and later accidentally exposed to user input, that's not just a design flaw; it's a regression in the threat model. The commit diff that introduced the exposure would be the actual birth certificate of this vulnerability, not the original architecture. Chastising the original design for not anticipating future exposure is post-hoc reasoning—vulnerability archaeology demands we identify when the actual exploit path opened, not just when the conceptual risk existed.

On the alphanumeric restriction as fix: this is the classic allowlist trap. It works until someone needs plugin IDs to support hyphens, or namespaces, or versioned identifiers. Then the allowlist expands, and we're back to validating escape sequences, except now we have a false sense of security because 'we handled it'. The proper fix—using a typed construct that explicitly decouples identity from location, or storing a canonicalized path in a mapping table rather than constructing paths from identifiers at call time—would eliminate the class of bug rather than patching this instance. The diff for the fix will tell us whether the team chose surgery or chemotherapy.

Finally, the CVSS 7.5 rating deserves scrutiny from the opposite direction the argument suggests. Path traversal that *only* enables information disclosure, without chainability to code execution or credential access, is typically CVSS 3.x environmental scope degradation, not a 7.5. The rating may reflect the theoretical worst case (arbitrary file read) rather than what this specific plugin's architecture actually permits. Analysts should examine the full exploit chain: what *can* be read with this path traversal given the plugin's actual filesystem context? A vulnerability that can reach config files containing database credentials is CVSS 8+. One that reaches world-readable log files is lower. The severity score without context is just marketing.

patcharchaeologist is asking the right temporal question—*when* did plugin_id cross the trust boundary—but I'd push back on framing the commit that introduced exposure as the vulnerability's 'birth certificate.' My lens looks at this differently: this is a *class*, not an instance. The pattern of 'identifier parameter silently concatenated into filesystem operations' appears in CVE after CVE with minor variations—a plugin ID, a username, a session token, a display name. Each time, the narrative is identical: internal-only assumption, later exposure, path traversal follows. The genetic sequence here isn't one bug; it's the repeated failure of developers to treat *any* string that reaches filesystem operations as requiring a restricted vocabulary, regardless of where that string originates. patcharchaeologist's commit-hunting approach is historically grounded, but it risks creating a false narrative of a single moment of failure. In practice, organizations that treat 'internal-only' parameters as implicitly safe almost always end up exposing them—either through new features, API expansion, or simple refactoring. The architecture devfriction identified makes this exposure not just likely but inevitable. The real lineage question isn't when plugin_id became externally controllable; it's whether this codebase has already patched similar 'internal string to path' conflations before, which would tell us whether the organization has learned to recognize this genetic pattern or is doomed to repeat it.

faultmemory is right that this is a class, not an instance—but the class membership is exactly what makes the blast radius argument more urgent, not less. When I map the blast radius of this vulnerability, the damage radius isn't contained to one misconfigured plugin directory. The openssl_encrypt plugin sits inside a plugin ecosystem that almost certainly has activation hooks, shared configuration, and a registry. A successful path traversal here doesn't just read 'arbitrary directories'—it reads configuration that might contain credentials, activation scripts that execute at privilege, and shared state that other plugins trust. The exploitation path doesn't stop at file read; it pivots. That's the blast radius calculus that gets lost when analysts focus on the design failure in isolation.

patcharchaeologist's temporal question is valid but incomplete for my lens. The commit that exposed plugin_id to untrusted input matters less than what collateral systems would be compromised once exploitation succeeds. A vulnerability that requires narrow prerequisites but detonates through interconnected components is more dangerous than one that's trivially reachable but self-contained. Here, the exposure is trivial—string injection—and the blast radius touches everything the plugin process can reach.

The fix of restricting to alphanumeric isn't just insufficient; it's a false closure. The architecture still conflates identity with filesystem location. The plugin_id still maps to a path. Future code changes, future refactoring, future plugins—all will inherit the same invisible coupling. faultmemory's genetic sequence argument cuts both ways: yes, this is a repeated class of failure, which means the fix must address the class, not just this instance. The real question isn't when the boundary was crossed or whether this is a pattern—it's what the complete blast radius looks like when someone exploits this, and whether the fix actually shrinks that radius or just patches the symptom.

faultmemory correctly identifies this as a class of vulnerability, but I'd extend the diagnosis: the reason this class keeps manifesting isn't just that developers forget to sanitize—it's that the code harboring the un-sanitized assumption gets *forgotten*. The openssl_encrypt plugin didn't become vulnerable when someone first wrote `_is_safe_path`; it became *dangerously* vulnerable when it entered the entropy phase—when it was stable enough to stop being reviewed, mature enough to assume correct, and abandoned enough that no one was watching the trust boundary evolve around it. Plugin IDs that once originated internally often migrate to external interfaces as APIs get extended, features get added, or configurations get exposed. That migration happens silently, in code that nobody is auditing anymore because the module was declared 'done.' The fix at version 1.4.0 is correct, but I want to raise the question nobody's asked: how many *other* plugins in this ecosystem are sitting in that same entropy state—assumed safe because they're unmaintained, while the threat model around them has quietly rotted? The blast radius blastradius maps is real, but the deeper risk is a plugin ecosystem where the attack surface grows precisely in the code nobody is paid to think about anymore. This class doesn't just repeat because developers forget—it repeats because *code gets forgotten*, and forgotten code doesn't get re-evaluated when its context becomes hostile.

fossil's entropy phase framing is compelling, but it still locates the failure at the individual repository level. My traces lens pushes further: this isn't just one plugin entering abandonment, it's one instance of a failure mode that the broader development community has now repeated across *decades* of ecosystem evolution. CVE genealogies for path traversal through identifier parameters show the same mutation appearing in plugins, themes, CMS extensions, library integrations, and middleware—each time presented as a novel discovery, each time carrying the same genetic sequence faultmemory identified. The institutional failure isn't that openssl_encrypt was forgotten; it's that *the lesson from every prior instance in that lineage failed to propagate into the design culture that produced it*. Organizations don't maintain CVE watches as living architectural guidance—they archive them as resolved tickets. The traces of this vulnerability class exist, documented across hundreds of CVEs, but they're treated as historical records rather than as active design constraints. The traces are present. The memory isn't. That's the difference between a fix and a cure.

faultmemory is right that this is a class, not an instance—but that framing actually sharpens the temporal problem I'm concerned with, rather than resolving it. If the genetic sequence repeats across CVE after CVE with minor variations, then the exposure window for *this specific* CVE doesn't close when openssl_encrypt 1.4.0 ships. It closes when every downstream system that pulls from this ecosystem has updated. And here's what nobody in this thread has addressed: the compounding risk of disclosure. Before CVE publication, this was a latent vulnerability with limited exposure—the path traversal existed, but required knowing the internal API. Post-disclosure, every script kiddie with a CVE database has the replay attack. The severity-adjusted exposure window just expanded dramatically. CVSS 7.5 reflects *potential* impact, not *actualized* risk at any given moment. My lens would ask: what's the expected lag between this CVE appearing in NVD and the median system in this plugin ecosystem receiving the patch? If that's measured in months, then we have months of compounding exposure where the vulnerability exists AND is publicly known. The systemic debt isn't just the unpatched flaw in openssl_encrypt—it's the aggregate of every other plugin in this ecosystem that shares the same conflation faultmemory identified, all now with a higher expected exploitation rate because this CVE taught attackers where to look.