preg_match delimiter warning in sanitize_var() when rendering shortcode packages

Hello,

I would like to report what appears to be a bug in WP Download Manager Free 3.3.51.

We are seeing a very large number of PHP warnings like this:

preg_match(): Delimiter must not be alphanumeric or backslash

The warning points to:

/content/plugins/download-manager/src/__/__.php

After debugging, the warning appears to originate from:

WPDM\__\__::sanitize_var($value, $sanitize = '')

In the default branch, the method does this:

if($sanitize !== ” && $value !== ” && @preg_match($sanitize, ”) !== false) {
$value = preg_replace($sanitize, ”, $value);
}

In our case, $sanitize is repeatedly the string:

"array"

Since “array” is not handled by any explicit case in sanitize_var(), it falls into the default branch, and the code effectively does:

@preg_match('array', '')

which triggers:

preg_match(): Delimiter must not be alphanumeric or backslash

We added temporary debugging and a backtrace. The relevant call chain looks like this:

– do_shortcode()
– WPDM\Package\Shortcodes::singlePackage()
– WPDM\Package\Package / PackageController::fetchTemplate()
– PackageController::metaData()
– wpdm_sanitize_var()
– WPDM\__\__::sanitize_var()
– WPDM\__\__::sanitize_array()
– WPDM\__\__::sanitize_var() again, this time with $sanitize = ‘array’

This happens while rendering pages with WPDM shortcodes. In our test, a single page with 6 download packages already triggered many repeated occurrences.

We are seeing the same issue in two separate projects. We use a monitoring system that still captures these warnings despite the “@” operator, so the logs for both projects are being flooded. Because even a page with only 6 downloads already produces many repeated warnings, this becomes a real operational problem in monitoring and log volume.

So it looks like “array” is being used as a sanitize/validate value somewhere in the package metadata/template flow, but sanitize_var() has no case for “array”, and the default logic incorrectly treats unknown sanitize values as regex patterns.

This does not look like an isolated site-specific regex issue, but like a plugin-side fallback bug for unknown sanitize values.

Suggested fix:
– add an explicit case ‘array’, or
– do not treat unknown $sanitize values as regex patterns in the default branch

For example, the default branch could simply skip preg_match()/preg_replace() for unknown sanitize values.

Could you please confirm whether this is a known issue?

Best regards