back to article Four million outdated Log4j downloads were served from Apache Maven Central alone despite vuln publicity blitz

There have been millions of downloads of outdated, vulnerable Log4j versions despite the emergence of a serious security hole in December 2021, according to figures compiled by the firm that runs Apache Maven's Central Repository. That company, Sonatype, said it had seen four million downloads of exploitable Log4j versions …

  1. b0llchit Silver badge

    If the update is so important (it is), then maybe they should force auto-builds to fail by renaming the vulnerable versions to something the scripts do not find for auto/scripted downloads. You can also poison the vulnerable versions at the source and having them bail out on first call with a log-message "please update".

    These would be (very) hard measures, but it may be necessary for the long tail to become shorter.

    1. Joe W Silver badge

      And I even feel that I saw some type of this behaviour a few years back - maybe with the ssl stuff-up?

    2. RichardBarrell

      Yeah. Withdrawing known-dangerous packages from availability is pretty common practice. Varies by community, though.

    3. Clausewitz 4.0

      Just hope a nuclear reactor safety procedure isn't using an automatic fetch / build of this version.

      Or a missile launcher.

      Or an industrial chemical plant.

    4. DS999 Silver badge

      Or backport the fix

      If you're going to leave the older versions up, don't leave vulnerable older versions up!

      1. b0llchit Silver badge

        Re: Or backport the fix

        You can patch the older version, but it has the same problem/advantage as poisoning the package. The hash of that specific version changes. That should let some build systems fail if they have previously seen that package. IMO, if it is (mostly) the same behavior in the build, then you should pull the old package and force a fix of the build scripts.

        1. DevOpsTimothyC

          Re: Or backport the fix

          You can patch the older version

          No, you can create a new patched version of the older version eg 2.12.2 becomes 2.12.2-1 and the original 2.12.2 gets pulled. As soon as you start switching the content of the versions, and relying on the hash you in a very bad place.

          The hash is there so you can ensure the package was not tampered with in transit it was not there to paper over what should be immutable

  2. spireite Silver badge

    I know this will be an unpopular viewpoint, but why not just yank the bugged versions?

    Oh, injetc into said buggy versions a banner/print/whatever.....

  3. Warm Braw

    Eh, what?

    If this estimate is anywhere near accurate, that would be more than one download for every four professional software developers in the world.

    Are there are a lot of ill-considered build scripts out there hammering the repositories or are there really that many unsuspecting users simply cutting and pasting the URLs from the installation instructions for the packages that make use of Log4j?

    1. Anonymous Coward
      Anonymous Coward

      @Warm Braw - Re: Eh, what?

      Nah, they're developers. They can't be bothered with such mundane stuff like security. Remember, they're the one who got us in this sh$%t in the first place by adding that marvellous feature.

      1. Penguin Of Evil

        Re: @Warm Braw - Eh, what?

        Their management probably told them to add features and in unrealistically short time. Their management didn't have a security policy or didn't enforce it. Their lawyers didn't have a reason to make sure they did. If your house falls down it's not usually down to the bricklayer.

        In a properly run environment it is the case that

        a) You have accurate and complete mainfests. When a vulnerability or flaw is identified you immediately know what is affected. When it's hardware this happens. In the exploding battery saga vendors rapidly produced lists of affected serial numbers. In the exploding motherboard story this month the same. In a well run business the question "what uses log4j" is answerable with a couple of database lookups. In software and related services it's handled by running around like headless chickens and then writing scanners because nobody knows.

        b) You have change control. When a third party package changes the build gets stopped because it has the wrong secure hash, or better yet you keep the approved copy local. Even basic open source tools like RPM have been doing this for many years.

        1. yoganmahew

          Re: @Warm Braw - Eh, what?

          c) You don't have cheapest-bid contractors cutting and pasting old versions from SO. Even after log4shell is known.

          d) Your corporate security department isn't stuffed full of promotion seekers because it's a cushy number pushing paper around.

  4. Anonymous Coward
    Anonymous Coward

    "We could have used that to SPY on the Americans! Bad tech company! Bad!"

    -- Chinese Government

  5. Penguin Of Evil

    And we are surprised because ?

    Even supposedly "serious" businesses like Microsoft have subsiduaries still shipping OpenSSL 1.1.0e 16 Feb 2017 (Microsoft Zenimax Elder Scrolls Online)

    Give em another decade and they might get around to log4j

    Until these big corporations can be meaningfully sued for bad software and services nothing will get fixed

    1. Anonymous Coward
      Anonymous Coward

      Unlikely to happen. They have hundreds of millions to pay lawyers with.

      We can't find enough funding for all the OSS developers and projects to be paid enough to eat based on their labors.

      And if you can "meaningfully sue" Microsoft over an OpenSSL vulnerability, you can bet they'll sue the OpenSSL developers and official project organization over it, regardless of the terms of the license. Big organizations don't just eat their court losses; they do their best to pass the buck down the feeding chain.

  6. shodanbo

    Yea these downloads are probably automated so I'm sure all the tremendously witty comments provided here will make an actual difference.

    1. Anonymous Coward
      Anonymous Coward


      I'm sure most of these are accounted for by instances of binary managers like Artifactory that clone Maven Central frequently

      1. DevOpsTimothyC

        Re: Absolutely

        Why would you ever have something like artifactory set like that. One of the major selling points of artifactory, nexus and similar is that they "protect" the company by ensuring that they have local copies of what was used to build the software. The only time a library is pulled form public repo's should be when it's first introduced to the code base.

  7. Anonymous Coward
    Anonymous Coward

    "downloads of pre-2.15 versions of Log4j from the Maven central repository was oddly high"

    Threat actors and wannabes, downloading the unpatched version to test & refine their weapons ? Seems that it will still be a while before the patch mostly applied

    "Unlikely to happen. They have hundreds of millions to pay lawyers with."

    Developers can all go for their extended holiday off grid & work. Corp will have to pay for overtime and holiday pay to get this looked into and, perhaps, working again. But, as it is , in the long term, anyone trying this could risk having their roles outsourced to another country.

  8. FireBurn

    Dependency Hell

    When I was rebuilding some packages after bumping the log4j2 version numbers in pom.xml, I found quite a few examples of the old versions being downloaded by other dependencies

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