shadowlmd

Thank you! ??

And it doesn’t really matter whether it’s meant to be hit directly or not because bots don’t care. I believe, some checks must be done to avoid such issues. Like it’s done in most other places:

// Exit if accessed directly.
defined( 'ABSPATH' ) || exit;

Directly. It’s not me getting it. It’s some bots, obviously. Check User-Agent string.

That’s a good idea. I was able to trace it. And the error still reproduces if I try to access the same URI.
91.134.248.245 xn--90aebdqtcv.xn--p1ai - [29/Oct/2021:20:55:10 +0300] "GET /wp-admin/includes/class-wp-privacy-data-export-requests-list-table.php HTTP/1.1" 500 0 "https://xn--90aebdqtcv.xn--p1ai/wp-admin/includes/class-wp-privacy-data-export-requests-list-table.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4"

Do you believe that would change anything? I don’t. But I’ll watch for errors in logs. They are rare, happens only once in a few days.

Done.

This is a part of wp-config.php from “stop editing” line:

/* Это всё, дальше не редактируем. Успехов! */
/** Абсолютный путь к директории WordPress. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');
/** Инициализирует переменные WordPress и подключает файлы. */
require_once(ABSPATH . 'wp-settings.php');
define( 'FS_METHOD', 'direct' );

It’s not commented out.

I guess this error appears when bots are trying to access class-wp-privacy-data-export-requests-list-table.php directly.

Update: my guess was wrong, nothing happens when file is accessed directly because the code is inside class.

• This reply was modified 3 years, 4 months ago by shadowlmd.

$ grep ABSPATH wp-config.php
 * * ABSPATH
if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');

Thank you! I can confirm it’s working now.

This doesn’t answer the question unfortunately. I want to disable this particular “vulnerability” check completely.

How exactly can this be ignored? I am sick of receiving email every day about this “vulnerability”. In plugin settings I can ignore everything except for this one. There is just no option to disable this check.

I am not using any panel. And will never be. And no, it is not a user base permission issue, like I already explained in original post:

1. Lighttpd running as www-data
2. Directory permissions are set to user:www-data and 770 permissions