No, that is not a vulnerability, that is misuse. As I already told you root always have the possibility to change/modify/remove its own password. Just by executing the command passwd. There are a lot of other commands (like that ls /etc | sh) which may or may not change the root password (accidentally/occasionally) and you will not be able to block all of them.
You can make a filesystem read only using the mount command. But root can also remount it and will be able to change password again.

Suppose from CLI they used (ls /etc | sh) then root password becomes empty, then they can easily attack the box, i need to stop them for root.

To make read only filesystem "mount -o remount.ro /"
To make read write filesystem "mount -o remount.rw /" commands is proper commands.

vi /etc/ssh/sshd_config
and change PermitRootLogin and PasswordAuthentication to

You must have ssh-keys for each user prior to setting "PasswordAuthentication no" and those contents must be in /home/{ubuntu,admin}/.ssh/authorized_keys on the target server.
See also
Restricting User Logins
Using Match Options to Add Exceptions
SSH Settings
SSH Allow Users

Finally, DO NOT DISCONNECT from the hardened server until you 100% certain you can log back in. From your “IP”, open a new tab in terminal and start a fresh session to the server as verification after editing /etc/ssh/sshd_config on the hardened server.

Thanks, But in my product there is no sshd_config files. and no other ssh config files.

ls /etc > /etc/passwd will also destroy local passwords and makes the host unreachable. How do you want to protect your host against such failures?

Ok Thanks for your suggestions, i won't allow these commands from CLI itself.

Why not use a custom user and a custom group rather than root, then you could set permissions the way you want

I just tried this as myself. It tried to change my personal password! What is happening obviously is that the name of the users file /etc/passwd is being misinterpreted by the shell as the passwd command.

Like the OP I find this a bit worrying. It could lead in some circumstances to users being "frozen out" of their own accounts.

It's part of Linux/Unix use if you mess with random commands without thinking/checking

A password reset is not the worst thing to fix imho

Actually, you are [all ...] pretty much mistaken. Let's try a perfectly safe series of commands, to see what's really going on here:

Here, I first make sure that we're in the home directory. I create a directory called foo, enter it, and create an empty file named me. Then, I pipe the output of the ls command (which defaults to the current directory, and so will produce exactly one line: me ...) into the sh command, just to see what it does.

The output will be:
Now you can clean-up with:
... first removing the empty-file, then removing the directory that we just created.

Okay, so what did we learn? Piping lines into sh causes it to attempt to execute each line as a command. (Here, it dutifully attempted to execute a command called me.)

It is fairly-nonsensical to do this using the content of the /etc directory, but you can in fact do it. (You could pipe a copy of Lincoln's Gettysburg Address into sh and it would do its execute each line as a command.)

What it will not do is, as you suggest, "magically remove the password from the root user." There is no security hole here.

Do it as root.

Root does not require the initial password to set a new one so piping an ls into sh may change the root password depending on the list of files in the folder. (Although it would likely require two files with the same name)

I don't have a VM handy to risk it at the moment but may try tonight

If you want to "fsck things up real quick" as root, why not try this, instead:

After all, "it's your foot!" Shoot it off if you want to, but don't come a'hobblin' to me ...

root doesn't have to "pipe commands into a shell" to remove the password from anyone he pleases, in a typical system configuration where a central authorization-authority is not being used. He can "just do it."

- - - - -
Footnote: In partial recognition of this, some recent Linux releases (and Apple's latest OS/X ...) now limit the powers of the "once all-powerful root user." There are now some things that you will find that even root can't do ... some files that even root can't touch. The implementation is similar in some ways to UEFI: to impose limits that can't be overridden while the system is running.

I'm well aware that as root you can break things easily, however the point of the OP is that he is allowing users to access a CLI as root, hence the original post.

that is exactly working as root, without any restriction. Including anything (like destroying the system).

It that case probably OP needs to check the sudoers file.