quttera

Thank you for your clarification.
We will add more logs wrapping new functionality and will update you once the code released.

Thank you for your help.

In the latest version, 3.3.1.1, we added support to manage the filesystem snapshot as a file instead of in the database.

In order to enable this feature please add

define(‘QTR_FS_SNAPSHOT’, true);

to the wp-config.php file.
The snapshot file will be created into scanner plugin’s directory

Please let us know if this worked for you.

Here is the code snippet presenting the error
=================================================
else
{
$rc = update_option($option,$value);
if(!$rc){
if($logger){$logger->Error(“Failed to update option $option”);}
}else{
if($logger){$logger->Info(“Content of $option updated successfully”);}
}
return $rc;
}

=================================================
The core WP function update_option() (which actually stores data in options table) returns failure.

Can you please check with your hosting provider if they see any errors in communication with the backend database?

The newly released plugin version 3.3.0.83 updated with code logging access to WordPress options table.
This should provide more information on the snapshot load/store issue.

Thank you for the provided information.

The first error means that plugin failed to load checksums of WordPress core files from the following URL (https://api.ww.wp.xz.cn/core/checksums/1.0/?version=)

The second error means that one of the detection patterns failed to be compiled properly.

Can you please share whether the filesystem snapshot related error still persist?

The file system snapshot is a list of files and directories which are queued for further plugin scan.

This list is managed in WordPress’s database (options table) using “qtr_scan_cron_args” name

The mentioned error means that plugin either failed to store this files list in the database or it failed to read it from the database.

Please check PHP error/log files, they should contain additional errors related to database access (options table).

Thank you for the question.

The external scan doesn’t see actual PHP source files but either the HTML pages generated by the PHP code.

Please try to run an internal scan in the heuristic mode, it may help to find suspicious PHP files injecting that JS code.

Once you run an internal scan, please pay attention to alien files which also could be used to inject that infection.

If still nothing found, dump website database, it could be that infection injected directly into the database.

Best Regards