CVE-2020-3153
A vulnerability in the installer component of Cisco AnyConnect Secure Mobility Client for Windows could allow an authenticated local attacker to copy…
Medium
Known exploited
- Severity
- 6.5 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 28.52%
- Chance of exploitation in the next 30 days. Higher than 98.13% of scored vulnerabilities.
- Known exploited
- Yes
- In CISA's catalog since Oct 24, 2022
- Fix
- None yet
- No fixed version published
Exploited in the wild. Cisco AnyConnect Secure Mobility Client for Windows Uncontrolled Search Path Vulnerability (Cisco AnyConnect Secure). Required action: Apply updates per vendor instructions. Due for U.S. federal agencies by Nov 14, 2022. Known to be used in ransomware campaigns.
Description
A vulnerability in the installer component of Cisco AnyConnect Secure Mobility Client for Windows could allow an authenticated local attacker to copy user-supplied files to system level directories with system level privileges. The vulnerability is due to the incorrect handling of directory paths. An attacker could exploit this vulnerability by creating a malicious file and copying the file to a system directory. An exploit could allow the attacker to copy malicious files to arbitrary locations with system level privileges. This could include DLL pre-loading, DLL hijacking, and other related attacks. To exploit this vulnerability, the attacker needs valid credentials on the Windows system.
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 6.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Weakness
CWE-427: Uncontrolled Search Path Element
The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.
How to prevent it
- Architecture and Design, Implementation: Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
- Implementation: When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
- Implementation: Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
- Implementation: Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution.
- Implementation: Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path.
CWE-427: Uncontrolled Search Path Element
The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.
How to prevent it
- Architecture and Design, Implementation: Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
- Implementation: When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
- Implementation: Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
- Implementation: Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution.
- Implementation: Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path.
References
Advisories
- packetstormsecurity.com/files/157340/Cisco-AnyConnect-Secure-Mobility-Client-4.8.01090-Privi…
- packetstormsecurity.com/files/158219/Cisco-AnyConnect-Path-Traversal-Privilege-Escalation.html
- packetstormsecurity.com/files/159420/Cisco-AnyConnect-Privilege-Escalation.html
- seclists.org/fulldisclosure/2020/Apr/43
- tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ac-win-path-t…
Other links
Timeline
- Published
- Added to CISA's Known Exploited Vulnerabilities catalog
- Remediation due for U.S. federal agencies
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2026-110936 A vulnerability has been identified in Siemens Software Center (All versions < V4.0.9.8). | High Known exploited | Same weakness, CWE-427 |
| GHSA-239g-whfq-7xj9 GitPython: Repository content can impersonate the git directory, leading to arbitrary code execution | High | Same weakness, CWE-427 |
| GHSA-6hwm-xvph-95vm NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary | High | Same weakness, CWE-427 |
| GHSA-m6wp-h223-4c8g PraisonAI: Plugin Auto-Discovery Executes Arbitrary Python Files Without Verification | High | Same weakness, CWE-427 |
| PYSEC-2026-227 vLLM is an inference and serving engine for large language models (LLMs). | High | Same weakness, CWE-427 |
| GHSA-v8cx-933x-r976 OpenClaw: Fake package roots could influence memory-core artifact loading | High | Same weakness, CWE-427 |
| GHSA-x86f-5xw2-fm2r Docker: `PUT /containers/{id}/archive` executes container binary on the host | High | Same weakness, CWE-427 |
| GHSA-r39h-4c2p-3jxp OpenClaw vulnerable to arbitrary code execution via attacker-controlled setup-api.js loaded from cwd during env-key resolution | High | Same weakness, CWE-427 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor