mowpmfa

Hello @awfominaya,

Thank you for reaching out and sharing your concerns.

After reviewing your description, we can confirm that there is no known breach or vulnerability in our 2FA plugin. The behavior you mentioned seems more consistent with a case where login credentials may have been compromised externally. In such cases, attackers often attempt brute-force or automated login attempts — however, thanks to our 2FA protection, they are unable to gain access to your site without completing the second authentication step.

Regarding the obfuscation in the premium version of our plugin, please rest assured that this is an intentional and standard security measure. We obfuscate the premium code to prevent copyright infringement and protect our proprietary functionality. Many of our customers, including large enterprises, use the same version safely and without any security issues.

As a precaution, we would recommend resetting your WordPress admin and hosting account passwords immediately, just to eliminate any chance of unauthorized access through compromised credentials.

Also, we’d like to clarify that our team was available at the scheduled meeting time, but it appears that you were unable to join.

Regards,
miniOrange Team

Hello @espressivo,

WordPress Application Passwords are designed for API access and bypass the normal login screen, so they don’t trigger 2FA. Our plugin does not currently enforce 2FA on those requests.

Let us know if you any other questions.

Regards,
miniOrange Team

Hello @joostgrunwald,

You can contact us at [email protected] via email.

Regards,
miniOrange Team

Hi Kristián,

Thank you for bringing this to our attention.

Yes, you’re absolutely right—we intentionally removed the translation functionality (specifically the mo_() implementation) in version 5.3.0. This was done as a temporary measure in response to a change introduced in the latest versions of WordPress. WordPress now enforces that translation functions like __() or pll__() should only be called after the ‘plugins_loaded’ hook has fired.

In previous versions, calling these functions earlier in the load process was common, but now doing so may trigger warnings or cause issues—especially on sites with debug logging enabled. To prevent such problems and avoid cluttering logs on production sites, we’ve temporarily disabled translations by modifying the mo_() function to return the string as-is.

We’re actively working on restructuring our plugin to ensure translations are properly loaded after the ‘plugins_loaded’ hook, and will reintroduce full translation support in an upcoming release.
In the meantime, if you rely on translations and are comfortable with a temporary fix, you can manually restore the old mo_() function in your local copy of the plugin and disable debug logging to avoid warnings. Here’s the previous function you can use:

function mo_( $string ) {
$string = preg_replace( ‘/\s+/S’, ‘ ‘, $string );
return is_scalar( $string )
? ( MoUtility::is_polylang_installed() && defined(‘MOV_USE_POLYLANG’) && MOV_USE_POLYLANG ? pll__( $string ) : __( $string, ‘miniorange-otp-verification’ ) )
: $string;
}

Please note that this is a temporary workaround and we recommend updating to the latest version once translation support is officially reinstated.

Thank you again for your understanding!