Which versions of luci-app-banip are affected by CVE-2026-62184?

OpenWrt deployments using banIP versions prior to 1.8.10 are vulnerable to control manipulation attacks in which external actors inject spoofed IP addresses to evade the automated blocking engine,…. A patch is available.

How to fix or mitigate CVE-2026-62184?

Within 24 hours, inventory all OpenWrt systems running banIP versions before 1.8.10 and assess internet-facing criticality; simultaneously begin testing luci-app-banip 1.8.10 in a lab environment. Within 7 days, complete compatibility validation and deploy the patched version to non-production systems, confirming operational impact. Within 30 days, roll out luci-app-banip 1.8.10 to all production OpenWrt deployments and verify successful completion through your asset management system.

luci-app-banip CVE-2026-62184

Q: What is the CVSS score of CVE-2026-62184?

CVE-2026-62184 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

HIGH

Improper Encoding or Escaping of Output (CWE-116)

2026-07-13 VulnCheck

Code Injection Openwrt Luci

8.7

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Remotely reachable log input with no auth or interaction (AV:N/AC:L/PR:N/UI:N); impact is denial of the blocking control affecting availability only (A:H), with no confidentiality or integrity effect.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 13, 2026 - 22:02 vuln.today

Analysis Generated

Jul 13, 2026 - 22:02 vuln.today

CVE Published

Jul 13, 2026 - 21:30 cve.org

HIGH 8.7

DescriptionCVE.org

luci-app-banip contains a log parsing vulnerability where the awk-based parser extracts the first IPv4 address from log lines regardless of field position, allowing attackers to inject arbitrary IPs via attacker-controlled fields like usernames. An unauthenticated remote attacker can inject an IP address into the login username field, causing banIP to block the wrong target while the real attacker remains unblocked.

AnalysisAI

Ban-list poisoning in OpenWrt's luci-app-banip (banIP) before 1.8.10 lets an unauthenticated remote attacker steer the automated IP-blocking engine at an arbitrary victim. Because the awk-based log monitor grabs the first IPv4 address it finds on a log line regardless of field position, an attacker can embed a spoofed IP inside an attacker-controlled field such as a login username; banIP then bans that injected address while the real attacker's source IP is never blocked. Reported by VulnCheck with a vendor patch available; no public exploit code or active exploitation is identified at time of analysis.

Technical ContextAI

banIP is an OpenWrt/LuCI application that monitors the system log for suspicious activity and dynamically populates nftables/firewall ban sets to block offending source IPs. Detection relies on user-configurable 'Log Terms' regular expressions plus an awk routine that extracts an IPv4 address from each matching log line. The root cause is CWE-116 (Improper Encoding or Escaping of Output / improper neutralization of log input): the parser selects the first IPv4 token on the line rather than the field that actually represents the connection source, so any log line that echoes attacker-supplied text (e.g. a failed-login username, HTTP header, or other free-form field) can carry a forged address into the ban decision. The affected code path is the log-monitoring logic surfaced in overview.js and the underlying banIP parser; CPE data identifies the OpenWrt luci package (cpe:2.3:a:openwrt:luci) as the affected component.

RemediationAI

Upgrade luci-app-banip to the vendor-released patch version 1.8.10 or later (fix commit d9bbc372e29618a8807b693a1ccf6d0e42cd196c; advisory GHSA-r6hx-4f83-vp8m). The fix changes the parser to use the last IP per line and adds a 'first:' prefix option on Log Terms for source-first log formats such as nginx, so after upgrading review each configured Log Term and add the 'first:' prefix where the genuine source IP appears first on the line to preserve correct blocking. If immediate patching is not possible, tighten the 'Log Terms' regular expressions so they anchor on the specific field that carries the true source IP rather than matching any line containing an IPv4 token, and stop monitoring log sources that echo unvalidated attacker-controlled free-form fields like usernames or HTTP headers - the trade-off is reduced detection coverage and more manual tuning. As a further compensating control, do not rely solely on banIP auto-blocking for high-value hosts, so a poisoned ban entry cannot lock out legitimate administrators or partners.