Loading story…
A vulnerability in OpenWrt's luci-app-banip can let an unauthenticated remote attacker evade blocking by manipulating how the application extracts IP addresses from log entries. According to VulnCheck, the flaw is in an awk-based parser that selects the first IPv4 address found in a log line without verifying that the address appears in the correct field, allowing an attacker to place a different IP address in a controllable value such as a username and cause banIP to block the wrong host.
A related OpenWrt LuCI commit updated luci-app-banip help text for the ban_logterm option to clarify that log parsing uses the last IP address on each line by default and that users can prefix a term with first: for source-first log formats such as nginx. The change indicates maintainers adjusted guidance around IP extraction behavior, highlighting the risk that incorrect log-field selection can leave the real attacker unblocked while disrupting legitimate systems through misdirected bans.
See affected versions and whether adversaries are exploiting it.
2 events from the most recent confirmed update back to the earliest known activity.
VulnCheck published an advisory describing a log parsing flaw in luci-app-banip in which an awk-based parser extracts the first IPv4 address from a log line without validating its position. The issue could let an unauthenticated remote attacker inject an arbitrary IP address into a controllable field, causing banIP to block the wrong target while the real attacker remains unblocked.
A code change in the OpenWrt LuCI repository updated luci-app-banip to version 1.8.10-1 and revised the ban_logterm help text to clarify that parsing uses the last IP address per log line by default, with a 'first:' prefix available for source-first formats such as nginx.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
OpenWrt disclosed a high-severity command injection vulnerability in `luci-proto-openvpn` through version `0.11.1` that allows an authenticated LuCI user to execute arbitrary commands as root. The flaw affects the `generateKey` `ubus` method in the LuCI OpenVPN `rpcd` backend, where the caller-controlled `cl_meta` parameter is inserted into a shell command without proper quoting or escaping. Because `rpcd` runs with root privileges, an attacker with access to the OpenVPN protocol configuration can remotely achieve full device compromise, including reading or modifying files, changing firewall and network settings, and installing persistence. Advisory details said the official LuCI front end was only accidentally safe because it base64-encoded `cl_meta`, while the backend still accepted raw values through direct `ubus` or LuCI RPC calls without server-side validation. A proof of concept reportedly executed `id` as root and created `/tmp/INJECTED_PROOF` on an OpenWrt `23.05.5` root filesystem. OpenWrt fixed the issue in commit `e4ff45e`, which wraps `cl_meta` with `shellquote()`, and users were urged to update `luci-proto-openvpn`, apply the patch, restrict configuration access, and monitor for suspicious command execution.
Jun 30, 2026
OpenWrt released **v25.12.5** with urgent fixes for multiple security issues in default-enabled network services, including **CVE-2026-62948**, a flaw that lets an unauthenticated DHCPv6 client inject forged lines into `/tmp/odhcpd.leases` through the FQDN hostname option. Those injected entries can later be rendered as live HTML in the **LuCI** “Active DHCPv6 Leases” page, creating a stored cross-site scripting path against administrators who view the interface. The vulnerability affects OpenWrt versions prior to **25.12.5** and carries a high-impact `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` rating. The service release also patches additional vulnerabilities across **odhcpd**, **uhttpd**, **LuCI**, **cgi-io**, and **ead**, alongside updates to the Linux kernel, **OpenSSL**, **musl libc**, and **dropbear**. OpenWrt said several of the corrected issues could enable remote code execution, request smuggling, stored XSS, privilege escalation, arbitrary file read, memory corruption, or denial of service, and strongly urged users to upgrade. Advisory metadata for **CVE-2026-62948** indicates proof-of-concept exploitation exists, although exploitation is not considered automatable.
Jul 15, 2026
A high-severity vulnerability tracked as **`CVE-2026-69096`** allows authenticated attackers to achieve remote code execution as root in OpenWrt deployments using **LuCI master** or **OpenWrt 25.12 snapshots** that include the `ucode` `docker_rpc.uc` backend for `luci-app-dockerman`. The issue combines overly broad read ACL permissions with unsafe command construction in the `docker.container.ttyd_start` path, where attacker-controlled `id`, `cmd`, and `uid` fields are passed to `system()` without proper quoting or argv-style handling, enabling OS command injection via an HTTP `POST` request to `/ubus`. The vulnerable code runs in the `rpcd` root context, meaning a user with only the **`luci-app-dockerman` read ACL** can execute arbitrary shell commands with full privileges by injecting shell metacharacters. The flaw is classified as **`CWE-78`** and carries a **CVSS v3.1** score vector of **`AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`**. Advisories state that **OpenWrt 24.10** and **23.05** are not affected because they do not include the vulnerable backend, and no patched version was available at the time of disclosure.
Aug 4, 2026