Caps Lock False Positive

Greeting, @weblizar,

I am using Admin Custom Login 3.6.2, and since updating from 3.6.1 two weeks ago, whenever I log in, the window reports Caps Lock is engaged when it is not. This same issue occurs on any website running 3.6.2. I see from the changelog that the plugin is tested and working clean with WordPress 6.9; however, that is not accurate.

I’ve identified the root cause: When your plugin replaces the password field on line 269 of init.php using innerHTML, it corrupts WordPress 6.9’s changed caps lock detection event handlers. This leaves the detection in a broken state, incorrectly reporting Caps Lock as engaged.

I’ve updated the init.php file to prevent WordPress’s broken caps-lock detection from falsely triggering a display, and to provide accurate detection instead. The fix adds CSS to hide the false warning, uses a MutationObserver to block it from appearing, and implements proper caps lock detection using the getModifierState() API.

While I was at it, I ran a security and code audit and found several critical vulnerabilities in the plugin. The import function had a file upload vulnerability: it used explode() on the first dot instead of pathinfo() on the last dot, allowing files like “malicious.php.json” to bypass validation. There was also an unsafe unserialize() call with error suppression that could enable object-injection attacks, and a syntax error involving an incomplete ternary operator that broke import functionality entirely. Additionally, error_reporting(0) suppressed all PHP errors in four files, potentially hiding potential security issues. I’ve fixed all the security issues and tested extensively.

I will directly send the four corrected files, which resolves the issues completely, to your support email. Please apply these fixes ASAP and update to version 3.6.3 to address these critical security vulnerabilities and the caps lock bug.