The Apache Struts 2 advisory landed on the 7th — CVE-2017-5638, S2-045 in the Apache Struts security bulletin sequence (Apache Struts S2-045 advisory). The flaw is in the Jakarta Multipart parser, used by Struts to handle file uploads, and triggers when the parser fails to handle a specially crafted Content-Type header. The crafted value contains an OGNL expression that the error-handling path evaluates rather than treating as opaque, with the result that arbitrary code execution as the web-server process is achievable from a single HTTP request to any Struts-served endpoint that accepts uploads. That is essentially every Struts deployment.
The disclosure-to-exploitation timeline has been short. Patches landed on the 7th. Working exploit code was public on Pastebin within hours. Internet-wide scanning for vulnerable endpoints began within twenty-four hours. By yesterday, multiple security teams have reported active exploitation against unpatched Struts deployments — Cisco Talos has a useful summary (Talos blog post on the Struts mass exploitation), and the F5 and Akamai web-application-firewall teams have published their detection patterns. The exploitation rate is going to be high through the rest of this week and into next; the patch propagation rate, given the deployment population, is going to lag.
The deployment population matters. Apache Struts 2 is a mature Java web framework used by a substantial number of enterprise web applications, often in places where the framework choice was made years ago and is not currently being actively maintained. Banking applications, government portals, e-commerce platforms, internal corporate tools — the Struts footprint is wide and uneven. The software bill-of-materials problem is acute for Java applications generally and for Struts specifically: the framework is often embedded in vendor-shipped applications where the customer organisation is unaware of its presence and does not control the patching cadence. The vCISO conversations this week have included several "do we have Struts anywhere" questions where the honest answer is "you almost certainly do, and we will need a week to find all of it".
For the customer estates, the audit posture this week is concrete. Identify every Java web application running internally or externally. For each, determine whether Struts 2 is in the dependency tree (Maven and Gradle dependency listings, manual inspection of WAR file contents, or where neither is available, vendor inquiry). For applications with Struts 2 in scope, identify the specific version. For applications with vulnerable versions, patch immediately if vendor-supported, or apply the documented mitigation (Servlet filter rejecting the malicious Content-Type pattern) where the patch path is not yet available. Browne Jacobson's estate has two Struts-using vendor applications and both are being patched today. The manufacturer has at least four. Northcott's external services are not Struts-based but their internal procurement-system vendor has shipped a Struts-using application that is under audit. The new financial-services client's customer-facing platform uses Struts in two components and has been patched.
The wider point is the dependency-tree management problem. The Struts S2-045 advisory is the latest in a long sequence of vulnerabilities in widely-deployed open-source components — Heartbleed in OpenSSL was the highest-profile precedent, Shellshock in bash was another, Logjam and DROWN extended the pattern into protocol implementations. The defensive posture against this class of vulnerability requires the customer organisation to know what is in its software, to track upstream vulnerability disclosures against that bill-of-materials, and to patch on a cadence that matches the disclosure-to-exploitation timeline (which is shrinking; for Struts it was hours). Most customer organisations do not have the operational capability to do this well across their full estate. The supply-chain security conversation is going to get more attention through 2017 and beyond.
I will keep watching the exploitation pattern through the next two weeks. There will be specific incidents — large breaches of organisations whose Struts patching was incomplete — and those incidents will surface over the coming months, not the coming days. The dwell time between an exploited Struts vulnerability and the discovery of the resulting compromise is, on the historical evidence, substantial. The operational implication is that if your organisation is found to have had a vulnerable Struts application this week, the assumption should be that you may already be compromised, and the response should include retrospective hunt activity rather than just patching.