CVE-2023-48335

Executive Summary

CVE-2023-48335 is a vulnerability in the WordPress plugin "Hide login page" by Webcraftic, affecting versions up to and including 1.1.9. The plugin is designed to obscure the default WordPress login URL (e.g., /wp-login.php) by allowing administrators to set a custom slug. However, due to improper access control list (ACL) enforcement, an unauthenticated attacker can bypass this obfuscation and directly access the login functionality. This exposure of sensitive information (the login page location) to unauthorized actors constitutes an information disclosure vulnerability.

The CVSS score is 3.7 (Low), reflecting the limited direct impact—no credentials or data are directly compromised. However, in the context of a layered defense, this vulnerability reduces the security posture by removing a basic obscurity layer, making brute-force or credential-stuffing attacks easier to target. The EPSS score is 0.0%, indicating very low exploitation likelihood in the wild, but the lack of a vendor patch means all installations remain vulnerable.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository. The plugin is not an NPM, PyPI, Go, or Ruby package. The supply chain risk is moderate: the plugin is widely used for basic security hardening, and the unpatched state means users must rely on manual workarounds or alternative plugins.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – exploitable remotely.
• Attack Complexity (AC): Low (L) – no special conditions required.
• Privileges Required (PR): None (N) – no authentication needed.
• User Interaction (UI): None (N) – no user action required.
• Scope (S): Unchanged (U) – the vulnerable component is the only affected asset.
• Confidentiality (C): Low (L) – only the login page URL is exposed.
• Integrity (I): None (N) – no data modification.
• Availability (A): None (N) – no denial of service.

Threat Level: Low. The vulnerability is a low-severity information disclosure. However, it can be chained with other attacks (e.g., brute-force) to increase overall risk.

Deep Dive & Mechanics

The "Hide login page" plugin works by intercepting requests to the default WordPress login URL and redirecting them to a 404 or custom page. It then registers a custom slug (e.g., /mysecretlogin) that triggers the actual login form. The vulnerability arises because the plugin does not properly enforce ACLs on the underlying login functionality. Specifically, the plugin fails to block direct access to the WordPress core login scripts (wp-login.php, wp-admin/) when accessed via alternative methods (e.g., direct IP, HTTP headers, or query parameters).

An attacker can bypass the custom slug by:

1. Directly requesting /wp-login.php (if not blocked by other means).
2. Using HTTP headers like X-Forwarded-Host or Host to trick the plugin into revealing the login form.
3. Accessing the site via its IP address, bypassing domain-based rules.

The core issue is that the plugin relies on URL rewriting and redirection rather than proper authentication or authorization checks. The WordPress core login mechanism remains fully functional and accessible if the attacker can reach it without going through the plugin's custom slug.

Vulnerable vs. Patched Code

Since no official patch exists, we compare the vulnerable plugin code to a hypothetical secure implementation.

Vulnerable Code (simplified):

// In hide-login-page.php
add_action('init', 'hide_login_page_init');
function hide_login_page_init() {
    $custom_slug = get_option('hide_login_slug', 'login');
    if ($_SERVER['REQUEST_URI'] === '/' . $custom_slug) {
        // Show login form
        include_once(ABSPATH . 'wp-login.php');
        exit;
    }
    // No additional checks for direct wp-login.php access
}

Patched Code (hypothetical):

// In hide-login-page.php
add_action('init', 'hide_login_page_init');
function hide_login_page_init() {
    $custom_slug = get_option('hide_login_slug', 'login');
    // Block direct access to wp-login.php
    if (strpos($_SERVER['REQUEST_URI'], 'wp-login.php') !== false) {
        wp_die('Direct access not allowed.', 403);
    }
    if ($_SERVER['REQUEST_URI'] === '/' . $custom_slug) {
        // Show login form
        include_once(ABSPATH . 'wp-login.php');
        exit;
    }
}

The patched version adds a check to block direct requests to wp-login.php, forcing all login attempts through the custom slug. Without this, the plugin is ineffective.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Install WordPress 6.x on a local server (e.g., XAMPP, Docker).
2. Install "Hide login page" plugin version 1.1.9.
3. Configure the plugin to set a custom login slug (e.g., /hiddenlogin).
4. Verify that accessing /hiddenlogin shows the login form.

Exploitation Steps:

1. Direct Access: Simply navigate to http://target/wp-login.php. If not blocked by other means (e.g., .htaccess), the login page appears.
2. IP Bypass: Use the server's IP address: http://192.168.1.100/wp-login.php.
3. Header Manipulation: Use curl with a modified Host header:

   curl -H "Host: target.com" http://target.com/wp-login.php
   

4. Query Parameter Abuse: Append query parameters to bypass simple checks:

   curl "http://target.com/wp-login.php?test=1"
   

Expected Outcome: The attacker sees the WordPress login form, confirming the vulnerability.

Blue Team

Detection Steps:

1. Monitor Access Logs: Look for requests to /wp-login.php or /wp-admin/ that are not preceded by a request to the custom slug.
2. Check Plugin Configuration: Verify that the custom slug is set and that no other plugins or .htaccess rules are blocking direct access.
3. Test the Vulnerability: Periodically attempt to access /wp-login.php from an external IP to ensure it returns a 403 or 404.
4. Implement Additional Controls: Use a Web Application Firewall (WAF) to block direct access to wp-login.php except from trusted IPs.

Indicators of Compromise (IOCs)

• URL Patterns: Requests to /wp-login.php, /wp-admin/, or /wp-login.php?action=* from unknown IPs.
• HTTP Status Codes: Unexpected 200 OK responses for /wp-login.php when the plugin is active.
• Log Entries: Access logs showing direct hits to wp-login.php without prior custom slug access.
• Plugin Version: Presence of "Hide login page" version 1.1.9 or earlier.

Detection Engineering

YARA Rule

rule Detect_Hide_Login_Page_Vuln {
    meta:
        description = "Detects vulnerable Hide login page plugin files"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2023-48335"
    strings:
        $vuln_func = "add_action('init', 'hide_login_page_init')"
        $no_block = "wp-login.php" nocase
    condition:
        $vuln_func and not $no_block
}

Sigma Rule

title: Direct WordPress Login Access Bypassing Hide Login Plugin
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects direct access to wp-login.php when Hide login page plugin is active
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-stem:
            - '/wp-login.php'
            - '/wp-admin/'
    condition: selection
falsepositives:
    - Legitimate admin access from whitelisted IPs
level: low
tags:
    - attack.t1190
    - cve.2023.48335

Suricata Rule

alert http any any -> any any (msg:"CVE-2023-48335 Direct WordPress Login Access"; flow:to_server; http.uri; content:"/wp-login.php"; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the Plugin: Remove or deactivate "Hide login page" until a patch is available.
2. Use Alternative Plugins: Replace with a maintained plugin like "WPS Hide Login" or "iThemes Security" that properly blocks direct access.
3. Server-Level Blocking: Add the following to .htaccess (Apache) or equivalent:

   <Files wp-login.php>
       Order Deny,Allow
       Deny from all
       Allow from 127.0.0.1
   </Files>
   

4. WAF Rules: Create a WAF rule to block requests to /wp-login.php except from known admin IPs.

Long-Term Fixes:

• Monitor the plugin's repository for an official patch.
• Implement a Content Security Policy (CSP) to restrict form actions.
• Use multi-factor authentication (MFA) to reduce the impact of login page exposure.

Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.