back to article Patch now: RCE Spring4shell hits Java Spring framework

Another Java Remote Code Execution vulnerability has reared its head, this time in the popular Spring Framework and, goodness, it's a nasty one. Dubbed "Springshell" or "Spring4Shell", the vulnerability requires an endpoint with DataBinder enabled. "For example," explained security shop Praetorian, "when Spring is deployed to …

  1. Mike 137 Silver badge


    'Jamie Moles, senior sales engineer at ExtraHop, commented: "While Spring has moved remarkably fast on deploying a patch, this is still a customer responsibility.'

    Surely, in an ideal world, the primary responsibility should rest with the framework developers to code and test adequately so the customer wouldn't need to patch so often. A very high proportion of 'vulnerabilities' result from basic coding errors at the increasingly neglected metal level. But of course that's where most of the potential for critical errors sits.

    The prevalent idea that it's perfectly fine for vendors to release dangerously flawed products to customers, who are then 'responsible' for protecting themselves need to be eradicated if any significant progress is to be made in infosec. As it is, the last three or so decades have seen the overall state of infosec decline rather than improving, despite all the ostensible technical 'advances' in security provisioning.

    1. PaulusTheGrey

      Re: Whose?

      In a perfect world Sales and Account managers would keep pushing the devs so hard to get the product out there as soon as insanely possible.

    2. Paul Johnston

      Re: Whose?

      Love the optimism but by that way I don't think anything would get done. Have known people who just want to get stuff out asap and others who are incapable of this as they need "one more check" . It's all a case of balance. Finally it's not as if the bad actors play like that. Offense and defence are both advancing and so will it ever be.

    3. yoganmahew

      Re: Whose?

      Is there nothing to be said for another unit test?

      1. malfeasance

        Re: Whose?

        To quote some analysis about this CVE (veracode) you need to be using

        Spring Web MVC or Spring Webflux projects AND

        Spring Framework version 5.3.x prior to 5.3.18, and all versions prior to 5.2.20 AND

        Java 1.9 or above AND

        Deployed on Tomcat App Server as a WAR AND

        Spring Web MVC with parameter binding (enabled by default) AND

        Don’t have an allowlist of HTTP fields registered to be allowed or explicitly disallow fields which could cause malicious intent.

        The interaction between all those components are unlikely to be covered by a unit test, so it's somewhat disingenuous to mention it. It would have to be an integration test that needed to be done by the Spring team using things that are outside of their control.

        I would note here that if you're a vanilla spring-boot user then you're not vulnerable to this partcular RCE.

  2. sanmigueelbeer

    While we are in the topic of software vulnerability, I would like to add: HP printers carry code execution bug

    Certain HP Print Products, Digital Sending Products - Potential remote code execution and buffer overflow -- This page contains instruction about how to disable LLMNR on the printer.

    1. Twilight

      Guess that's a benefit of keeping printers for a long time. I have an HP but it is not on the list of affected devices.

    2. Chris Coles

      HP? Dumped Them Years Ago

      Never; Ever; Use HP Products Ever Again. PERIOD!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like