• For the last 2 weeks I have getting this error in my log files, every since the October Wordfence update. I have the latest version of it.

    PHP Fatal error: Call to undefined function wp_create_nonce() in /public_html/wp-content/plugins/wordfence/lib/wfUnlockMsg.php on line 4

    How do I fix?

    https://wordpress.org/plugins/wordfence/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter rliston

    (@rliston)

    I am still getting these errors.
    I am going to have to uninstall if I don’t get some answers soon.

    I was looking at this. As In understand it, this error shows in logs a lot and can be indicative of several things. Googling “PHP Fatal error: Call to undefined function wp_create_nonce():” shows a wide swatch of errors attributed to various themes and plugins. A great answer one of our community members provided is in the post below. I’ll quote it for you here:

    https://wordpress.org/support/topic/php-fatal-error-call-to-undefined-function-wp_create_nonce?replies=3#post-6126185

    The error above could also be caused by someone (probably a bot) trying to directly access http://yoursite.com/wp-content/plugins/wordfence/lib/wfUnlockMsg.php

    Accessing the file without having WordPress “include()” it will give that message — the error itself isn’t dangerous, and normal users shouldn’t be going to that page.

    It might mean that your web server lets remote users see what files are in directories (ignoring .htaccess), or there is an anonymous FTP server that shows the same files/folders, or there is a bot that knows what files Wordfence contains, and it’s scanning to see if they exist (possibly looking for sites running outdated versions).

    I see errors in error_log similar to this once in a while, but usually on WP core files. Usually, it is probably nothing to worry about as long as your core and plugins are up to date — aside from being paranoid about having your site tested by someone with ill intentions (but of course that happens daily on most sites, in one way or another.)

    Can you check access logs and see if that file is being hit directly by web traffic?

    Thanks

    tim

    I started getting these messages in my error_log every couple of days now, too, even though in the current version of Wordfence, the wfUnlockMsg.php file is protected from direct access.

    I was able to match the times in the error_log to blocked requests for admin-ajax.php, usually probing for the revslider flaw. In my access_log, I see requests like this:
    "GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=..%2wp-config.php HTTP/1.1" 503 2042 "-" "Mozilla/5.0 (Windows NT 5.2; rv:2.0.1)"

    … so the 503 probably means it was blocked using the Wordfence security network, but I think Wordfence tried to “include” the wfUnlockMsg.php file, even though this was an ajax request. It probably doesn’t hurt anything (other than logging the error message the original poster mentioned), but can the programmers take a look at it? I think there were a few other posts about this a while back, so maybe this was the cause for them too.

    Thanks mwrusnak

    Looks like they are trying to exploit your revslider plugin and view your wp-config.php The developer says thats been patched several versions ago so update the plugin to make sure you are protected (unless its embedded in theme which means you have to get the theme author to do so). When someone tries to use that exploit, it triggers a message that tells you we caught you at it, and that you have been banned. I would assume that the Unlock message is just logic for whatever we send back to the user based on what happened and not necessarily targeting only unlocking accounts.

    tim

    Yep — I don’t even have revslider, so I’m not worried about that part. It’s just that the original poster and I have seen Wordfence showing an error in our error_log files, and I found that it is when ajax requests are blocked, like the one above.

    I think that Wordfence probably shouldn’t send the “unlock” message in response to ajax reqeusts, since real users wouldn’t be directly viewing ajax responses anyway — but if the plugin authors do want the message to be sent during ajax requests, Wordfence should make sure the core file containing wp_create_nonce() has been loaded before the message. (I assume that WP core isn’t fully loaded for each ajax request, which is probably the cause of the missing function.)

    Yeah, I checked the unlock file and it’s pretty specific to the unlock function, but regardless the reason, if that file is called, its performing the function it is supposed to. Are you saying you’d rather have it conditional on whether it sends or not based on the error code the browser receives? 503 is what we serve for blocks, so the bot hitting the page is still going to see an apache error page, regardless of what the file says to display.

    tim

    No, I’m fine with the message itself, it’s just that it sometimes causes the fatal error, mentioned by the first poster above:
    PHP Fatal error: Call to undefined function wp_create_nonce() in /public_html/wp-content/plugins/wordfence/lib/wfUnlockMsg.php on line 4

    I found that it is happening only in ajax requests, and either of these options to fix it is fine with me — either not displaying the message for ajax requests (since most ajax responses wouldn’t be seen directly by real users anyway), or making sure wp_create_nonce() is available before it is used (since WP must not be loading it automatically during ajax requests).

    So is there a resolution to this? We use the error logs on many of our WordPress websites to remotely monitor for site issues, and since this one crops up on all our sites daily, it means that we are constantly inundated with error log emails. Before WF started doing this (it began with an upgrade), we would only get logged errors once a week, or once a month for some sites, and allowed us to proactively resolve PHP issues promptly.

    Please update wfUnlockMsg.php so that if the wp_create_nonce() function is not available (such as in an ajax request), please create a dummy function so that this fatal error is not thrown.

    Having plugins throw fatal errors when there is not actually an issue is very bad practice, regardless of the sistuation the error arises in.

    Thanks

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Fatal errors since upgrade’ is closed to new replies.