EmbedPress EUVD-2026-100851

Exploitation requires that the EmbedPress plugin (version before 4.6.8) is installed and active on the target WordPress site, and that the affected feature performs a server-side, credential-bearing request to a third-party API - i.e., the site owner has configured API credentials/integration that the vulnerable endpoint consumes. No authentication, no user interaction, and no special privileges are needed (PR:N, UI:N), and default configurations of an installed plugin are reachable remotely. The practical LIMITING factors are: the plugin must be present and below 4.6.8, and the quota-drain impact is most meaningful when the owner has provisioned paid/metered third-party API credentials; the database-bloat impact applies regardless. There is no confidentiality exposure and no remote code execution.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 base score of 5.3 (AV:N/AC:L/PR:N/UI:N) confirms network-reachable, low-complexity, unauthenticated exploitation requiring no user interaction - the worst case for attacker accessibility. However, the impact is bounded (C:N, I:L, A:N), reflecting resource/data abuse rather than code execution or data theft. EPSS is low at 0.17% (5th percentile), indicating a low modeled probability of broad exploitation, and the vulnerability is NOT in CISA KEV, so there is no confirmed active exploitation. Publicly available exploit code exists (WPScan), which raises opportunistic risk. SSVC adds important nuance: Exploitation=none (no observed attacks) but Automatable=yes and Technical Impact=partial - meaning that while not yet exploited at scale, the flaw can be trivially scripted and mass-fired across WordPress sites, which is consistent with the unauthenticated/low-complexity vector. The signals align coherently: easy to exploit and automatable, but limited blast radius and no current in-the-wild activity. One discrepancy worth noting: the provided vector sets A:N, yet the described impact (exhausting the owner's third-party API quota and writing unbounded database records) is a plausible availability/resource-exhaustion impact that the official vector does not capture - defenders should treat the denial-of-service-via-resource-consumption angle as real despite A:N.

An attacker, without any account or authentication, sends crafted HTTP requests to the vulnerable EmbedPress endpoint on a target WordPress site. Each request forces the server to make a credential-bearing call to a third-party API (burning the owner's paid quota) and to store attacker-controlled cache entries, which the attacker repeats in a loop to drain the quota and bloat the database. Public exploit code is available via WPScan, lowering the barrier to opportunistic, automated abuse.