UltraVNC revision 1211 has multiple off-by-one vulnerabilities in VNC server code, which can potentially result in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.

UltraVNC revision 1206 has stack-based Buffer overflow vulnerability in VNC client code inside FileTransfer module, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. This vulnerability has been fixed in revision 1207.

UltraVNC revision 1211 has multiple improper null termination vulnerabilities in VNC server code, which result in out-of-bound data being accessed by remote users. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1212.

UltraVNC revision 1198 contains multiple memory leaks (CWE-655) in VNC client code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1199.

UltraVNC revision 1205 has stack-based buffer overflow vulnerability in VNC client code inside ShowConnInfo routine, which leads to a denial of service (DoS) condition. This attack appear to be exploitable via network connectivity. User interaction is required to trigger this vulnerability. This vulnerability has been fixed in revision 1206.

UltraVNC revision 1203 has multiple heap buffer overflow vulnerabilities in VNC client code inside Ultra decoder, which results in code execution. This attack appears to be exploitable via network connectivity. These vulnerabilities have been fixed in revision 1204.

UltraVNC revision 1198 has a heap buffer overflow vulnerability in VNC client code which results code execution. This attack appears to be exploitable via network connectivity. This vulnerability has been fixed in revision 1199.

If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q).

FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to execute arbitrary code by leveraging failure to block the blaze-ds-opt and blaze-ds-core classes from polymorphic deserialization.

FasterXML jackson-databind 2.x before 2.9.7 might allow remote attackers to execute arbitrary code by leveraging failure to block the slf4j-ext class from polymorphic deserialization.