Eli

LOL, that’s funny how there is more than one way to interpret that name. However, I still don’t understand why my plugin would detect that in your Database because the review is on ww.wp.xz.cn and should not be in the content of your website.

I tried to recreate this and it does not find anything on my site after installing that Post SMTP plugin. If this was a DB Scan can you please send me the DB content that was detected. Ideally a text export of that record in the offending table from your DB, or else just copy and paste the full text from that record and let me know what table it was found in.

If you can send me an example of this text then I can confirm that it is in fact a False Positive and then update the definition so that it is not misidentified.

Thank you for reporting this error. However, I was unable to recreate this issue and it does not actually look like it is being caused by my plugin at all. From the technical details provided I can see that there are certainly quite a few queries generated by my plugin that have been stuck in the queue for a few hours, but they all have the status of “waiting for table lock”, and the older queries in the queue which are the cause of the table lock are not from my plugin. Those queries that have started the table lock issue start with:

SELECT  wp_posts.ID                     FROM wp_posts LEFT JOIN wp_term_relationships ON (wp_posts.ID = wp_term_

… but I cannot see the full query from this excerpt, so I cannot tell you who might have generated those queries. Perhaps the server support team can take a closer look and tell you more about the actual cause of the table lock. They should also be able to offer some sort of workaround by setting query time limits or some other so that one rogue query does not lock a table for hours thus preventing other plugins like mine from querying the same table.

Please let me know if you have any other questions or inf you get more info from your server support that you want to share on this issue.

No, that would be a personal choice that you would need to make on your own.

I find that Rewrite Rules in your .htaccess files are the best way to prevent most of your unwanted bots from scraping your site.

Cloudflare is also offering ways to mitigate bot traffic which would take the burden off of you and your server … https://www.cloudflare.com/learning/ai/how-to-block-ai-crawlers/

1. Thanks for reporting this issue to me. I have asked the WordPress Plugin Repository support team and they said that this is currently a wide-spread issue that they are aware of and working on here is the link they provided to track their progress on this issue: https://meta.trac.ww.wp.xz.cn/ticket/8182
2. I’ve heard from some users that MalCare has occasionally flagged issues on sites that later appeared to be clean, with the reported problems resolved after payment but without clear details on the underlying cause. If they’re able to provide specific information about the detected issue, please feel free to share the affected or flagged files with me. I’ll review them using my current malware definitions and, if a legitimate new threat is identified, I’ll make sure it is added to future definition updates so the plugin can detect it going forward.

Thanks for sending me this code. I see where you are call in this JS timeout in the admin_footer hooked function, but I guess my real questions was: why are you putting all this code into the DB?

It is not uncommon for DB entries that contain code to be manipulated by hacker to execute malicious code snippets, that is why WPCode Snippets can be so dangerous. While there is no direct exploit that I am aware of within WPCode itself, I have know many instances of hacks utilize WPCode Snippets to execute they malicious payload. Maybe they used other vulnerabilities to get their bad code into the DB (which is sometimes easier than injecting executable code into php files) but any code recorded in the database would not be executable or dangerous with a plugin like WPCode to eval and run those code snippets.

So, getting back to my original line of questioning: Would you be able to put all this PHP code into a file, like in mu-plugins or something like that so that it’s not executed from within your DB? I feel like that would be more secure overall anyway.

In this case ,since you know that scripts found in the database are intentional, I would suggest that you simply whitelist each of those code snippets the next time they are found in the DB scan. Then they should not come up again unless they are altered, in which case you can review the code again to make sure the the change was intentional and then whitelist the new code changes again.

It looks like they released some new code a few weeks ago that includes a new email template library which uses variable functions. It’s really hard to figure out what these functions might be because of the way they are setting these variables, so it falls under code obfuscation, which is not really allowed in the WordPress plugin repository, but this is a popular plugin so I have whitelisted it for now. I may revisit this later to try to figure out what these variables are being set to and make sure that the way they have included these new classes and templates is actually safe, but for now it should no longer come up as a Known Threat in the scan if you download the latest definition updates.

Innanzitutto, c’è qualcosa che non va se la scansione impiega così tanto tempo. In generale, una scansione completa non dovrebbe durare più di un’ora, nemmeno su un sito web di grandi dimensioni. Se sono presenti molti plugin o se ci sono molti altri siti web installati in sottocartelle nella directory principale del sito, la scansione potrebbe richiedere più tempo, ma di solito questo è indice di un numero elevato di errori di scansione o di un problema critico del sito web che ne causa il blocco o un rallentamento eccessivo. In condizioni normali, la scansione dovrebbe elaborare ogni cartella in meno di un secondo, impiegando solo pochi secondi in caso di problemi con uno o più file in quella cartella. Il sistema di scansione non è progettato per consentire a una singola cartella di impiegare più di 65 secondi senza che venga saltata con un errore o che la scansione fallisca. Pertanto, non è possibile che ogni singola cartella impieghi un’ora intera per essere scansionata.

È necessario lasciare la pagina aperta durante l’esecuzione della scansione, altrimenti il ​​processo si interromperà e sarà necessario riavviarlo. A questo punto, sembra che sia comunque necessario riavviare la scansione, e sarebbe opportuno monitorare attentamente la prima parte del processo, in particolare quando viene visualizzato il messaggio “Preparazione in corso…”, per verificare se si blocca in qualche cartella potenzialmente problematica. Potrei avere un’idea più precisa della causa del problema se mi inviaste uno screenshot della scansione in corso, soprattutto dopo che è andata avanti per un po’. Se la prima scansione è ancora in corso, vi prego di acquisire uno screenshot ora, prima di chiuderla e riavviarla. Potreste anche consultare i file error_log sul vostro server per cercare eventuali indizi sulla causa di questo rallentamento. Inoltre, controllate la scheda Console nello strumento di ispezione del browser per verificare la presenza di errori nella pagina dei risultati della scansione.

Se avete dettagli che desiderate condividere con me e che potrebbero aiutarmi a risolvere questo problema, ma non volete pubblicarli su questo forum pubblico, potete contattarmi direttamente via email per ricevere ulteriore assistenza.

eli AT gotmls DOT net