{"uuid": "75e91392-6df4-4070-9fe7-97dd8fa231ec", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-11075", "type": "seen", "source": "https://t.me/cissp/1536", "content": "Collection of ideas and specific exploits against Docker CVE scanners\n\nTL;DR\nMost Docker image scanners make use of shell access, run package managers, if you run it on the Dockerfile you don't know you could expect. Running them on untrusted code can lead to command execution, some of the scanner providers don't consider this an issue, they (probably rightly) expect people to expect this. However, keep this in mind whenever you use these tools, especially if you add it to your CI/CD pipeline or other security automation where this might become an issue, most likely to escalate privilege or attack your CI or security automation itself.\nAll issues have been fixed by the vendors or considered as not a security issue\n\nIdeas if you have to exploit such tools or think about how attackers would\n \u2022 Anchore runs as a service, attacking it is more interesting because it might have its own rights or could be a way to gain persistance. They do not run package managers but there are shell shananigans non the less. This leads us to CVE-2020-11075, which is specific to them but shows how scanning docker images is hard to defend.\n \u2022 For scanners, such as FOSSA, Snyk or WhiteSource, that run package managers directly to resolve dependencies, you can obviously run commands through gradlew or Podfiles\n \u2022 The example for Snyk shows how running docker commands to examine the images can result in code execution. But in general shelling out often is usually a bad idea for security.\n \u2022 Similarly exploits on WhiteSource show how you can execute commands either by tricky directory names or again by manipulating (through injection) values that will be arguments for shell commands.\nhttps://github.com/gmatuz/cve-scanner-exploiting-pocs", "creation_timestamp": "2026-09-01T17:01:11.643985Z"}