There appears to be a bug in the implementation of "checkForUtf8ByteOrderMark" in org.springframework.ws.soap.saaj.SaajSoapMessageFactory.
Under certain circumstances, the call to pushbackInputStream.read(bom) will read less than the required 3 bytes into bom. Then, since the byte order mark isn't found, unread(bom) is called which results in some invalid bytes being added to the stream.
The contract for PushbackInputStream.read(byte b, int off, int len) says "Reads up to len bytes of data." In our case, using Tomcat (versions 6 and 7) with recent releases of Chrome and IE, the call to inputstream.available() in BufferedInputStream's implementation of read returns 0. This is because no more data can be read without blocking. It seems to be just an unfortunate coincidence caused by the size of the header sent by the newest version of chrome and IE. The end result is that our soap envelope is corrupted and our system is unusable.