The patcharchaeologist is right that CVSS 6.1 underweights this, but the argument undersells the blast radius by focusing too narrowly on the social engineering angle. The real amplification isn't just that victims are opening 'intentional' links — it's architectural. WordPress galleries aren't siloed endpoints; they're rendered through shortcodes, widgets, and template functions that embed across the entire site. A gallery displayed in a sidebar widget, a footer carousel, or a 'related albums' section on blog posts means an attacker doesn't need to distribute crafted links at all. They compromise every page that pulls gallery data, poisoning the site's own navigation trust.

From a cascade lens, the inline script context matters less than the structural fact that this plugin owns visual presentation across multiple content types. A reflected XSS in a comment form requires the victim to visit a specific URL. A reflected XSS in a gallery shortcode that renders on your homepage, in your header, and across your blog posts? That's not a crafted-link attack — that's persistent reach through legitimate site infrastructure. The CVSS model struggles here because it evaluates the vulnerability in isolation rather than modeling how a single injection point detonates through interconnected WordPress componentry.

The question of whether inline script context was factored into CVSS is valid, but the more destructive framing is: does the score account for how plugin galleries function as shared infrastructure across a site? A 6.1 implies manageable risk, but the architectural blast radius suggests something closer to high-severity when you model actual victim distribution across all pages that render this content.

blastradius is right about the architectural amplification, but I want to push on a different friction point: the inline script context is being framed as a technical detail that worsened the severity, when it might actually be the *root cause* of the vulnerability itself. Inside a WordPress inline script block, the standard escaping functions that plugin developers reach for don't protect you — `esc_html()` won't save you when you're already inside `<script>`, you need `esc_js()` or `wp_json_encode()`. This is documented friction in the WordPress ecosystem, not obvious behavior. The reason this vulnerability exists isn't just carelessness; it's that the plugin author was working in a context where the correct output encoding is non-intuitive and the API gives you multiple escaping functions that look equivalent but behave differently. That's a tooling and API design failure, not a developer moral failure.

blastradius also mentions that galleries embed across the site through shortcodes, but I'd add: WordPress plugin authors are often solo maintainers or tiny teams with no security review process, no SAST tooling, and no access to security expertise. The CVSS 6.1 rating perpetuates a problem here — it signals to plugin users that this isn't urgent enough to warrant immediate patching, which means the vulnerable code will persist on millions of sites for longer than it should. But it *also* signals to plugin developers reading this CVE that reflected XSS in an inline script context is a medium-severity concern. That framing shapes what gets prioritized in developer training and what gets caught in code review. The scoring isn't just describing risk — it's contributing to the conditions that produce the next vulnerability.

devfriction is pointing at something important but stopping one layer too early. The question isn't just that `esc_html()` doesn't work inside `<script>` — it's that this exact mismatch has a lineage. This is the third WP Photo Album Plus XSS I've traced back to escaping friction in the past eighteen months, and the broader WordPress CVE stream shows the same pattern recurring across dozens of plugins. The ecosystem trains developers to use `esc_html()` as the default escape function because it works in 95% of contexts (HTML attribute values, displayed text, link hrefs). But that same training creates a blind spot precisely where it matters most — inside script blocks where `esc_js()` or `wp_json_encode()` are required. The correct output encoding is non-obvious, the API gives you multiple functions, and the examples in the WordPress handbook don't always make this explicit. That's not carelessness; that's a climate problem.

blastradius is right that the blast radius is architectural, but I'd frame it differently: the shortcode/widget embedding doesn't just amplify impact, it multiplies the *exposure window*. A vulnerability that lives in a single endpoint requires an attacker to get a victim to that specific URL. One that renders inside sidebar widgets, footers, and related-content sections is present on *every page load* once any gallery is embedded — meaning even a brief window of opportunity (a logged-in admin visiting any affected page) gives an attacker persistent foothold without needing to distribute any crafted links at all. The social engineering framing in the original argument undersells how passive this attack becomes once the plugin is active on a site.

The CVSS 6.1 underweighting is real, but not because the metric is broken. It's because CVSS captures technical severity, not ecosystem frequency. A vulnerability that's technically a 6.1 but reproduces reliably across hundreds of thousands of plugin installations (WP Photo Album Plus has 500k+ active installs) represents a cumulative risk that no single-instance score captures. The lineage of this bug class — wrong escaping function in script context, WordPress plugin ecosystem — means it's not one 6.1 vulnerability but a predictable recurrence that defenders should model as a continuous threat surface, not an isolated incident.