Getting unexpected messages from some clients

I'm using Engine.IO in my application primarily as a WebSocket wrapper with a long-polling fallback to work around firewalls.

My server is a Node.JS script that uses Engine.IO 6.5.0 and the client is a website that uses Engine.IO-Client 6.5.0.

All packets are sent by client and server in binary format.

Client is sending data like this:

const socket = new eio("wss://example.com", {transports: ["polling", "websocket"]});
socket.binaryType = "arraybuffer";
socket.on("open", () => {
    const data = new Uint8Array(48);
    // fill data with known values
    socket.send(data);
});

Server is receiving data like this:

const eio = EngineIO.attach(server, {
    transports: ["polling", "websocket"],
    cors: {
        origin: "*",
        methods: "GET,HEAD,PUT,PATCH,POST,DELETE"
    }
});

eio.on("connection", (socket) => {
    // ...
    socket.once("message", (msg) => {
        assert(Buffer.isBuffer(msg));
        assert(msg.length === 48);
        const foo = msg.subarray(...);
        // ...
    });
});

Almost every client is sending and receiving messages correctly (I get 48 bytes and msg is a Buffer).

However, every day I get 1-2 clients that are sending something unexpected.

In the socket.once("message") callback, the msg that these clients send is ALWAYS:

• A Uint8Array instead of Buffer or String
• Has a length of 1 instead of 48
• Contains [0x08] instead of my data

The user agents of these clients are:

• Mozilla/5.0 (PlayStation Vita 3.74) AppleWebKit/537.73 (KHTML, like Gecko) Silk/3.2
• Mozilla/5.0 (BB10; Kbd) AppleWebKit/537.35+ (KHTML, like Gecko) Version/10.3.3.2163 Mobile Safari/537.35+
• Mozilla/5.0 (SMART-TV; Linux; Tizen 2.4.0) AppleWebkit/538.1 (KHTML, like Gecko) SamsungBrowser/1.1 TV Safari/538.1

The payload names no repository files or tests. Start by tracing Engine.IO 6.5.0 binary handling across the polling and WebSocket transports, using the reported Uint8Array containing [0x08] from the listed legacy user agents as the reproduction; done means identifying why the expected 48-byte message becomes that value and documenting a verified resolution.