wp_kc

It is not a publicly accessible web site, and it has WP_DEBUG enabled. These messages only show up in the debug log file while accessing /wp-admin area of the web site. Nothing special has to be done, simply log in to the site. The log file grows by about 2MB per day with these types of messages.

No front end issues are noticeable. I just thought you might be interested, since it looks like these message will turn into errors in the future.

I still got the same result with that…
03-May-21 14:48:38 ERROR Fatal error: forking process failed (cURL error 56: OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0: AJAX API). Aborting

But, I figured it out. I have CloudFlare on the site with the problem, and I have “Authenticated Origin Pulls” enabled. When I disabled Authenticated Origin Pulls in my server configuration and paused CloudFlare, it started working. Just pausing CloudFlare alone did not fix it.

So I am assuming the problem is happening because the server can’t do a simple loopback when Authenticated Origin Pulls is on.

I’m research if there is a fix for this. But at this point, it does not look like it is a NinjaScanner problem. So I’m marking this as resolved. Any more ideas would be appreciated though.

I commented out both lines, but still got the same result.
30-Apr-21 05:25:32 ERROR Fatal error: forking process failed (cURL error 56: OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0: AJAX API). Aborting

P.S. If I switch to WP-CRON mode, the error message is pretty much the same…
29-Apr-21 15:25:37 ERROR Fatal error: forking process failed (cURL error 56: OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0: WP-CRON). Aborting

It looks like the Elementor developers found the problem and fixed it. The latest version released 8 hours ago is no longer generating these messages.

Fixed!

Thanks for the speedy response.

It works again! Thanks, you guys are awesome.

Thanks. I filed a bug report on your web site. Here is an update for others reading this support thread.

I found and fixed one problem only to find another. A plugin was adding a “defer” parameter to the link for jquery. Since Envira adds inline script in the header right after all the queued scripts are loaded, jquery wasn’t ready for it yet. There was a “jQuery undefined” error because of this. It might be better to surround that code in an onDocumentLoaded event.

After the defer issue was fixed, the images now load on the gallery page as normal. When you click on an image in the gallery, it opens in a lightbox, so that works too. But there is no way to close the lightbox or navigate to the next image in the gallery. When I looked at the javascript debug console, I saw this error immediately after clicking an image to view it…

Uncaught TypeError: s.get(...).style.removeAttribute is not a function
    F /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:11
    jQuery 32
    M /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    D /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    onload /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    L /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    envirabox /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:11
    jQuery 2
envira-min.js:11:1033
    F /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:11
    jQuery 32
    M /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    D /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    onload /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    (Async: EventHandlerNonNull)
    L /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:10
    envirabox /wp-content/plugins/envira-gallery-lite/assets/js/min/envira-min.js?ver=1.8.3.1:11
    jQuery 2

Thanks.

Thanks.

Some additional details…

Server setup:

• Debian 9
• WordPress – Version 4.9.8
• PHP 7.0 FPM
• Advanced Custom Fields – Version 4.4.12
• Advanced Custom Fields: Flexible Content Field – Version 2.1.0 (w/valid license)
• Advanced Custom Fields: Repeater Field – Version 2.1.0 (w/valid license)

Conditions causing the bug:

• The problem occurs when trying to add a new location rule to a field group using a single flexible content field.
• The flexible content field had 12 layouts, with a total of 37 sub-fields among them.
• The field group had 6 Location rules.
• 8 ‘Hide on Screen’ items were checkmarked
• This setup had been working in the past on the same server, with the same configurations files.
• Trying to add a new location rule resulted in the last 3 layouts (along with their 7 sub-fields) being deleted. The new rule also was not saved. And the last field of the last surviving layout was deleted, as well as some settings of the second to last sub-field.

Temporary work-around:
I bumped the php.ini variable ‘max_input_vars’ up to 2000, restarted apache, reconstructed the field group and was able to save it. So too many form variables being submitted at once is definitely causing the problem. Luckily, everything that used that field group was restored to normal operation after reconstructing the field group. Then I returned ‘max_input_vars’ to its default value of 1000 and restarted apache again to prevent attackers from trying to abuse GET and POST requests.

Suggested solution:
It is my understanding that WordPress is moving toward using its REST-API for all screens in the admin area. Maybe now is a good time to start converting ACF to submit all data from the field group editor as a single JSON data string. This would avoid triggering the default 1000 input variable setting on apache.

I bought and installed Ninjafirewall WP+ Edition. Syslog events are working great. I wrote a Fail2Ban filter for it too. Also available on Github

Thanks for your response. It sounds like I need to upgrade!

• This reply was modified 6 years, 3 months ago by wp_kc.

https://github.com/philipjohn/exploit-scanner-hashes

The file goes in the plugin’s main directory.

I don’t know why it is not working then. When I do everything you recommended, the image urls show up as “https://234” or similar, like it is receiving an ID. However, if I change your code to…

$acf_exists = function_exists( 'acf_shortcode' );

        foreach ( $posts as $post ) {
            $image = '';
            $url   = '';
            $alt   = '';
            if ( $thsource == 'custom-field' ) {
                $debug .= 'Using custom field;';
                //$url = $basic_url = get_post_meta( $post->ID, get_option( 'relpoststh_customfield', $this->custom_field ), true );

if ( $acf_exists ) {
   $url = $basic_url = get_field( get_option( 'relpoststh_customfield', $this->custom_field ), $post->ID );
} else {
   $url = $basic_url = get_post_meta( $post->ID, get_option( 'relpoststh_customfield', $this->custom_field ), true );

…then everything works perfectly. I’m guessing that ACF does not store custom field data in the postmeta table using the specified ACF field name, but instead does some sort of name mangling that get_field() undoes.