Title: Vulnerability: Missing Authorization to Authenticated…
Last modified: June 28, 2025

---

# Vulnerability: Missing Authorization to Authenticated…

 *  [slabbi](https://wordpress.org/support/users/slabbi/)
 * (@slabbi)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/)
 * Wordfence reported a vulnerability in this plugin:
 * [https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/vgw-metis/vg-wort-metis-200-missing-authorization-to-authenticated-subscriber-limited-settings-update](https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/vgw-metis/vg-wort-metis-200-missing-authorization-to-authenticated-subscriber-limited-settings-update)
 * When I am right, the patch is pretty simple:
 * In /classes/admin.php line 422+:
 * Change:
 * $public_identification_id = $pixel->public_identification_id;
 * $private_identification_id = $pixel->private_identification_id; // assuming it’s
   available
 * to
 * $public_identification_id = sanitize_text_field($pixel->public_identification_id);
 * $private_identification_id = sanitize_text_field($pixel->private_identification_id);//
   assuming it’s available
 * Can anybody confirm this as a valid solution?

Viewing 10 replies - 1 through 10 (of 10 total)

 *  [alduinwf](https://wordpress.org/support/users/alduinwf/)
 * (@alduinwf)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18532437)
 * 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:
 *     ```wp-block-code
       $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:
 *     ```wp-block-code
                    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.
 *  Thread Starter [slabbi](https://wordpress.org/support/users/slabbi/)
 * (@slabbi)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18532496)
 *     ```wp-block-code
       $post_id = (int) $_POST['post_id'];
       ```
   
 * the value is always cast to an integer. When the value of post_id cannot be converted
   to an integer it is “0”, so I doubt that this is a problem here. Same for the
   second value. The only unchecked values are the identification IDs.
 *  [alduinwf](https://wordpress.org/support/users/alduinwf/)
 * (@alduinwf)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18532514)
 * 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 idL 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. 🙂
 *  Thread Starter [slabbi](https://wordpress.org/support/users/slabbi/)
 * (@slabbi)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18532571)
 * Yes, sounds reasonable. Thanks for the detailed analysis.
 *  Thread Starter [slabbi](https://wordpress.org/support/users/slabbi/)
 * (@slabbi)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18534953)
 * The vulnerability is now two days old, and there’s still no response from VG 
   WORT.
 * @”VG WORT”: If you can’t – or don’t want to – fix the bug, then put the source
   code on Github and give interested users access to it for further development.
    -  This reply was modified 11 months, 2 weeks ago by [slabbi](https://wordpress.org/support/users/slabbi/).
 *  Plugin Author [vgwort](https://wordpress.org/support/users/vgwort/)
 * (@vgwort)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18535440)
 * Hello,
 * The VG WORT METIS plugin has been temporarily removed from the WordPress.org 
   plugin directory due to a reported security vulnerability. Existing installations
   are not affected — the plugin continues to function as usual. Only new installations
   via the plugin search are currently not possible. Installation via a previously
   downloaded ZIP file remains possible.
 * Our developers are already working on addressing the reported issue. The vulnerability
   mentioned in this thread is known and will be resolved as part of the upcoming
   update. In addition, technical updates are being implemented to ensure official
   compatibility with WordPress 6.8.
 * Please also note that today is the submission deadline for the regular METIS 
   distribution, which means our overall workload is currently very high. 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.
 * Your VG WORT Team
 *  [alduinwf](https://wordpress.org/support/users/alduinwf/)
 * (@alduinwf)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18535490)
 * 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.
 * 🙂
 *  Plugin Author [vgwort](https://wordpress.org/support/users/vgwort/)
 * (@vgwort)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18535515)
 * Thanks for the feedback and the suggestion regarding GitHub.
 * We understand the point and can see the potential benefits of opening up parts
   of the plugin to the community — especially when it comes to faster fixes or 
   improvements. At the same time, certain areas, like the API connection and VG
   WORT-specific processes, require more internal control.
 * We’ve passed the idea on to the developers for consideration. For now, we’re 
   focusing on resolving the current issue and preparing the next release.
 * Your VG WORT Team
 *  [alduinwf](https://wordpress.org/support/users/alduinwf/)
 * (@alduinwf)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18535522)
 * > 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! 🙂
 *  Thread Starter [slabbi](https://wordpress.org/support/users/slabbi/)
 * (@slabbi)
 * [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18536632)
 * It would definitely be a nice move by VG WORT. While I don’t think many users
   will actively participate, the proposed approach would be much faster and less
   stressful for VG WORT when it comes to bug fixes and vulnerabilities, as in this
   case.
    -  This reply was modified 11 months, 2 weeks ago by [slabbi](https://wordpress.org/support/users/slabbi/).

Viewing 10 replies - 1 through 10 (of 10 total)

The topic ‘Vulnerability: Missing Authorization to Authenticated…’ is closed to 
new replies.

 * ![](https://ps.w.org/vgw-metis/assets/icon-128x128.png?rev=2913689)
 * [VG WORT METIS](https://wordpress.org/plugins/vgw-metis/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/vgw-metis/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/vgw-metis/)
 * [Active Topics](https://wordpress.org/support/plugin/vgw-metis/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/vgw-metis/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/vgw-metis/reviews/)

 * 13 replies
 * 3 participants
 * Last reply from: [slabbi](https://wordpress.org/support/users/slabbi/)
 * Last activity: [11 months, 2 weeks ago](https://wordpress.org/support/topic/vulnerability-missing-authorization-to-authenticated/#post-18536632)
 * Status: not resolved