Disclosure Date: April 05, 2010 (last updated July 30, 2020)
** DISPUTED ** The Command Line Interface (aka Server CLI or administration interface) in the master process in the reverse proxy server in Varnish before 2.1.0 does not require authentication for commands received through a TCP port, which allows remote attackers to (1) execute arbitrary code via a vcl.inline directive that provides a VCL configuration file containing inline C code; (2) change the ownership of the master process via param.set, stop, and start directives; (3) read the initial line of an arbitrary file via a vcl.load directive; or (4) conduct cross-site request forgery (CSRF) attacks that leverage a victim's location on a trusted network and improper input validation of directives. NOTE: the vendor disputes this report, saying that it is "fundamentally misguided and pointless."
Disclosure Date: June 09, 2020 (last updated July 24, 2020)
A security feature bypass vulnerability exists when Windows Kernel fails to properly sanitize certain parameters.To exploit the vulnerability, a locally-authenticated attacker could attempt to run a specially crafted application on a targeted system.The update addresses the vulnerability by correcting how Windows Kernel handles parameter sanitization., aka 'Windows Kernel Security Feature Bypass Vulnerability'.
Disclosure Date: March 30, 2020 (last updated June 05, 2020)
An issue was discovered in Open Source Social Network (OSSN) through 5.3. A user-controlled file path with a weak cryptographic rand() can be used to read any file with the permissions of the webserver. This can lead to further compromise. The attacker must conduct a brute-force attack against the SiteKey to insert into a crafted URL for components/OssnComments/ossn_com.php and/or libraries/ossn.lib.upgrade.php.
A Linux kernel vulnerability in TCP networking could allow DoS
> CVE-2019-11477 is considered an Important severity, whereas CVE-2019-11478 and CVE-2019-11479 are considered a Moderate severity. The first two are related to the Selective Acknowledgement (SACK) packets combined with Maximum Segment Size (MSS), the third solely with the Maximum Segment Size (MSS).
Vulnerable code exists in https://github.com/torvalds/linux/blob/master/include/linux/skbuff.h
This might stick around in various embedded hardware, which could be more disasterous if DoS'ed, but it's too early to tell.
Disclosure Date: February 24, 2020 (last updated July 24, 2020)
When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 188.8.131.52, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations.
Disclosure Date: March 25, 2020 (last updated July 24, 2020)
Saml2 Authentication services for ASP.NET (NuGet package Sustainsys.Saml2) greater than 2.0.0, and less than version 2.5.0 has a faulty implementation of Token Replay Detection. Token Replay Detection is an important defence in depth measure for Single Sign On solutions. The 2.5.0 version is patched. Note that version 1.0.1 is not affected. It has a correct Token Replay Implementation and is safe to use. Saml2 Authentication services for ASP.NET (NuGet package Sustainsys.Saml2) greater than 2.0.0, and less than version 2.5.0 have a faulty implementation of Token Replay Detection. Token Replay Detection is an important defense measure for Single Sign On solutions. The 2.5.0 version is patched. Note that version 1.0.1 and prior versions are not affected. These versions have a correct Token Replay Implementation and are safe to use.