The following answers depend on if the VNC sessions are started by the users of the system, or if they are pre-started on the server (e.g. you normally connect to a login manager)
User Started Sessions
How is it possible?
From what I can gather, Centos7 typically uses tigervnc.
Tigervnc uses authentication by default, but anyone who starts a vnc server can pass the option -SecurityTypes=None option when starting it. When this is done, it doesn't matter if your vnc viewer is configured to send credentials or not; the server doesn't ask for any credentials and lets you connect and see the session.
Since it takes effort to start a vnc server unsecured like this on Centos7, I'd say the person using the default port didn't want to be bothered by a password prompt and went out of their way to make their session insecure.
Is this really bad?
Probably, but it depends on the policies of whomever runs the server. If it is on a trusted network only used by trusted people, maybe its ok. That is (or should be) pretty rare though. It is generally a problem when someone can impersonate someone else without authentication, authorization and auditing, otherwise it is difficult to prove who actually did anything in someone's name.
Did you do something wrong?
As long as you didn't do anything as that user, you did nothing wrong. The person who started the server did wrong.
PreStarted VNC
How is it possible?
If the server is set up to have a pool of VNC servers or to start them on demand, then if you can connect to someone else's without authentication, anyone can connect to yours without authenticating (unless you start your own server on the machine for your session and ensure you enable authentication).
What happened would be the admin mis-configured the service or wanted it to be insecure on purpose. The configuration should probably have been to spawn a greeter/login screen on initial connect and only allow a single client to connect, and to logout when the client disconnects. However, it is either allowing more than one client to connect at a time ("sharing" the connection), or is allowing the session to persist after the initiator disconnected.
Is this really bad?
This is probably very bad, for similar reasons to the "User Started Sessions" part, but possibly worse because the admin might not expect this behavior. This is easier to set up incorrectly, especially if just copy/pasting example configurations online without reading the instructions.
Did you do something wrong?
In this case you did less wrong than in the user started sessions case. In that case you might have been expected to know that the running server wasn't your own. Here, there was no way to know that there was already someone else's session running on the port that you normally connect to.
xauthand magic cookies and the rest. something bad. i doubt very much you'll get in trouble if you tell the admin - said admin will probably thank you profusely for the tip. just let the admin know before you start calling bosses, (but do call bosses if it doesn't get fixed right away).