usd-2025-38 | Teamcenter 2312.8 - Cross-Site Scripting

Product: Teamcenter
Affected Version: 2312.8
Vulnerability Type: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CWE-79)
Security Risk: HIGH
Vendor: Siemens
Vendor URL: https://plm.sw.siemens.com/en-US/teamcenter/
Vendor acknowledged vulnerability: Yes
Vendor Status: Fixed
CVE Number: CVE-2026-33862
CVE Link: https://nvd.nist.gov/vuln/detail/CVE-2026-33862
Advisory ID: usd-2025-38

Description

The application does not properly encode or filter user-supplied data, which allows injection of stored JavaScript code.

The victim's browser will execute this code when they visit the site.

An XSS vulnerability can be exploited in various ways.
A common attack is to steal sensitive information from the user and secretly transmit it to the attackers.
Alternatively, attackers can perform actions with the rights of the user.

Proof of Concept

It was possible to attach files to objects, which had an XSS payload in their filename. When the overview of attachments was opened, the XSS payload would be executed.

First, a new object was created with a low privileged user.
In this case, the object type was Item Revision.
To make the payload trigger, the Files view has to be in Table mode.
In this case the filename is reflected in the Column References:

Once created, the attachments of the created object can be opened and a new attachment uploaded.
Here, a PDF file named "><img onerror="alert(document.domain)" src="x"/>.pdf was attached to the object:

After uploading the malicious attachment, the payload triggers whenever the References column is shown in the application:

If the malicious attachment was uploaded to the object, the payload triggers every time a user inspects the table view that includes the References column.
Attackers can thus execute arbitrary JavaScript code in their name and potentially steal sensitive information or even the user session.

Fix

It is recommended to treat all input on the website as potentially dangerous.

Invalid values should not be sanitized and passed to the application, but instead be rejected.
To achieve this, all input should be validated on the server-side.
Where possible, a list of allowed characters should be defined.
The more restrictive a filter can be specified, the better the protection it provides.
Allowlists are especially recommended if input values have a well defined format or a list of valid input values exists.

Additionally, all output that is dynamically generated based on user-controlled data should be encoded according to its context.
The majority of programming languages support standard procedures for encoding meta characters.
For example, PHP has the built-in function htmlspecialchars().

If the application requires users, for example, to be able to change text in an editor using HTML this type of output encoding is not possible without breaking this functionality.
In such cases, the use of client-side HTML sanitization is recommended.

Further details on how to prevent XSS vulnerabilities can be obtained in the XSS Prevention Cheat Sheet by OWASP.

References

Timeline

  • 2025-07-28: Vulnerabilities initially reported via Siemens' vulnerability handling and disclosure process.
  • 2025-08-20: Siemens report that they could reproduce the findings and are working on a fix.
  • 2026-05-12: Siemens releases a fix and publishes an advisory about the findings, see https://cert-portal.siemens.com/productcert/html/ssa-827383.html
  • 2026-07-14: This advisory is published.

Credits

This security vulnerability was identified by Dustin Born of usd AG.