I would not call it vulnerabilities, maybe an exploit, but that’s also a bit much.
You always have to assume you cannot correct anything once you pressed the send button, no two ways about it. Reasons being:
- You can not do anything if the recipient is offline right after receiving the message, neither delete/resend, undo send, nor edit.
- Timing out messages or media can be photographed with another device.
- (Forks can just ignore anything of the above.)
- Absence of any check mark (“sent” and “received”) is no indication that it has not been sent, nor received, since your own connection could be delayed.
- Even if there is a possibility to hide the edit or even the entire message, Android, another app, or a connected smart device could have already logged the original one.
The only (flawed and incomplete) way around some of this would be a private notification/message without sender and content (handshake “message”), enforcing a reception response as soon as the app is open and only then let the server send the actual message, making any remote function for the sender obsolete again.
(Something like this, where -/> indicates end of influence of sender:
Sender sends message to server -> server sends notification for undisclosed message to recipient -> recipient sends acknowledgment to server or sender, if disclosed -/> sender auto-authorizes server if not stopped before -> server sends message to recipient)
(Also, given the arguments above, reports for sent/received / check marks in general are a mere convenience as of now and don’t serve a verifiable purpose at all.)