When mod_remoteip was configured to use a trusted intermediary proxy server using the "PROXY" protocol, a specially crafted PROXY header could trigger a stack buffer overflow or NULL pointer deference. This vulnerability could only be triggered by a trusted proxy and not by untrusted HTTP clients.
There is a stack-based buffer overflow in the nfs_handler reply helper function: nfs_umountall_reply().
There is a stack-based buffer overflow in the nfs_handler reply helper function: nfs_mount_reply().
There is a stack-based buffer overflow in the nfs_handler reply helper function: nfs_readlink_reply().
There is a stack-based buffer overflow in the nfs_handler reply helper function: nfs_lookup_reply().
There is a stack-based buffer overflow in the nfs_handler reply helper function: rpc_lookup_reply().
Insufficient validation of environment variables in the telnet client supplied in FreeBSD can lead to stack-based buffer overflows. A stack-based overflow is present in the handling of environment variables when connecting via the telnet client to remote telnet servers. This issue only affects the telnet client. Inbound telnet sessions to telnetd(8) are not affected by this issue. These buffer overflows may be triggered when connecting to a malicious server, or by an active attacker in the network path between the client and server. Specially crafted TELNET command sequences may cause the execution of arbitrary code with the privileges of the user invoking telnet(1).
An authenticated user could create a stack-based buffer overflow by changing their own password to a purpose-crafted value. In addition to the ability to crash the PostgreSQL server, this could be further exploited to execute arbitrary code as the PostgreSQL operating system account. Additionally, a rogue server could send a specifically crafted message during the SCRAM authentication process and cause a libpq-enabled client to either crash or execute arbitrary code as the client's operating system account. This issue is fixed by upgrading and restarting your PostgreSQL server as well as your libpq installations. All users running PostgreSQL 10, 11, and 12 beta are encouraged to upgrade as soon as possible.