This is easy to just do, but it is hard to know how far to take it. If the header is OK, but there are no bytes after it, then we'll get EOF from someplace else. If there's one byte indicating we should go into readExtension, but no more, then readExtension needs the code change too.
Anyway, I'm posting a CL that fixes the first two spots it can happen.
UnexpectedEOF was added for a very specific reason and I would prefer not to see it infect the entire standard library.
What is the use case here. How will knowing that the image is corrupt because it contained less than the necessary bytes of data, vs some other kind of complete but still corrupt state be useful to the caller ?