Thanks for fixing that bug. However, replacing NUL with \0 sounds iffy.
Even if we assume that a web page contains C-like code, the replacement
would mishandle a NUL followed by an octal digit, since the replacement
would look like \07 which would be interpreted as a BEL character, not
as a NULL followed by a digit 7. And web pages do not typically contain
C code, so the replacement \0 might cause other trouble.

Instead, it sounds better to replace NUL with the four-character
sequence "�", as this is a standard HTML way to represent a NUL
character. I installed the attached patch to do this.

In my little tests with this patch, libxml2 typically handled � by
discarding it and continuing to parse, which is better than ignoring the
rest of the input. In some cases libxml2 handles � by discarding
later input up to a delimiter; although this is bad, it's a libxml2 bug
that attackers can exploit independently of what Emacs does with NUL,
since attackers can simply use �.