Skip to content

CVE-2026-110936

A vulnerability has been identified in Siemens Software Center (All versions < V4.0.9.8).

High Known exploited
Severity
8.4 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.97%
Chance of exploitation in the next 30 days. Higher than 61.75% of scored vulnerabilities.
Known exploited
Yes
In CISA's catalog since Oct 20, 2026
Weakness
CWE-427 Uncontrolled Search Path Element
Fix
None yet
No fixed version published
Exploited in the wild. Siemens Software Center Uncontrolled Search Path Element Vulnerability (Siemens Software Center). Required action: Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines. Due for U.S. federal agencies by Nov 3, 2026.

Description

A vulnerability has been identified in Siemens Software Center (All versions < V4.0.9.8). The affected application loads dynamic-link libraries (DLLs) from an uncontrolled search path. This could allow an authenticated local attacker to place a specially crafted DLL in a directory that the application searches, leading to arbitrary code execution with the privileges of the affected application.

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 4.0 8.4

CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector
Local
Attack complexity
Low
Attack requirements
None
Privileges required
High
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Not defined
Scope
X

CVSS 3.1 6.7

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Attack vector
Local
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

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.

References

Timeline

  1. Published
  2. Added to CISA's Known Exploited Vulnerabilities catalog
  3. Last updated by the source
  4. Latest EPSS score
  5. Remediation due for U.S. federal agencies
AdvisorySeverityWhy it's related
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
GHSA-55cf-xx38-4p9p
OpenClaw: Workspace dotenv files cannot override connector endpoint hosts
Medium Same weakness, CWE-427
Is this in your code?

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