The story begins in April 2016, when Tenable researcher Jacob Baines and the Tenable Network Security team identified an unsafe Java deserialization vulnerability in Spring Framework. They found that if an application uses Spring Framework’s HttpInvokerServiceExporter library to deserialize untrusted data, it may be possible for a remote attacker to execute code on the server through the manipulation of input data.
The discovery and PoC provided by Tenable were rejected by the Zero Day Initiative, however, before the vulnerability was brought to the attention of the Pivotal Security team. On May 4, 2016, the Spring Framework team responded that this was not unintentional behavior, and provided the following commentary:
While the Pivotal team acknowledged the dangers of untrusted input streams, it left the responsibility for safe configuration and use to developers. Pivotal followed up by including a warning to developers in the subsequent 4.2.6 and 3.2.17 release documentation.
The Black Duck® Security Research team in Belfast authored and published BDSA-2016-1700 to document this vulnerability. Our research concluded that the vendor’s position holds, and that the documented warning was sufficient. Having identified the specific code commit that introduced the contentious code, we determined that versions 3.0.0 to 3.2.16, and versions 4.0.0 to 4.2.5 was the correct vulnerable range.
A CVE was assigned to this issue in August 2016, but it was not fully analyzed by the National Vulnerability Database (NVD) until January 2020. Initial analysis listed just one affected version, 4.1.4. But in April 2022, this CVE was analyzed again, and the affected version range was changed to all versions up to and including 5.3.16.
A Spring Framework maintainer responded.
The CVE was updated again in May 2022, and the affected versions are now considered all up to (but excluding) 6.0.0.
As a result of the April 2022 NVD update, CVE-2016-1000027 was flagged against all Spring Framework versions, up to and including 5.3.16, causing questions about its sudden appearance on security scan results. In some cases, the appearance of an RCE vulnerability on a software Bill of Materials triggered delays in software release schedules.
It’s not uncommon for a vulnerability to be raised and then for the software vendor to reject the issue as intended behavior and settle the matter with an update to documentation. It is valid argument that these issues are not vulnerabilities per se and shouldn’t be treated as such. However, as the Spring Framework maintainer says, the advisory serves as a useful reminder. Although there is no remediation advice we can offer, we plan to continue flagging these issues in our BDSA feed when we are aware of them, and provide what can be essential knowledge from vendor to developer.