A deserialization vulnerability in BMC FootPrints allows authenticated attackers to execute arbitrary code, posing a critical risk of full application compromise.

This flaw exists within the ASP.NET servlet VIEWSTATE handling, where improper deserialization of untrusted data occurs. An authenticated attacker can supply crafted serialized objects via the VIEWSTATE parameter to achieve remote code execution on the underlying server.

Successful exploitation of this vulnerability allows an attacker to gain full control over the affected BMC FootPrints instance, which typically houses sensitive organizational data, incident reports, and IT asset inventory. Given the CVSS score of 8.8, the risk is high, particularly because ITSM platforms are frequently targeted to facilitate lateral movement within corporate networks. Compromise of this system can lead to significant data breaches and total loss of confidentiality, integrity, and availability of the service.

Immediate Action: Apply the vendor-provided hotfixes immediately. Refer to the BMC documentation to install the specific patch version corresponding to your current deployment, such as 20.24.01 or the relevant 20.20.x through 20.23.x updates.

Proactive Monitoring: Review application and web server logs for suspicious VIEWSTATE parameters or unexpected process execution spawned by the application service account. Monitor for anomalous network traffic originating from the BMC FootPrints server.

Compensating Controls: Deploy a Web Application Firewall (WAF) with rules configured to inspect and block malicious serialized objects or suspicious payloads within the VIEWSTATE parameter. Ensure the application service is running with the least privilege necessary to restrict the impact of potential code execution.

Public Exploit Available: Yes — a published proof-of-concept exists as documented by watchTowr Labs.

This vulnerability presents a significant risk to organizational infrastructure due to the sensitive nature of the data managed by BMC FootPrints. Security teams should prioritize patching cycles for this software immediately, as the availability of a functional proof-of-concept significantly lowers the barrier for motivated attackers. If immediate patching is not feasible, ensure that access to the ITSM interface is restricted to trusted internal networks only.