Suricata

Reported by APEvul:

Per RFC 2131, when Option 52 is present, the BOOTP `sname` (64 bytes) and/or `file` (128 bytes) fields may contain additional DHCP options and should be treated as continuation areas for option parsing. In my testing, a client that correctly honors Option Overload accepted and applied attacker-controlled DHCP configuration carried in the overloaded `sname` field, while the standard DHCP options area remained benign-looking.

The issue I am reporting is that, if Suricata does not parse overloaded `sname` / `file` fields into the same DHCP application-layer path used for detection and logging, this may create a visibility gap for security-relevant DHCP configuration such as DNS servers, routers, or domain names.

This is not a claim that Option 52 itself is invalid protocol behavior. Rather, it is a request to improve Suricata’s DHCP parser, detection exposure, and EVE logging coverage so that they better match RFC 2131 semantics for overloaded option storage. Suricata’s currently documented DHCP rule keywords are limited, and its EVE DHCP logging is separately documented, which is why I am describing this as a parser / detection / logging coverage issue rather than a protocol bug. :contentReference[oaicite:0]{index=0}