An authorization workflow gap in the Germanized for WooCommerce plugin for WordPress, versions up to and including 4.1.4, lets an authenticated attacker with Subscriber-level access change their account email to a victim's billing email and then redeem their original, unrotated activation token, causing a pre-existing guest order to be linked to the attacker's account and exposing the buyer's billing name, street address, phone number and purchased items on the attacker's My Account page. Exploitation is conditional: the site must run double opt-in with 'Disable login for unactivated customers' explicitly set to No (non-default), public customer registration must be enabled, the token must be redeemed within its one-day expiry window, and a guest order must already exist whose billing email matches the victim address used. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the stacked configuration and timing prerequisites substantially limit real-world exploitability despite the network attack vector and low attack complexity.
An authorization bypass in the Hustle WordPress plugin (all versions up to and including 7.8.14.3) lets an authenticated user who holds the plugin-granted hustle_create capability - but not hustle_edit_integrations - overwrite the site's active email service provider credentials (AWeber, Constant Contact, Infusionsoft, ConvertKit or HubSpot API keys) with attacker-controlled values, redirecting every subsequent Hustle form lead submission to the attacker's ESP tenant. For HubSpot the same requests can also irreversibly delete the operator's OAuth token, OAuth referer and OAuth current-page option rows, breaking the integration until it is re-authorized. Exploitation is constrained: the attacker must already hold a delegated Hustle capability and must first load a Hustle module wizard page to capture a valid hustle_provider_action nonce, and the site must have an ESP integration configured for the impact to matter; no public exploit code or active exploitation has been identified at time of analysis, and the reported CVSS 4.3 and this_month priority reflect a genuine but bounded risk rather than an emergency.
Missing capability checks in the Perfect Images WordPress plugin (wp-retina-2x) through version 7.2.0 allow any authenticated user holding Author-level access to replace media files that do not belong to them via the /wp-json/wp-retina-2x/v1/replace REST route. Exploitation requires a valid account at Author level or above on a site where the plugin is installed and active; no user interaction and no non-default configuration are needed. Impact is confined to integrity (CVSS 3.1 score 4.3, C:N/I:L/A:N), with no confidentiality or availability effect described in the available sources; no public exploit has been identified at time of analysis, and no CISA KEV entry was supplied.
Authenticated users holding Author-level access or above can raise the role of accounts created through Essential Addons for Elementor's registration form, including accounts registered by unauthenticated visitors via the public form, to a higher role such as Editor. The flaw affects versions 6.6.0 through 6.8.7 and is an incomplete fix of CVE-2026-5193; version 6.8.8 corrects it. No public exploit has been identified at time of analysis, EPSS is 0.18% (7th percentile), and CISA SSVC records no known exploitation, no automatable exploitation, and partial technical impact.
WordPress sites running the BuddyForms plugin versions 2.8.8 through 2.10.0 let unauthenticated visitors permanently delete media files that other guest visitors uploaded, because the plugin does not verify ownership of an attachment before acting on a deletion request. The assessed impact is limited to integrity of guest-submitted media (CVSS 3.1 base score 3.7, AV:N/AC:H/PR:N/UI:N/C:N/I:L/A:N) - there is no confidentiality impact and no path to account takeover; only sites that expose forms allowing guest media uploads are exposed. Exploitation status is low-risk across all signals: no public exploit identified at time of analysis, no CISA KEV listing, SSVC exploitation 'none', EPSS 0.16% (5th percentile), and a vendor patch is available in 2.10.1.
WebDyne versions from 2.022 before 3.022 for Perl disclose application source to unauthenticated clients via the viewer in the default index page. WebDyne's wrapper scripts, such as webdyne.psgi, enable the built-in index page by default. Its source viewer returns files under the document root named in the source parameter of an HTMX request, including .psp, .pm and .pl files. A remote attacker can read the application's Perl code, including the __PERL__ blocks of .psp pages and any credentials they hold.
WebDyne versions from 2.031 before 3.022 for Perl execute files with .psp anywhere in the name as Perl pages. WebDyne decides whether to run a requested file as a page by matching its name against WEBDYNE_PSP_EXT_RE, which has no end anchor. An application that accepts uploads by checking only the final extension lets a remote attacker upload a file such as report.psp.pdf and run its embedded Perl by requesting it.
WebDyne versions from 2.014 before 3.022 for Perl reflect request parameters unescaped into form field values, allowing cross-site scripting. The textfield, password_field and filefield tags fill their value attribute from the request parameter of the same name. WEBDYNE_CGI_AUTOESCAPE, which controls escaping of these values, defaults to off. From 2.022, WebDyne::HTML::Tiny also replaced its entity_encode method with one that returns its input unchanged, so enabling WEBDYNE_CGI_AUTOESCAPE has no effect. A remote attacker can inject script into any page using these tags through a crafted link.
WebDyne versions from 3.007 before 3.022 for Perl execute .psp files outside the document root via path traversal in the PSGI API route fallback. When a request matches no file, the PSGI handler retries it as an API route through api_filename. That keeps .. segments in the request path and only checks that the joined path starts with the document root, which a request for /../private passes. A remote attacker can run the embedded Perl in any .psp file the server can read, such as one uploaded to a directory outside the document root.
WebDyne versions from 2.014 before 3.022 for Perl issue session cookies without the Secure, HttpOnly and SameSite attributes. WebDyne::Session sets its session cookie with only a name, value and path. Browsers then send the session ID over plain HTTP and with cross-site requests, and expose it to page scripts. A network attacker or an injected script can steal the session, and another site can make requests that carry it.