Background
Both scanner-targeted.php and scanner-general.php skip pattern-matching for any file over a hardcoded 5MB cap ($config['max_file_size'] in each script), applied in build_file_list() before checksum verification ever runs. Checksum verification (wp core verify-checksums via checksum-verify.php) has no size limit of its own — it's a separate mechanism entirely.
For a file that's part of WordPress core or a verified plugin, this is harmless: a checksum match already proves the file is byte-identical to the official release, so skipping pattern-scanning on top of that is redundant, not a gap.
The actual gap
A large (>5MB) file that isn't covered by any checksum manifest — a custom theme asset, a plugin not in the verified list, something under uploads/ — currently gets neither check. It's silently excluded from pattern-scanning by size, with no checksum fallback to catch it either.
There's currently no way to manually work around this:
- The scanners only accept a directory as
start_path, not a single file (build_file_list() uses RecursiveDirectoryIterator).
max_file_size isn't exposed as a CLI flag or argument — it's a hardcoded literal in each script's $config.
Proposed follow-up
- Add a
--max-file-size flag (bytes, or a friendly 5MB/20MB form) to both scanners, and thread it through wp-ops malware-scan's own --max-file-size option and wp-ops wp-cli scanner-targeted/general.
- Consider also accepting a single file as
start_path (not just a directory), so a specific known-large, non-core file can be pattern-scanned in isolation without raising the cap for a whole tree.
Surfaced while writing up the malware-scan post on the blog — a reader asked how to manually verify a checksum-skipped large core file (answered with the WordPress.org checksums API), which is fine for core/plugin files but doesn't help for this non-checksummed case.
Background
Both
scanner-targeted.phpandscanner-general.phpskip pattern-matching for any file over a hardcoded 5MB cap ($config['max_file_size']in each script), applied inbuild_file_list()before checksum verification ever runs. Checksum verification (wp core verify-checksumsviachecksum-verify.php) has no size limit of its own — it's a separate mechanism entirely.For a file that's part of WordPress core or a verified plugin, this is harmless: a checksum match already proves the file is byte-identical to the official release, so skipping pattern-scanning on top of that is redundant, not a gap.
The actual gap
A large (>5MB) file that isn't covered by any checksum manifest — a custom theme asset, a plugin not in the verified list, something under
uploads/— currently gets neither check. It's silently excluded from pattern-scanning by size, with no checksum fallback to catch it either.There's currently no way to manually work around this:
start_path, not a single file (build_file_list()usesRecursiveDirectoryIterator).max_file_sizeisn't exposed as a CLI flag or argument — it's a hardcoded literal in each script's$config.Proposed follow-up
--max-file-sizeflag (bytes, or a friendly5MB/20MBform) to both scanners, and thread it throughwp-ops malware-scan's own--max-file-sizeoption andwp-ops wp-cli scanner-targeted/general.start_path(not just a directory), so a specific known-large, non-core file can be pattern-scanned in isolation without raising the cap for a whole tree.Surfaced while writing up the malware-scan post on the blog — a reader asked how to manually verify a checksum-skipped large core file (answered with the WordPress.org checksums API), which is fine for core/plugin files but doesn't help for this non-checksummed case.