CVE-2022-22047
Windows Client Server Run-time Subsystem (CSRSS) Elevation of Privilege Vulnerability
High
Known exploited
- Severity
- 7.8 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 18.77%
- Chance of exploitation in the next 30 days. Higher than 97.28% of scored vulnerabilities.
- Known exploited
- Yes
- In CISA's catalog since Jul 12, 2022
- Fix
- None yet
- No fixed version published
Exploited in the wild. Microsoft Windows Client Server Runtime Subsystem (CSRSS) Privilege Escalation Vulnerability (Microsoft Windows). Required action: Apply updates per vendor instructions. Due for U.S. federal agencies by Aug 2, 2022.
Description
Windows Client Server Run-time Subsystem (CSRSS) Elevation of Privilege Vulnerability
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 7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-426: Untrusted Search Path
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
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.
- 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 it, while execl() and execv() require a full path.
CWE-426: Untrusted Search Path
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
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.
- 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 it, while execl() and execv() require a full path.
References
Advisories
Other links
Timeline
- Added to CISA's Known Exploited Vulnerabilities catalog
- Published
- Remediation due for U.S. federal agencies
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-6hwm-xvph-95vm NLTK: Uncontrolled search path when invoking the Graphviz 'dot' binary | High | Same weakness, CWE-426 |
| GHSA-hxmv-c4g6-5fqc PraisonAI workflow include bypasses tools.py autoload opt-in and executes included recipe code | High | Same weakness, CWE-426 |
| GHSA-rx78-29qr-5hq8 OpenClaw: Workspace-derived service PATH could influence trash command selection | High | Same weakness, CWE-426 |
| GHSA-wc84-j36w-pw4x OpenClaw: Workspace .env STATE_DIRECTORY could influence bundled runtime dependency roots | High | Same weakness, CWE-426 |
| GHSA-24vr-rprv-67rf OpenClaw: Workspace .env npm_execpath could influence bundled runtime dependency install | High | Same weakness, CWE-426 |
| GHSA-fq9j-vw4w-fr6v OpenClaw: Workspace .env CLOUDSDK_PYTHON could influence Gmail setup gcloud execution | High | Same weakness, CWE-426 |
| GHSA-8wg3-5mcm-fjq8 OpenClaw: Workspace .env could override Homebrew executable selection for skill install flows | High | Same weakness, CWE-426 |
| GHSA-mh5c-xrmh-m794 uutils coreutils has an Untrusted Search Path | High | Same weakness, CWE-426 |
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