CVE-2025-59151
Pi-Hole Web Interface ≤ 6.3
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:LSummary
CVE-2025-59151 is a high-severity CRLF Injection (CWE-93) vulnerability in Pi-Hole Web Interface. Its CVSS base score is 8.2 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Content Injection (T1659); ranked at the 34th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and SI-15 (Information Output Filtering) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-59151 is a Carriage Return Line Feed (CRLF) injection vulnerability affecting the Pi-hole Admin Interface, the web-based management interface for Pi-hole, a network-level advertisement and tracker blocking application. Versions prior to 6.3 fail to properly sanitize input during redirects triggered by requests to files ending in the .lp extension. This allows attackers to inject CRLF characters (%0d%0a), manipulating both HTTP response headers and content. The issue is associated with CWE-93 (CRLF Injection) and CWE-113 (HTTP Response Splitting), earning a CVSS v3.1 base score of 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L).
The vulnerability can be exploited remotely over the network with low complexity, requiring no privileges or user interaction. An attacker sends a crafted request to a .lp endpoint, injecting CRLF sequences to insert arbitrary HTTP headers into the response. This enables attacks such as session fixation, cache poisoning, and circumvention of browser security features like Content Security Policy (CSP) or X-XSS-Protection, primarily impacting integrity with some availability effects.
The Pi-hole web repository advisory (GHSA-5v79-p56f-x7c4) confirms the vulnerability and states it is fixed in version 6.3 through improved input sanitization during redirects. Security practitioners should upgrade to Pi-hole Admin Interface 6.3 or later to mitigate the issue.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-36364
Vulnerability Data
Pi-hole Admin Interface is a web interface for managing Pi-hole, a network-level advertisement and internet tracker blocking application. Pi-hole Admin Interface before 6.3 is vulnerable to Carriage Return Line Feed (CRLF) injection. When a request is made to a file…
more
ending with the .lp extension, the application performs a redirect without properly sanitizing the input. An attacker can inject carriage return and line feed characters (%0d%0a) to manipulate both the headers and the content of the HTTP response. This enables the injection of arbitrary HTTP response headers, potentially leading to session fixation, cache poisoning, and the weakening or bypassing of browser-based security mechanisms such as Content Security Policy or X-XSS-Protection. This vulnerability is fixed in 6.3.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V3.4.2V4.1.3V1.3.6V4.2.3
Mitigating Controls (NIST 800-53 r5) AI
Input validation directly stops untrusted data containing CRLF sequences from reaching the component that treats CRLF as a delimiter.
Output filtering can neutralize CRLF sequences before they reach HTTP response headers.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and validation to block CRLF injection.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect CRLF flaws but does not itself implement the neutralization.
Secure development lifecycle mandates input validation and output encoding that directly prevents CRLF injection.
Application security requirements include rules for neutralizing special characters such as CRLF in inputs.
Secure architecture principles encourage safe handling of untrusted data but do not prescribe specific CRLF controls.
Secure coding standards explicitly require neutralization of CRLF sequences, fully addressing this weakness.
Logging of HTTP traffic can record header-splitting attempts, aiding detection and forensics.