Even though, the date (2014-02-07) indicated in http://commons.apache.org/proper/commons-fileupload/changes-report.html for the fix for CVE-2016-3092 in 1.3.2 is the same as the date indicated for the fix for CVE-2014-0050 in 1.3.1, this is incorrect. The actual date on which the fix for CVE-2016-3092 in 1.3.2 was made is 2016-05-12, as can be seen in the commits log of the Apache Commons FileUpload repository found on these pages:
So, it's safe to assume that the date being the same for these two fixes was a mistake on the page itself, presumably for simply copy/pasting some markup, which discards the possibility of CVE-2016-3092 being indirectly fixed and not applicable in 1.3.1.
There can be found multiple statements about CVE-2016-3092 actually affecting 1.3.1, as can be seen in the following pages:
However, no fix seems to have been applied to the 1.3.1 version, which is the one in our codebase.
The actual fix is simple enough and consists in making the buffer size bigger if it's not big enough, as can be seen in the following revision log and diff record for this fix, respectively:
r52780: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (4.3 trunk)
r52781: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (EE 3.3 maintenance branch)
Even though, the date (2014-02-07) indicated in http://commons.apache.org/proper/commons-fileupload/changes-report.html for the fix for CVE-2016-3092 in 1.3.2 is the same as the date indicated for the fix for CVE-2014-0050 in 1.3.1, this is incorrect. The actual date on which the fix for CVE-2016-3092 in 1.3.2 was made is 2016-05-12, as can be seen in the commits log of the Apache Commons FileUpload repository found on these pages:
So, it's safe to assume that the date being the same for these two fixes was a mistake on the page itself, presumably for simply copy/pasting some markup, which discards the possibility of CVE-2016-3092 being indirectly fixed and not applicable in 1.3.1.
There can be found multiple statements about CVE-2016-3092 actually affecting 1.3.1, as can be seen in the following pages:
However, no fix seems to have been applied to the 1.3.1 version, which is the one in our codebase.
The actual fix is simple enough and consists in making the buffer size bigger if it's not big enough, as can be seen in the following revision log and diff record for this fix, respectively:
r52780: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (4.3 trunk)
r52781: committed fix for the CVE-2016-3092 vulnerability to our apache commons fileupload codebase (EE 3.3 maintenance branch)