Vulnerability: Missing Authorization to Authenticated…

I’m not convinced that’s the problem because $pixel‘s contents are generated by Db_Pixels and doesn’t look as if it’s something someone could manipulate.

However, this line that sets the stage which post we’re talking about…is not checked further:

$post_id = (int) $_POST['post_id'];

So my guess would be this is the problem.

However, I’m lacking context here if one could fix this just with assuming the “global” ID we’re talking about or what.

At least we should check a few things. First, if post_id is even set at all (to avoid PHP warnings in the log), and then at least if the current user would be allowed to edit the post_id they are sending.

So replace the line above with:

             if (! isset($_POST['post_id'])) {
                     wp_send_json_error('Post ID is a wild Missingno.', 400);
                     wp_die();
              }

              $post_id = (int) $_POST['post_id'];

              if (! current_user_can('edit_post', $post_id)) {
                     wp_send_json_error('I am sorry Dave, I am afraid I cannot do that.', 403);
                     wp_die();
              }

Additionally, we should also check for some nonce. However, I’m sorry, but I’m not deep enough in this part of the architecture to know if one is already conveniently set, or how we could set one. But this should, if nothing else, prevent a random user from editing information of a post of their choosing.

That is right but according to Wordfence, the problem is not “what” is changed, but “who” can change random stuff. They state “Missing Authorization”, not “Improper Sanitization”.

And what post id to manipulate is grabbed from this line and the function trusts it blindly without further checks if the user is even allowed to edit this post id.

I mean… looking at the function, I am not even sure how much of an impact this issue might have, except the code not playing by permission checking rules, and maybe leaking some data. That might be worse than “updating” post settings for any post. Let’s boil it down.

L 432 reads metas from said post id, the text length.
L 433 gets the count pixels for this post id
L 435 and L 436 sets a local variable to data from L 433 – so far, we have not changed anything.

Changing might happen in L 443 – which updates the status of the article (whether or not it’s suitable for a pixel), and also not with data an attacker could modify. Everything here is either meta or already in the database anyways. So no harm done here either. In fact, an attacker would do the author a service even if the post status has been set wrong for whatever reason. Because it would make the system re-count the letters and set the correct status. It is some sort of maintenance work, if you will.

Well and L 446-450 just sends the JSON response back, with the stuff that it gathered itself. Here might be a leak of data because it also sends the “private_identification_id”. So that might be worse than the “update of the post” part that the CVE is complaining about.

The only thing that comes from the outside, might trigger a save action, and is not checked, is the post id. No content that might be stored in the database or otherwise can come from the outside. So sanitization really doesn’t seem to be the problem here. 🙂

Hello,

The plugin is not commercially operated, so it’s not always possible to respond to forum posts immediately. Nevertheless, we are continuously working to improve and maintain the plugin.

To be completely fair, the more reason to put it somewhere like GitHub and have the community help with the efforts. All you’d have to do is to babysit the API stuff (if you don’t want to document it) and push the release button should other developers be faster in providing fixes or new features and such.

🙂

like the API connection and VG WORT-specific processes, require more internal control

And this is fine since this is only a small part of the plugin, and it does work. Collaborative development doesn’t mean you have to abandon the plugin, you can still maintain the API connection and its inner workings. You don’t _have_ to open the API and document it to its full extent (let alone how the sausage is made on your end).

But there is plenty of plugin left where the community could help, such as the integration to WordPress (such as support for Custom Post Types, or fixes like these).

I’m glad you are considering it tho. Keep up the good work! 🙂