An issue was discovered in gsi-openssh-server 7.9p1 on Fedora 29. If PermitPAMUserChange is set to yes in the /etc/gsissh/sshd_config file, logins succeed with a valid username and an incorrect password, even though a failure entry is recorded in the /var/log/messages file.

A vulnerability was found in libssh's server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access.

The recv_msg_userauth_request function in svr-auth.c in Dropbear through 2018.76 is prone to a user enumeration vulnerability because username validity affects how fields in SSH_MSG_USERAUTH messages are handled, a similar issue to CVE-2018-15473 in an unrelated codebase.

An issue was discovered in cckevincyh SSH CompanyWebsite through 2018-05-03. admin/admin/fileUploadAction_fileUpload.action allows arbitrary file upload, as demonstrated by a .jsp file with the image/jpeg content type.

An issue was discovered in cckevincyh SSH CompanyWebsite through 2018-05-03. SQL injection exists via the admin/noticeManageAction_queryNotice.action noticeInfo parameter.

Insecure access control in freeSSHd version 1.3.1 allows attackers to obtain the privileges of the freesshd.exe process by leveraging the ability to login to an unprivileged account on the server.

The SSH server implementation of AsyncSSH before 1.12.1 does not properly check whether authentication is completed before processing other requests. A customized SSH client can simply skip the authentication step.

FreeSSHd 1.3.1 version is vulnerable to an Unquoted Path Service allowing local users to launch processes with elevated privileges.

The server in Dropbear before 2017.75 might allow post-authentication root remote code execution because of a double free in cleanup of TCP listeners when the -a option is enabled.

Dropbear before 2017.75 might allow local users to read certain files as root, if the file has the authorized_keys file format with a command= option. This occurs because ~/.ssh/authorized_keys is read with root privileges and symlinks are followed.