AdminLTE PiHole 5.18 - Broken Access Control

AdminLTE PiHole 5.18 – Broken Access Control: A Critical Security Vulnerability Explained

One of the most widely used open-source network-level ad blockers, Pi-hole, has long been praised for its simplicity, effectiveness, and robust privacy-focused design. However, in December 2022, a critical vulnerability was discovered in its web interface—AdminLTE—that undermines fundamental security principles: access control.

This vulnerability, known as CVE-2022-23513, affects Pi-hole versions prior to 5.18, specifically when the web interface is configured with outdated or misconfigured access controls. The flaw allows attackers to perform unauthorized queries against the queryads.php endpoint, exposing sensitive data about blocked domains without proper authentication.

Understanding the Vulnerability: Broken Access Control

Access control is a cornerstone of cybersecurity. It ensures that only authorized users can access specific resources or perform certain actions. When access control is broken, systems fail to enforce restrictions, enabling malicious actors to exploit features intended for administrators or authenticated users.

In the case of Pi-hole, the queryads.php endpoint was designed to allow administrators to search for domains that are currently blocked by the system. However, due to a lack of proper authentication checks, this endpoint became accessible to anyone with network access—even unauthenticated users.

This means that a remote attacker could query the system to discover which domains are being blocked, potentially revealing sensitive information such as:

• Malicious domains used by phishing campaigns
• Tracking domains from third-party analytics services
• Corporate or personal domains being blocked by a user's configuration

Proof of Concept: The Exploit in Action

Here’s a real-world example of how the vulnerability can be exploited using curl:

curl 'http://pi.hole/admin/scripts/pi-hole/php/queryads.php?domain=google.com'

This request sends a simple GET query to the Pi-hole web interface, asking whether google.com is blocked. If the system is vulnerable (i.e., running Pi-hole < 5.18), it responds with a 200 OK status and returns data indicating whether the domain is in the blocklist.

Example response:

data: Match found in /etc/pihole/blacklist.txt
data: google.com
data: www.google.com
data: analytics.google.com

Even though the user is not authenticated, the system reveals the full list of blocked domains associated with the query. This is a direct violation of the principle that sensitive data should only be accessible to authorized personnel.

HTTP Request & Response Analysis

Request	GET /admin/scripts/pi-hole/php/queryads.php?domain=google.com HTTP/1.1 Host: pi.hole Cookie: [..SNIPPED..]
Response	HTTP/1.1 200 OK [..SNIPPED..] data: Match found in [...] data: google.com data: www.google.com

Notice the absence of any authentication header or token. The server responds with the full data set, demonstrating that the endpoint lacks session validation and role-based access control.

Impact and Risk Assessment

The implications of this vulnerability are significant:

• Information Disclosure: Attackers can map out entire blocklists, revealing patterns of user behavior or organizational policies.
• Reconnaissance: Threat actors can use this data to identify weak points in network security or to craft targeted phishing campaigns.
• Privacy Violation: Users who rely on Pi-hole for privacy protection may inadvertently expose their browsing habits.
• Exploitation Chain: This vulnerability can serve as a stepping stone for further attacks, such as identifying internal domains or testing for other misconfigurations.

According to the VulDB and the official GitHub Security Advisory, this vulnerability affects:

• Pi-hole v5.14.2
• FTL v5.19.2
• Web Interface v5.17

It was confirmed to be exploitable on Raspbian and Debian systems—common platforms for Pi-hole deployments.

Root Cause: Missing Authentication Checks

At the core of the issue lies a missing auth_check() function or similar mechanism in the queryads.php script. The code should verify:

• Whether the user is logged in
• Whether the user has administrative privileges
• Whether the request is coming from a trusted IP or session

Instead, the endpoint simply processes the domain parameter and returns results without any validation. This is a classic example of broken access control as defined in the OWASP Top Ten security risks.

Fix and Mitigation: Patching the Vulnerability

As of Pi-hole 5.18, the issue has been resolved. The updated web interface now includes:

• Authentication checks before processing any query
• Session-based access control
• Restriction of sensitive endpoints to authenticated users only

Administrators should:

• Upgrade to Pi-hole version 5.18 or later
• Ensure that the AdminLTE web interface is updated
• Verify that the queryads.php endpoint is no longer accessible without login

For systems still running older versions, consider:

• Using firewall rules to restrict access to the admin interface
• Enabling HTTPS and requiring strong authentication
• Disabling remote access unless absolutely necessary

Expert Insight: Lessons from CVE-2022-23513

Security experts emphasize that even well-designed tools like Pi-hole are not immune to vulnerabilities when access control is overlooked. This incident serves as a reminder:

• Always validate user roles before processing sensitive queries
• Never expose internal data via public endpoints without authentication
• Regularly audit and update software, especially for open-source projects

As the AdminLTE interface is a web-based frontend, it must follow the same security standards as any web application: authentication, authorization, and input validation.

Conclusion: Proactive Defense is Key

While Pi-hole remains a powerful tool for ad-blocking and privacy protection, the CVE-2022-23513 vulnerability highlights the importance of continuous security vigilance. Simply installing a tool does not guarantee security—it must be actively maintained.

By upgrading to the latest version, enforcing access controls, and monitoring system behavior, users can prevent such exploits and maintain the integrity of their network security.