WPDM Premium Packages SQL Injection: CVE-2026-61948
DygDog Team··6 min read
A serious WPDM Premium Packages SQL Injection vulnerability has been disclosed affecting the popular WordPress digital-product plugin. If your site runs WPDM – Premium Packages version 6.2.0 or earlier, update to version 7.0.0 or later immediately.
The flaw — CVE-2026-61948, currently reserved at CVE.org — carries a CVSS 3.1 score of 9.3 Critical from Patchstack. That score reflects a network-accessible, unauthenticated issue that requires neither configuration nor user interaction to reach. For a WordPress download portal, membership site or digital storefront, the potential consequence is unauthorised access to database-held content.
DygDog has added passive detection for this exposure as Module 74: wpdm_premium_packages_sqli. It runs automatically on every scan, identifies externally observable signals of the affected plugin and version, and reports a clear finding with a remediation priority. It does not send SQL injection payloads and cannot interact with your database.
What is the WPDM Premium Packages SQL Injection vulnerability?
CVE-2026-61948 is an unauthenticated SQL injection issue (CWE-89) in WPDM – Premium Packages, a WordPress plugin developed by Shahjada for selling and distributing digital downloads. Patchstack's advisory identifies versions up to and including 6.2.0 as affected and version 7.0.0 as the patched release.
SQL injection occurs when user-supplied data reaches a database query without adequate sanitisation. The attacker does not need to be logged in, does not need to hold any role in WordPress, and does not need to persuade an administrator to take any action. The issue is reachable directly over the network.
Why CVE-2026-61948 matters for WordPress
The CVSS 3.1 vector for this issue is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L. Each element of that string has a practical meaning:
- AV:N — reachable over the network, no local access required
- AC:L — low attack complexity; no special conditions or unusual configuration
- PR:N — no privileges required; the attacker is unauthenticated
- UI:N — no user interaction required
- S:C — the scope changes — the exploit can reach resources beyond the vulnerable component itself
- C:H — high confidentiality impact against in-scope data
That combination is what places the score at 9.3 Critical and what distinguishes this from routine plugin maintenance. Many WordPress vulnerabilities require an authenticated user to trigger them. This one does not.
The EUVD reference for this issue is EUVD-2026-48206.
Affected and patched versions
| WPDM – Premium Packages version | Status | Action required |
|---|---|---|
| 6.2.0 and earlier | Affected | Update immediately |
| 7.0.0 and later | Patched for this advisory | Confirm the update completed |
| Version unknown | Cannot be assessed externally | Check WP Admin or WP-CLI |
If your installed version is not externally visible, do not assume the plugin is absent or safe — confirm from inside the WordPress environment.
How DygDog detects the WPDM vulnerability
DygDog's Module 74 is entirely passive. It does not send SQL syntax, does not submit form data, and makes no POST requests under any code path.
Detection runs in three sequential stages:
Stage 1 — Validate the target. DygDog applies its SSRF protections before any outbound request is made.
Stage 2 — Confirm WordPress. The homepage is fetched. If wp-content/, wp-includes/, or a WordPress generator tag is present, the site is treated as WordPress. If not, the module stops with no finding.
Stage 3 — Identify plugin presence and version. When WordPress is confirmed, DygDog scans the page HTML for asset paths containing wp-content/plugins/wpdm-premium-packages/. If those are found, it extracts the version from ?ver=X.Y.Z query strings on those assets. Where no version string is available, DygDog makes one additional tightly scoped GET request for the plugin's public readme.txt — only after the plugin has already been confirmed in the HTML — and reads the Stable tag: header.
The module stops at the first stage where conditions are not met. A site with no observable WordPress signals receives no finding. A site with WordPress but no WPDM asset references receives no finding.
What a DygDog result means
| DygDog outcome | Meaning | Next step |
|---|---|---|
| Critical | Plugin observed; public version is 6.2.0 or earlier | Update to 7.0.0 or later immediately |
| Warning | Plugin observed; version could not be established from public signals | Confirm the installed version from WP Admin or WP-CLI |
| No finding | Plugin not observed in the externally visible page source | Do not treat this as proof the plugin is absent |
A Critical finding means DygDog identified credible public signals of an affected version. It does not mean the site has been compromised, and DygDog cannot determine whether exploitation has occurred. The finding identifies a remediation priority — the appropriate response is to patch and review relevant logs, not to conclude that a breach has taken place.
Patch WPDM Premium Packages now
- Back up your WordPress site and database before making changes.
- Update WPDM – Premium Packages to version 7.0.0 or later via WordPress Admin → Plugins → Update, or via WP-CLI:
wp plugin update wpdm-premium-packages. - Confirm the installed version in WP Admin or with
wp plugin get wpdm-premium-packages. - Review server, database, and application logs for unusual activity in the period before patching.
- Ensure that WordPress core, all active plugins, and all active themes have a defined owner responsible for applying updates.
If you cannot update immediately due to a compatibility dependency, treat the delay as a documented risk decision. Assess whether compensating controls — such as WAF rules restricting the affected endpoint — can reduce exposure in the interim. Compensating controls do not replace the vendor patch.
For the authoritative patch guidance see Patchstack's WPDM – Premium Packages advisory.
WordPress security needs visibility
Plugin risk accumulates quietly. WordPress environments accrue plugins through site migrations, agency handovers, marketing integrations and legacy tooling that outlives its original purpose. A plugin installed for a single campaign can remain active — and unpatched — for months.
External visibility helps surface that risk before it becomes an incident. DygDog evaluates the public attack surface as an unauthenticated party would see it, maps observable signals to known vulnerability data, and returns findings with specific remediation steps.
Module 74 means that from this point on, any DygDog scan of a WordPress site will automatically check for externally observable exposure to the WPDM Premium Packages SQL Injection vulnerability alongside the scanner's broader WordPress, configuration, and web application checks.
Scan your WordPress site
Scan your site now to check for observable WPDM – Premium Packages exposure and other configuration issues across 74 passive security checks.
For further reading: