better-icons CVE-2026-15527

Exploitation requires local system access with at least low OS-level privileges (consistent with CVSS PR:L). The attacker must be able to invoke the scan_project_icons or sync_icon component directly and supply a crafted icons_file argument - this is the specific exploitable surface. The vulnerability is not remotely triggerable in default configurations; an attacker must already have a shell or equivalent code execution context on the affected host. Exploitation is limited to files accessible to the OS user running the better-icons process. No special feature flag or non-default configuration is required beyond the presence of better-icons version 1.0.5 or earlier.

The CVSS 4.0 base vector (AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N) scores 1.9, placing this in the lowest severity tier. All three signals - attack vector (local), privilege requirement (low), and impact (low across C/I/A) - constrain real-world risk substantially. No subsequent-system impact is assessed. A publicly available proof-of-concept (E:P, noted in the CVSS 4.0 threat metric) raises the exploitability signal modestly, but the local access prerequisite means remote threat actors cannot reach this without a prior foothold. No CISA KEV listing exists, indicating no confirmed active exploitation campaigns. EPSS data was not provided in the source intelligence. The combination of local-only access, low impact ceiling, and a niche deployment footprint makes this a low operational priority for most organizations, though development environments running better-icons pipelines with shared or untrusted local access should patch when a fix becomes available.

A local attacker with low-level account access on a developer workstation or CI/CD runner where better-icons is installed invokes the sync_icon or scan_project_icons functionality, supplying an icons_file argument containing traversal sequences such as '../../../../etc/passwd' or a path pointing to sensitive configuration files. Because the argument is not sanitized, the process reads or overwrites the targeted file within the bounds of its own OS-level permissions. A public proof-of-concept exists in GitHub issue #18, lowering the bar for exploitation.