DEBUG.LOG 132MB en 9 días

<span>Vuelvo a consultar sobre este problema porque, aunque ya lo reporté anteriormente, el tamaño que está alcanzando </span><span>debug.log</span><span> empieza a ser preocupante.</span>

<span>El archivo fue eliminado/reiniciado el </span><span>8 de agosto</span><span> y hoy, </span><span>17 de agosto</span><span>, ya ocupa aproximadamente </span><span>132 MB</span><span>.El problema se produce de forma repetitiva durante la carga de WordPress y el backtrace muestra sistemáticamente a WP Vulnerability dentro de la cadena que desencadena los avisos:</span>

include_once('/plugins/wpvulnerability/wpvulnerability.php')
require_once('/plugins/wpvulnerability/wpvulnerability-schedule.php')
wpvulnerability_schedule_core_events
wpvulnerability_get_update_schedule_slug
wp_get_schedules
apply_filters('cron_schedules')

Por lo que he podifo observar las llamadas concretas a __() pertenecen a WooCommerce, WooCommerce Subscriptions y otros plugins, pero lo que me llama la atención es que WP Vulnerability se encuentra en todas las lineas del log llamando a wp_get_schedules() durante su propia carga (wp-settings.php / carga del plugin), antes de que WordPress haya alcanzado init.

No se trata de un aviso aislado. En apenas unos segundos se repite continuamente.

El resultado práctico es que debug.log ha alcanzado 132 MB en aproximadamente nueve días.

Versión de WordPress: 7.0.4
Límite de memoria de WordPress: 512 MB
WooCommerce Subscriptions   por WooCommerce – 9.1.0
WooCommerce   por Automattic – 11.0.1
nformación del servidor: Apache
Arquitectura del servidor: Linux 5.10.0-45-amd64 x86_64
Versión de PHP: 8.3.32
PHP post max size: 100 MB
PHP time limit: 30 PHP
max input vars: 6000 Versión
cURL: 7.74.0, OpenSSL/1.1.1
Versión de la base de datos de WordPress: 11.0.1

The page I need help with: [log in to see the link]