Aimogen Pro CVE-2026-57719

Exploitation requires a reachable Aimogen Pro upload endpoint on a WordPress site running version 2.8.3 or earlier and the ability to submit a file of a dangerous/executable type (e.g. .php) that the server stores in a web-accessible, script-executable directory. Per the supplied CVSS vector (PR:N/UI:N), no authentication or user interaction is claimed - implying remote unauthenticated exploitation against default configurations of the Aimogen Pro plugin - but this PR:N is not independently confirmed and should be verified, since many WordPress plugin upload flaws in fact require at least low-privilege (subscriber/contributor) authentication. Exploitation is further limited by server hardening that blocks PHP execution in the uploads path, WAF filtering of the endpoint, or the plugin being deactivated.

The signals are severe but incomplete. The reported CVSS 3.1 vector is a maximal 10.0 (network, low complexity, no privileges, no user interaction, scope changed, high CIA), which on its face means unauthenticated remote code execution against default installs. However, no EPSS score, SSVC decision, POC, or KEV entry is provided, so real-world exploitation is unconfirmed - this is a Patchstack catalog entry, not evidence of active attacks. A notable caveat: many WordPress plugin file-upload issues catalogued by Patchstack actually require at least low-privilege authentication (e.g. subscriber or contributor), yet the supplied vector states PR:N; this PR:N should be verified against the vendor/Patchstack advisory because it materially changes priority. If truly PR:N this is a patch-now emergency; if it is in fact authenticated, urgency drops to high rather than critical-emergency. EPSS is unavailable, so probabilistic exploitation likelihood cannot be weighed here.

An attacker locates a WordPress site running Aimogen Pro <= 2.8.3 and sends a crafted multipart request to the plugin's file-upload handler, submitting a PHP web shell disguised or accepted as an allowed file type. Because the handler does not restrict dangerous file types, the shell is written under the webroot; the attacker then requests its URL to execute commands and take over the server. No public exploit is identified at time of analysis, but the low attack complexity makes weaponization straightforward if the endpoint is reachable.