Description

An issue was discovered in Softing OPC UA C++ SDK through 6.20 and Softing Secure Integration Server through 1.22. By using FileType renames, it is possible to bypass limitations on assignment of a directory path to FileDirectory OPC UA objects and a file path to File OPC UA objects.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.6",
  "pubDate": "2026-09-14T05:16:56.987Z",
  "pubdate": "2026-09-14T05:16:56.987Z",
  "executiveSummary": "This vulnerability involves an improper path validation mechanism within Softing OPC UA C++ SDK and Softing Secure Integration Server. The flaw allows an authenticated attacker to bypass intended directory and file path restrictions assigned to FileDirectory and File OPC UA objects.\nBy manipulating FileType renames, an attacker can manipulate the underlying filesystem operations, potentially accessing or modifying unauthorized files on the host system. This vulnerability constitutes a path traversal or path injection issue that circumvents security constraints implemented by the OPC UA address space management.\nThe vulnerability affects Softing OPC UA C++ SDK through version 6.20 and Softing Secure Integration Server through version 1.22. Successful exploitation requires the ability to interact with OPC UA objects, typically requiring authenticated access to the server. The impact includes unauthorized file system access, which may lead to the exposure of sensitive configuration data, modification of critical files, or potentially remote code execution depending on the server's configuration and filesystem permissions.\nOrganizations using the affected versions are at risk of unauthorized filesystem manipulation and should prioritize restricting access to OPC UA endpoints and applying security updates as provided by the vendor.",
  "technicalDetails": "The root cause of this vulnerability lies in an insufficient validation logic when handling rename operations on OPC UA FileType objects. In the OPC UA information model, File and FileDirectory objects act as abstractions for filesystem nodes. The implementation of these objects in the Softing OPC UA C++ SDK and Softing Secure Integration Server is intended to sandbox user access to specific designated directories or files.\nThe flaw manifests when an attacker performs a rename operation on an object that is mapped to a FileType. The application logic fails to properly re-validate the target path resulting from a rename operation against the original security constraints and permitted directory scopes. Specifically, the SDK fails to normalize paths or perform adequate canonicalization checks after a rename command is received via the OPC UA protocol.\nThe attack flow proceeds as follows: First, an attacker identifies an OPC UA server exposing File or FileDirectory objects that have been configured with restricted access paths. Second, the attacker utilizes standard OPC UA client functionality to issue a rename request to a FileType object. By providing crafted input that leverages directory traversal sequences (e.g., '../') or specific renames that collide with existing path validation logic, the attacker induces the application to update the object's internal file reference to an unauthorized location outside the intended sandbox.\nOnce the object's path reference is successfully overwritten to point to an unauthorized location on the host's filesystem, the attacker can use the standard Read or Write methods of the File object to interact with the target file. Because the application logic treats the renamed object as a valid, permitted resource, the underlying operating system file APIs process the request with the privileges of the OPC UA server process.\nThis mechanism allows for arbitrary file read and write capabilities, constrained only by the service account's permissions. In environments where the OPC UA server runs with elevated privileges, this could result in complete system compromise. The vulnerability is persistent, as the improper mapping remains in the server's configuration until explicitly corrected or the service is restarted. There is no indication that authentication bypass is achieved; however, the vulnerability allows an authenticated user to perform actions well beyond their intended access control policy, effectively bypassing the server's internal filesystem security boundaries."
}