CVE-2015-7547 affects glibc, which is present in pretty nearly all docker containers. There's an automated process underway which will update all official containers, but it's not immediately clear how I should manage the situation.

Some third party containers are poorly maintained, and likely not to get rebuilt any time soon. We have local containers that need work to get re-builds done, often not more complicated than rebasing them on a newer upstream base container. The speed of those upstream containers getting rebuilt will be quite variable. If I rebuild everything locally now, I'll be too early to get the fix in some cases. In general the 'everything's just a container' promise of docker administration doesn't hold here.

So, what strategies are available?

One thing that would be really useful would be to be able to docker exec something in each container to check if it's vulnerable. Something which directly tests for the vulnerability would be ideal, but failing that some tool which knows enough about the packaging systems of all sorts of different linux distributions would also be helpful. Is such a tool available that will run in the diverse range of (often minimal) docker containers?

Any other ideas?

  • I'm wondering if this would have been better to be posted on serverfault. Thoughts?
    – mc0e
    Commented Feb 20, 2016 at 14:06
  • raw.githubusercontent.com/pbkwee/deghost/master/deghost.sh goes some way towards this, but doesn't cover alpine linux in particular of the ones popular for docker containers.
    – mc0e
    Commented Feb 20, 2016 at 17:37
  • @DeerHunter no, there's nothing implicit in using docker to this problem, it's relying on a software stack you can' update, you get the same problem with many "appliances" where you have no control over the OS-level software Commented Feb 27, 2016 at 21:45

1 Answer 1


This is an unfortunate consequence of relying on software built/maintained by others, over which you have no control.

With Docker at least you have the opportunity of just replication the Dockerfile and then basing it on a fixed base image.

My recommendation would be that you do exactly that. The base OS images should be fixed by now, if you're using one that isn't rebuilt, just fork it and run your own Docker image based on the base OS of your choice.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .