Major Description
Subnegotiation messages in telnet are sent using the sequence IAC SB ... IAC SE.
Although it's not clearly spelled out in RFC 854, any IAC (0xff) bytes inside these messages must be escaped by doubling. Other clients do this and this is the only behavior that makes sense.
The commons-net telnet client is failing both to escape and to unescape IAC bytes within subnegotiation messages. Moreover, if it does receive a valid IAC IAC sequence within a subnegotiation message, it will incorrectly jump back to "data" input mode, discarding the message and introducing its remainder as garbage in the data stream.
In addition, the code fails to check for an overflow of the subnegotiation buffer, which would cause an ArrayIndexOutOfBounds exception if a malicious peer triggered this condition.
Finally, a IAC SE sequence appearing by itself should probably be discarded, rather than passing as a command to the handler.
I'm attaching a patch to fix these issues.