No, it's not possible, if you're only talking about a CSWSH style of hijacking.
In CSWSH, the user is on an attacker-website and the attack happens on the user's browser while on the attacker-website.
For a WebSocket, for the ability to "write" something to the server, or "read" some private information back, the WS security mechanism must be cookie-driven, and the writable remote messaging functions need to be vulnerable (don't require additional unique information) for "write" attacks.
A "write" attack of CSWSH could change the price of an apple, if the server's pricing functions are vulnerable. The user would need to be authorised to make the price change, or the server functions would need to be unsecured. The attacker would need to know the right messages to send. But this isn't mutating data coming back through the WS channel itself.
It isn't possible to change the server-data coming from the websocket itself. CSWSH operates on the browser side on the receiving end of server communications, not in the middle in between the legitimate side and the server - that requires a MITM attack of some sort that is stopped by TLS.
Being on the attacker-website, naturally, the attacker-website cannot change the data being returned from the WebSocket channel itself. However, it could receive a value from the server and present a different value to the user. That occurs by throwing away the server value after it arrives in the browser from the WebSocket. But there is little or no value for this, the attacker-website is already a fraud and can display incorrect information without waiting for a WebSocket message from the server.
Regardless of what happens on the client-side, server functions need to be defined to validate input. Even on the legitimate site, if the client-side can assert their own apple price in an order, it's not secure in general anyway. The server should lookup the price of the apple from the product-id in the order when charging the user's credit card.