Orchestrator Security And Vulnerabilities FAQs

Security FAQs

  1. Weak TLS:
    Customers have full control over the exact ciphers and SSL/TLS version allowed by Orchestrator. They are configured by changing the SCHANNEL settings of Windows. Robots, users, and Studio instances connected to Orchestrator and not the other way around. This means, that TLS settings configured by the customer on the Orchestrator server will enforce that security level for the overall UiPath platform.
    For convenience, here is a link to the PowerShell commands from Microsoft to change the Cipher suites. Read more on TLS.
  2. HTTPOnly:
    HTTP only flag cannot be applied universally as that would prevent the XSRF-Token from being able to be leveraged and cause a security issue. Some of the cookies don't have the HTTPOnly flag because they are used by the front-end to facilitate access to the application (ai_session, ai_user, idsrv_session).
  3. YUI – 2.9.0:
    Concerns may arise about the reported vulnerabilities (CVE-2012-5883, CVE-2012-5882, CVE-2012-5881) in the YUI 2.9.0 library when used in UiPath software. However, it is crucial to note that these vulnerabilities are related to the usage of Flash. As UiPath software does not use Flash, these vulnerabilities will not have an impact. Consequently, the security of UiPath software is not affected by these vulnerabilities.
  4. Moment.js – 2.29.2:
    Regarding the two CVEs reported for the Moment.js 2.29.2 library (CVE-2022-31129 and CVE-2022-24785), an evaluation may reveal that they are not exploitable. As a result, these vulnerabilities pose minimal, if any, risk to UiPath's products, maintaining a secure environment for product operations.
  5. Samesite:
    Same as number 1 above and samesite=none is not necessary because we use a random / un-guessable value sent with each request as both a cookie and a header value that must be validated. Also, the XSRF-Token Cookie must be read by JavaScript to provide effective cross-site request forgery protection.
  6. HTML code: Adding HTML code in the text box where we define the tenant selection in the Login phase, the following happens:

Occurance: This issue happens only when the tenant name is written like in the above example. A tenant like that cannot be created.


The application allows the usage of special characters however there are many protections in place to prevent Cross-Site-Scripting issues, such as content sanitization handled from the server-side and also by the Angular Framework which does not display HTML tags and the usage of correct Content-Type for API endpoints (i.e application/json).