Logs showing “Post Status Changed: new → Published ” from unknown users

Not sure what’s going on with the (1) “Post Status Changed” log entries.

But I’m interested in the (2) last_sent[digest] message. Perhaps we can figure this out.

What version of the iTSec plugin are you using (Pro 6.8.5 or 7.0.1)?

Can you more precisely describe what you do on the Logs page when the error shows up ? Is the msg actually displayed inside the Details modal window as can be seen in the screenshot ?

Does it show up when simply accessing the Logs page ?

For debugging purposes please add the line below to the wp-config.php file (if not already):

define('ITSEC_DEBUG', true);

This will add a Debug menu option to the plugin Security menu.

• This reply was modified 3 years, 8 months ago by nlpro.
• This reply was modified 3 years, 8 months ago by nlpro.
• This reply was modified 3 years, 8 months ago by nlpro.

I don’t know for sure, but it seems like the “Post Status Changed” entries are actually 404 errors. Now that I’m looking at the site, I see a bunch of entries that are associated with my user name. When I look at the details, it shows:
https://www.tecadatasafe.com/wp-admin/admin.php?page=itsec-dashboard

I tried a page that doesn’t exist to get a 404 and that showed up too.

I am using version 7.0.1

The last_sent[digest] message shows up everywhere in the logs. Both in the details as shown in the screenshot, or just in the main window and it persists when I click on the various logs and filters.

I added the debug code to wp-config.php, not sure what to do next.

Thanks.

Ok, good.

I figured out the

xxx is not of type yyy.

message originates from the WordPress core REST API validation function(s).

The value of the notification center last_sent[digest] setting is supposed to be an integer Unix timestamp. The error may indicate it’s not.

This is where the extra Debug menu option comes in handy. Navigate to the Security/Debug page. Under the Settings section select “notification-center” and then click on the Load button.
This will show us what value is currently stored in the last_sent[digest] entry (if any). It should be a 10 digits integer number.

Oh almost forgot, do you ever get a Daily Security Digest email ?

• This reply was modified 3 years, 8 months ago by nlpro.
• This reply was modified 3 years, 8 months ago by nlpro.

This is what it says:
“last_sent”: {
“digest”: null,
“inactive-users”: 1624431828
},

I do not have the Security Digest enabled, so no – I don’t receive the notifications.

Ok, great.

Since I’m pretty sure the error is related to the setting that stores the timestamp of the last sent Daily Security Digest email, the safest attempt to reset the value is probably by temporarily enabling the Security Digest notification. All we need to do then is wait for a Daily Security Digest email to be sent.

We could update the last_sent[digest] value manually from the Debug page, but if we don’t have to I prefer not to do that.

Once a Daily Security Digest email is sent we can disable the Security Digest notification.

And hopefully that will clear the validation error message from the Logs page (fingers crossed) ??

Okay, I’ve enabled it and we’ll see if it works. When I did that though, it now has the message on all the notification setting pages! Hopefully it will go away once it’s sent.

I’ve now got more than one site with this error.
last_sent[digest] is not of type integer.

I’ve turned on the daily digest and it’s not being sent.

Ok, that makes me think it’s a structural error. Though I haven’t seen this being reported by anyone else on this forum (so far).

Anyway the Daily Security Digest email will only be sent if there is anything to report (there is no point in sending an email that has nothing to report).

There are 3 security events that will trigger the digest email to be send.

First one is when the File Change (FC) feature detects file changes during a scan. So make sure FC is enabled.

Second one is (temporary) lockouts. For this you need the Local Brute Force feature to be enabled.

(The third is (Pro only) Privilege Escalation, but for now let’s disregard this option).

From experience I know that it is usually the File Change (FC) feature that triggers the Daily Security Digest email. So I prefer this above the other 2 security events.

You could force a (temporary) lockout by performing 5 (default) invalid login attempts but I prefer not to do that if we don’t have to ??

Any questions please let me know.

• This reply was modified 3 years, 8 months ago by nlpro.
• This reply was modified 3 years, 8 months ago by nlpro.
• This reply was modified 3 years, 8 months ago by nlpro.

Both I’m looking at now have FCD enabled. One doesn’t show any file changes in the log and the other does. Both have the same folder and file type exclusions as well.

wp-content/uploads/bb-plugin/
wp-content/uploads/bb-ultimate-addon/
wp-content/uploads/bbpowerpack/
wp-content/plugins/
wp-content/uploads/backupbuddy_temp/
wp-content/uploads/backupbuddy_backups/
wp-content/uploads/pb_backupbuddy/
wp-content/cache/
wp-content/uploads/bb-plugin/cache/
wp-content/uploads/siteground-optimizer-assets/

One that I see is the bb-plugin cache reporting file changes even though I have it excluded. I notice this in other sites as well that I do get digests for. Even though I have these exclusions, I get the file change notifications. And it’s not just for this folder, this is the one I happened to notice as an example for this error.

It’s annoying, but that’s a topic for another day ??

Yep, that’s definately another topic (which I’ve seen before) ??

To help things a little more you could make a simple change to the wp-config.php file. Simply make the line that we added earlier a comment like this:

//define('ITSEC_DEBUG', true);

Just add 2 forward slashes at the start of the line.

The File Change feature should pick up this file change next time a file change scan runs.
And consequently the Daily Security Digest email should be triggered to be send.

Something I forgot to mention about the file change excludes list you shared.

Excluding “wp-content/uploads/bb-plugin/“ should automatically exclude any files and subfolders (like “wp-content/uploads/bb-plugin/cache/“). So there is no point in also excluding specific subfolders.

Having said that I do understand why the subfolder “wp-content/uploads/bb-plugin/cache/“ was added since you indicated file changes are still being reported from the cache subfolder.

What server platform is the site running on ? (Linux or Windows)

If not sure, simply navigate to the Site Health page and click on the Info tab.
Look for the the Server architecture value in the Server section.