nerdlogger

Same here……WSD’s started right after update. Hoping for fix soon. Thanks.

Hi Robert,

I’ve gone through all my installations…..here are the things I’ve observed to be a pattern:

• It happens on both network and single sites
• all sites are running on a single server in containers
• all updates were from 2.5 to 2.6
• the reset values were on “2fa Policies” page only…..NOT the settings (I remove the ability for other admins to change settings in this panel)
• On 2 sites I did the update by hand from the plugins menu and it seemed like the old version was never there. After the update I clicked the link to go to the updates page and was redirected to the 2FA wizard. I skipped it and setup the proper values by hand on the “2fa Policies” page.
• (almost certain) that the “2fa Policies” were reset IF “Hide the Remove 2FA button on user profile pages” was NOT checked. (almost certain) that on sites were this option was checked the settings did not reset.
• WP version (all) 6.3.2
• PHP version (all) 8.1.26

Hope this helps……

Let me know if you like me to dig more info……

TTYL

Many Ayromlou

Hi @robert681,

Thank you for the quick response. After extensive testing over the weekend, it looks like WP 2FA is in the clear. The “real” culprit was “all-in-one-seo-pack” plugin that was present on both networks. Once it was removed the WP 2FA plugin can be enabled at network level without any issues (crossing my fingers).

I’ve confirmed that with both plugs active at network level, all visits to wp-admin/wp-login.php and the front ends of any subsite will produce a error. If “wp 2fa” plugin is disabled, the interactive sessions (above) will start to work, but any “core” (in my case user password reset) operation via wp-cli command (from bash) will produce an errors from “all-in-one-seo-pack”. This was very useful and helped solve the problem.

Once I reversed the situation (wp2fa: Network ON, all-in-one-seo-pack: REMOVED), everything works beautifully.

I guess we need a new SEO plugin now ??

Thanks again for the follow up. Hopefully @joshjcobb is in a similar boat :-).

TTYL

Many

Hi,

I don’t think that’s the case……This just came out today and specifically mentions version <= 4.6.19. I doubt that wordfence and patchstack are just “hard linking” to the www.remarpro.com version tag.

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/molongui-authorship/molongui-4618-reflected-cross-site-scripting

Thanks,

Hi, I don’t believe the XSS issue has been resolved yet. Atleast not according to patchstack:

https://patchstack.com/database/vulnerability/molongui-authorship/wordpress-molongui-plugin-4-6-18-cross-site-scripting-xss-vulnerability

Hi,

Thanks for the response….but I think you should fix this asap as you’re creating garbage entries in the DB……you’re literally seeking past the end of the array and grabbing the string terminator character…….Following code illustrates:

<?php
// PHP code goes here
$characters = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ';
   print("Printing character @ strlen($characters) location\n");
   echo "\n";
   echo $characters[strlen($characters)];
   echo "\n";
   print("Printing character @ (strlen($characters) - 1) location\n");
   echo "\n";
   echo $characters[(strlen($characters) - 1)];
   echo "\n";
?>

Run this from command line and see……your version of the code (without subtracting 1) goes off the end of the characters array.

Please see the comments on this page as well (same issues are discussed).

https://php.net/manual/en/function.rand.php

Please fix this soon…..this could cause major issues later on.

Thanks,
Many Ayromlou

Same here…..WSOD. Moved the plugin out, reload, move it back in. As long as it’s disabled hopefully a update will fix it. I can’t even grep for a class named “Tribe__PUE__Package_Handler” in the entire source tree……

Hate to bump, but I did not hear any news/confirmation on this…..anyone?

TTYL
Many

1.0.7 update breaks the admin area….I’ve downgraded back to 1.0.6 until the issue is resolved.

Thanks TL3000……found your post after discovering that the plugin was the culprit…….

I’ve noticed that this also breaks the media library function (the default large thumbnail view……not the detailed list view).

Additional info for the author……This error pops up when you add images to a post……the actual file is uploaded and is there on the server, but the “thumbnail” and file details on the right panel don’t show up……This happens with ALL themes (even twenty somethings that come with WP4.0)……

Can this be fixed please…….4.0 has been out for a while…..This also happened in 3.9.2 — that’s when I noticed the issue, upgraded to 4.0 and still had the issue……disabled the plugin and everything is fixed now.

Thanks,

Hi All,

I had the same problem with user Riccardo. I think I’ve solved it. It’s actually a mistake in the code (i.e.: not malicious).

The togetherjs-min.js code has a definition for “TogetherJSConfig_findRoom”. If you edit the file togetherjs.php (part of the plugin zip file) you see the author uses
$site_id = get_current_blog_id();
to assign the current blog_id (which btw is pre-3.8 call) to variable site_id (Line 433 in code). If you look further down (starting on line 475) he injects the necessary javascript into the header of the page and on line 481 uses
var TogetherJSConfig_findRoom = "site_' . $site_id . '";
to assign the participant to a room.

The problem is that site_id is usually 1, so TogetherJSConfig_findRoom variable gets assigned the string “site_1” which basically lands everyone who uses (installs and activates) the plugin in the same room.

Riccardo is just some guy who’s installed the plugin, activated it and left it in collaborate mode.

I changed the above code from
var TogetherJSConfig_findRoom = "site_' . $site_id . '";
to
var TogetherJSConfig_findRoom = "demosite_' . $site_id . '";
and I can confirm that Riccardo is not there.

I would suggest that the plugin author give us the facility to choose the prefix we want to use instead of hardcoding it in the code (since $site_id will always resolve to 1) or use the hostname of the installation instead of the string “site_” in the above initialization.

Hope this helps……

TTYL
Many