U-Boot parser, TP-Link MR600 V5, and router hygiene

On 1 July, Binarly disclosed six memory-safety flaws in Das U-Boot, tracked as BRLY-2026-037 to BRLY-2026-042. U-Boot is widely used across embedded, network and industrial products. The affected code parses FIT (Flattened Image Tree) data while determining which regions should be covered by signature verification.

A malicious FIT must first reach a device's boot or update path, whether through physical access, removable media or a product-specific remote update mechanism. The findings do not imply that every U-Boot device is remotely exploitable.

Root cause — an unchecked parser result

In BRLY-2026-038, fdt_get_name() can fail and return a null name with a negative length. The vulnerable code continues to use both values. The negative length can move a write pointer before its stack buffer; a later node name can then be written below that buffer.

  name = fdt_get_name(fdt, offset, &len);      # can return NULL, len < 0
+ if (!name)                                    # absent in v2026.07
+     return len;
  if (!depth && *name)                          # v2026.07: dereferences NULL
      return -FDT_ERR_BADLAYOUT;
  if (end - path + 2 + len >= path_len)         # negative len skews the bounds check
  strcpy(end, name); end += len;                # -> out-of-bounds write

What our lab confirmed

The frozen lab record includes a stored run of the real parser at two points — the released v2026.07 and the fixed tree — under AddressSanitizer. The same crafted image behaves differently on each build.

# v2026.07 — VULNERABLE
==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000  # READ, zero page
    #0 fdt_find_regions   boot/fdt_region.c:91
    SUMMARY: SEGV in fdt_find_regions            # -> ABORTING

# master — FIXED (identical input)
fdt_find_regions => -11                          # clean, exit 0

A bounded control-flow demonstration

To test what the recorded write could affect, we built a synthetic verifier-shaped harness with a function pointer deliberately placed immediately before the vulnerable buffer. It was compiled without PIE or stack protection and mapped page zero. A malformed FIT changed the pointer's low bytes and redirected the harness call; the fixed parser rejected the same input.

# v2026.07:
verify -> synthetic test callback   ●  call redirected
# master (identical input):
verify -> benign callback          ●  clean   fdt_find_regions => -11

Why this matters for Australia

Australia's consumer smart-device standard commenced on 4 March 2026 for covered products manufactured from that date; it is not retrospective across the existing fleet. The July SOCI material concerning distributed energy resources is consultation material and is not yet law. Enhanced CIRMP requirements apply to specified critical-infrastructure assets and include staged transition periods.

TP-Link's public advisory describes command injection in the Archer MR600 V5 WireGuard client configuration. It requires an authenticated administrative user applying a configuration through the web-management interface. TP-Link names EU_V5_1.7.0 and JP_V5_1.2.0 as fixed builds.

Where configuration data becomes shell syntax

The supplied Neonix write-up compares the vulnerable EU_V5_1.5 build with the fixed EU_V5_1.7.0 build and locates the change in libcmm.so. It reports that oal_wgvpn_genInterfaceConfClient() and oal_wgvpn_genPeerConfClient() generate the WireGuard [Interface] and [Peer] blocks one field at a time. In the vulnerable build, those fields are interpolated into formatted echo commands and passed to util_execSystem().

That helper first materialises the command with vsnprintf() in a 512-byte buffer. It rejects the string only if it contains a semicolon; otherwise it calls system() as root. The flaw is deeper than one omitted character: configuration data crosses an interpreter boundary and is parsed again as shell syntax, where other operators and command-substitution forms still have meaning. An authenticated administrator who can submit a crafted WireGuard configuration can therefore cross from the management plane into commands running with the router process's privileges.

# vulnerable V5  field -> formatted echo command -> semicolon-only filter -> system()
# fixed V5       field -> fputs() / fprintf() -> direct file write       -> no shell

The joint advisory AA26-194A was issued on 13 July by 19 agencies across 13 countries; ASD published its Australian page on 14 July. It describes a campaign attributed to Russia's FSB Center 16, also tracked under names including Berserk Bear, Energetic Bear, Ghost Blizzard and Static Tundra. The campaign spans more than a decade and targets poorly secured network infrastructure.

1. SCAN  internet SNMP agents answering to a default / weak community string
2. SET   SNMP Set-Request abusing Cisco CISCO-CONFIG-COPY-MIB
3. EXFIL running-config copied out over TFTP to attacker infrastructure

# occasionally paired with:
CVE-2018-0171  # Cisco Smart Install (TCP 4786)
CVE-2008-4128  # added to CISA KEV on 13 July

How an SNMP credential becomes a configuration export

In SNMPv1 and v2c, the community string is effectively a shared bearer credential. A read-only string permits queries; a read-write string also permits state-changing Set requests. With that access, the actor does not need an interactive CLI login. The CISCO-CONFIG-COPY-MIB exposes a job table whose fields select the running configuration as the source, a network file as the destination, TFTP as the transfer protocol, and an external server and filename. Activating the row makes the router initiate the transfer.

The sensitive subtree begins at 1.3.6.1.4.1.9.9.96.1.1; the joint advisory specifically highlights the server-address object at 1.3.6.1.4.1.9.9.96.1.1.1.1.5. This is why a conventional vulnerability scan can miss the condition: the decisive weakness may be a live management protocol plus an over-privileged community string, not a missing patch. Credentialed configuration review or controlled SNMP testing is needed to distinguish read-only exposure from read-write control.

The named sectors — communications, energy, financial services, government (especially state and local), healthcare — overlap with several Australian critical-infrastructure sectors. The advisory names at-risk sectors, not confirmed Australian victims.

Drawn from vendor advisories, CISA and named reporting — not our own lab this month.

Black Hat USA postscript — two talks to follow

Black Hat USA Briefings ran on 5–6 August, after July closed. These are attributed conference results, not Neonix laboratory work.

Each item is written so it can be assigned to the accountable owner. Regulatory mappings should be applied only where the organisation, asset and transition date are in scope.

1. 01 Run the router-hygiene sweep (AA26-194A) Disable Cisco Smart Install; move to SNMPv3; block TFTP/SMI/SNMP at the edge; replace end-of-life gear. Owner: Network · ASD E8 — Patch OS / Restrict Admin
2. 02 Confirm the June U-Boot FIT fixes are backported Ask affected product vendors; do not assume a future upstream release will reach deployed products. Owner: Product / OT
3. 03 Add firmware & bootloader integrity to procurement Require firmware provenance, rollback protection and a defined support lifetime. Owner: Procurement / Product
4. 04 Audit OT and router management services Remove weak credentials and unnecessary exposure. For Archer MR600 V5, apply TP-Link's region-specific fixed firmware or later. Owner: OT / Network
5. 05 Apply smart-device rules only where they are in scope Check the product scope and manufacture date before treating the standard as applicable. Owner: Product / Legal
6. 06 Map applicable enhanced CIRMP requirements Confirm the applicable critical-asset class, requirement and staged transition date. Owner: Risk / GRC
7. 07 Track the distributed-energy SOCI proposal Treat the July material as consultation, not an existing fleet-wide obligation. Owner: Legal / GRC