🐛 `parseIpv4Hex` matches any two characters, not hex digit pairs

[mashajh]

sandbox/src/monitor/enhancedNetworkMonitor.ts:133 parses IPv4 addresses out of /proc/net/tcp-style hex with this regex:

function parseIpv4Hex(hex: string): string {
  const octets = hex.match(/../g);  // matches *any* two characters
  if (!octets || octets.length !== 4) return "0.0.0.0";
  return octets.reverse().map((octet) => Number.parseInt(octet, 16)).join(".");
}

/../g is a "match any two characters" pattern, not "match two hex digits". If hex ever contains a non-hex character (e.g., a stray space or control byte from a malformed procfs line), parseInt(octet, 16) returns NaN and the function emits "NaN.NaN.NaN.NaN" — which silently flows through enhancedNetworkMonitor as an "address" and gets logged into the audit evidence.

Steps to Reproduce

parseIpv4Hex("0100007F"); // → "127.0.0.1"   ✅
parseIpv4Hex("0100Z07F"); // → "127.0.NaN.1" ❌ should reject
parseIpv4Hex("AB CD");    // matches "AB", " C", "D"... garbage

Expected vs Actual

	Expected	Actual
Bad input	Reject (return "0.0.0.0" or throw)	NaN.NaN.NaN.NaN flows through downstream

Fix

const octets = hex.match(/[0-9a-fA-F]{2}/g);
if (!octets || octets.length !== 4 || octets.join("").length !== hex.length) {
  return "0.0.0.0";
}

Environment

• Node.js, sandbox monitor reading /proc/<pid>/net/tcp
• Severity: Medium (data quality bug; not exploitable on its own, but pollutes audit evidence)