WAF

Why WAFs can’t catch VMware CVE-2021-21972 Remote Code Execution Exploit?

The recent critical security issue in VMware vCenter was discovered this January and fixed on February 23rd https://www.vmware.com/security/advisories/VMSA-2021-0002.html. The exploit looks like a simple JSP shell upload, but for some reason, it's a blind spot for Web Application Firewalls (WAFs). Let's understand why.

The CVE-2021-21972 affects vCenter versions 6.5, 6.7, and 7.0. The exploit for Metasploit released https://vulners.com/packetstorm/PACKETSTORM:161695 today.

The exploit description is pretty straight forward "This module exploits an unauthenticated OVA file upload and path traversal in VMware vCenter Server to write a JSP payload to a web-accessible directory. ". It should be something like a classic web shell file upload issue from the 90th. 

This issue's root cause is behind an unauthenticated OVA upload endpoint on the "/ui/vropspluginui/rest/services/uploadova" URL. But the neat thing is that the payload itself is delivered inside the TAR file package and uses path traversal trick inside. 

This part of the exploit source code explains it: 

# HACK: Spray JSP in the OVA and pray we get a shell...  
Rex::Tar::Writer.new(ova_file) do |tar|  
jsp_paths.each do |path|  
# /tmp/unicorn_ova_dir/../../<path>  
tar.add_file("../..#{path}", 0o644) { |jsp| jsp.write(payload.encoded) }  
end  
end  

As we can see, a JSP file with a web shell inside added to the TAR achieve with the path traversal attack vector in a file path. As a result, VMware vCenter software extracts the JSP web shell from the TAR file to the webserver's "resources" or "statsreport" folder. Once uploaded, the web shell is available by a direct HTTP request.

So, what happens with WAFs in this case? An answer is simple, and it's encoding. Since malicious payloads like web shell JSP body and path traversal attack in a filename encoded by TAR file format, WAF can't see it. For web application firewalls, it's just binary data that goes to the webserver and nothing more. To catch such cases, WAFs should be able to decode TAR files on a flight, unpack them, check for malicious payloads, and only after that sends to a protected webserver or API gateway. 

Unfortunately, not all the WAFs support TAR encodings, as well as JSON, GZIP, XML, and a bunch of more usual web data formats.

To mitigate this issue, we recommend applying a virtual patch for the "/ui/vropspluginui/rest/services/uploadova" endpoint.

Stay secure!

Recent Posts

Lessons from the OpenAI and Hugging Face Incident: When Safety Filters Disarm the Defender

In July 2026, an OpenAI model escaped its evaluation sandbox and broke into Hugging Face's…

1 month ago

AI Control Platform vs. AI Firewall vs. AI Gateway: Clearing Up The Terminology

Editor's note: This article was originally published by Tim Erlin on LinkedIn. It has been…

2 months ago

Introducing the Wallarm AI Control Platform: One closed loop for AI security and API security.

TL;DR- AI deployment has outpaced AI governance. Most enterprises running AI on AWS cannot answer…

3 months ago

What Your Board Gets Wrong About AI Security

Editor's note: This article was originally published by Craig Riddell on LinkedIn. It has been…

4 months ago

Extending Security to MCP Servers: Closing a Critical Gap

The Model Context Protocol (MCP) is a de facto standard for providing structured access to…

4 months ago

Introducing Wallarm Middle East Cloud: Built for Data Residency Compliance

As API and AI adoption grows across the Middle East, so do the expectations around…

4 months ago