Polarion Stored XSS CVE-2025-40587: Patch to 2404.5 or 2410.2 Now

Siemens has confirmed a stored cross‑site scripting (XSS) vulnerability in Polarion that affects multiple maintenance branches and must be patched: Polarion V2404 releases prior to V2404.5 and Polarion V2410 releases prior to V2410.2 are vulnerable to CVE‑2025‑40587, and Siemens’ ProductCERT published advisory SSA‑035571 (February 10, 2026) with fixed release thresholds and remediation guidance. ([cert-portal.siemenortal.siemens.com/productcert/html/ssa-035571.html)

Background / Overview​

Polarion is Siemens’ application lifecycle management platform used by engineering teams across industries, including critical infrastructure sectors such as energy and manufacturing. On February 10, 2026, Siemens ProductCERT published SSA‑035571 describing a vulnerability (tracked as CVE‑2025‑40587) that allows an authenticated user to inject arbitrary JavaScript into document titles, which can later execute in the browsers of other users who view those documents. Siemens recommends upgrading affected product lines to the fixed versions or later to mitigate the issue.
Independent vulnerability trackers and vulnerability intelligence firms quickly mirrored Siemens’ advisory (OpenCVE, Tenable, CVE aggregators), confirming the affected versions, the stored XSS root cause (CWE‑79), and the CVSS ratings that Siemens published. These sources uniformly recommend updating to the vendor‑supplied fixes.

---

What the advisory actually says (concise technical summary)​

• Vulnerability: Stored cross‑site scripting (XSS) (CWE‑79) that permits attacker‑controlled JavaScript to be embedded in document titles.
• Affected versions:
• Polarion V2404 — all versions earlier than V2404.5.
• Polarion V2410 — all versions earlier than V2410.2.
• CVE identifier: CVE‑2025‑40587.
• Severity: CVSSv3.1 base score 7.6 (High); CVSSv4 base score 6.2 (Medium) (vendor scores reported in the advisory).
• Exploit prerequisites: an attacker must be authenticated (low privilege is sufficient) to create the malicious document title; subsequent victims only need to view the document to trigger script execution.

These are core facts system owners and SOC teams must internalize immediately.

---

Why this matters: risk and real‑world impact​

Stored XSS in a collaboration or ALM tool is a potent vector for targeted compromise inside organizations.

• Session capture and impersonation: JavaScript executed in another user’s browser can exfiltrate session tokens, cookies, or other credentials stored in the browser context and send them to an attacker‑controlled receiver, enabling account takeover.
• Privilege escalation via workflow abuse: Polarion is used by engineering and product teams that frequently hold elevated project privileges or access to build artifacts, test plans, and integrations with CI/CD pipelines; hijacked sessions may be used to manipulate artifacts or trigger unsafe workflows.
• Supply‑chain and build compromise: If an attacker can use stolen credentials or an elevated session to modify tracked requirements, artifacts, or integration endpoints, they can create a stealthy path into build systems or release pipelines.
• Operational disruption: In industrial and critical‑infrastructure contexts, engineering ALM tools tie into operational workflows and approvals. A successful browser‑based compromise could materially disrupt engineering operations or allow the injection of misleading artifacts into release processes.

Because the vulnerability is stored (persistent) and triggers simply by viewing a crafted document title, it lends itself to low‑noise social engineering (e.g., sending a link to a familiar document with an enticing title) and can be weaponized inside trusted corporate email/chat channels.
Multiple vulnerability trackers and Siemens’ own advisory stress the network‑accessible nature of the issue when Polarion’s web interface is reachable by attackers, and the low attack complexity when an authenticated account is available.

---

Affected products and safe upgrade thresholds​

Siemens’ published remediation thresholds are explicit and must be followed exactly when triaging assets:

• Polarion V2404: update to V2404.5 or later.
• Polarion V2410: update to V2410.2 or later.

Operators running Polarion maintenance branches earlier than those fixed releases should plan immediate upgrades. Where direct upgrading is not immediately feasible (long maintenance windows, regulatory controls), strong compensating controls must be put in place while scheduling the patch.
Independent vulnerability aggregators corroborate Siemens’ version details and CVE metadata; cross‑checking these external listings is a best practice when triaging enterprise assets.

---

Technical analysis: how the vulnerability works​

1. Root cause​

Polarion failed to properly sanitize or encode user input used in the rendering context of document titles. The web UI renders titles without neutralizing special HTML/JavaScript elements, enabling attackers with write access to store script payloads that will execute in other users’ browsers when the title is rendered. This is textbook stored XSS behavior (CWE‑79).

2. Attack flow (conceptual)​

• Attacker obtains an authenticated account (phishing, weak password, shared account, or legitimate low‑privileged account).
• Attacker creates or edits a document title to include a crafted JavaScript payload.
• Another user (victim) views the document or a list view that displays the title—browser renders the malicious payload.
• Payload executes in victim’s browser under the site origin, enabling token theft, CSRF, UI‑based actions, or chain‑exploitation to other features.

This flow is simple and resilient; any user who opens or previews the document may be impacted.

3. Why authentication matters but isn’t a guarantee​

While the initial creation of the malicious title requires authentication (low privilege), many enterprise environments reuse low‑privilege accounts for routine tasks, and attackers have demonstrated multiple routes to obtain those credentials. Once persistent JavaScript is stored, the attacker no longer needs to be online to trigger the payload—any viewer is at risk.

---

Detection, hunting, and immediate mitigations​

Apply a layered approach: patch where possible; detect and contain where patching will take time.

• Immediate detection candidates:
• Web server logs and application audit trails showing document title fields containing suspicious characters, tags, or JavaScript snippets. Search for ipt", "javascript:", "onerror=", "onload=", and commonly obfuscated payload markers.
• Recent document creation/edit events by accounts that don’t normally create many documents. Look for anomalous volumes or time patterns.
• Browser‑side telemetry on engineering workstations—unexpected outbound connections from browsers to domains that are not company‑approved.
• Hunting steps:
• Export recent document metadata and scan title fields with regex to find HTML or script markers.
• Cross‑reference authors of suspect titles with authentication logs and device posture events (MFA status, remote IPs, VPN sessions).
• If you have a web application firewall (WAF) with request body inspection, add a temporary rule tontain JavaScript or HTML tags in title parameters.
• Short‑term mitigations (while patching):
• Restrict Polarion’s network exposure: ensure that the Polarion web interface is reachable only from trusted subnets and administrative workstations. Place it behind an access‑controlled reverse proxy or VPN. Minimize Internet exposure.
• Enforce stronger authentication controls: require multi‑factor authentication (MFA) for all Polarion accounts, tighten password policies, and reduce shared or service accounts.
• Harden browsers on engineering workstations: apply extension control, disable auto‑execution helpers, and employ endpoint protections that can detect script behavior and abnormal data exfiltration.
• Temporarily disable or restrict document creation/edit privileges to a small set of trusted accounts until the upgrade can be applied.

These steps align with the general ICS/OT mitigations recommended by national authorities for vendor‑disclosed issues: isolate control system networks, place devices behind firewalls, and limit remote access.

---

Recommended remediation plan (operational checklist)​

• Inventory & prioritize
• 1.1. Identify all Polarion instances (V2404, V2410, and any other maintenance branches).
• 1.2. Prioritize instances exposed to broader corporate or internet‑facing networks and those used by critical engineering teams.
• Patch & upgrade (primary remediation)
• 2.1. Plan maintenance windows and test upgrades to V2404.5 or later and V2410.2 or later, respectively. Apply vendor release notes and follow Siemens’ upgrade instructions.
• 2.2. Validate application functionality in staging before rolling to production.
• Containment for unpatched systems
• 3.1. Restrict access via VPN or allowlist only to required IP ranges.
• 3.2. Implement WAF rules to detect/neutralize script tags in title fields, and log violations for forensic review.
• 3.3. Reduce document‑creation privileges to trusted roles.
• Detection & response
  document titles across your Polarion instances for injected content; remove or sanitize any suspicious titles.
• 4.2. Rotate potentially compromised credentials and require MFA.
• 4.3. Monitor for unusual outbound connections from browsers or anomalous session activities that could indicate token theft.
• Post‑remediation controls
• 5.1. Reassess RBAC and audit logging for Polarion projects.
• 5.2. Integrate Polarion into vulnerability scanning and regular patch cycles.
• 5.3. Run a short tabletop to simulate an XSS compromise and validate detection/response procedures.

---

Practical considerations for industrial and critical‑infrastructure operators​

Operators in OT and ICS environments face special tradeoffs: maintenance windows are constrained and upgrades may require long validation cycles. For these teams:

• Treat the Polarion vulnerability as a high business‑impact issue if Polarion is connected to release pipelines or change‑management systems affecting production controllers. The adversary model for OT is different: a browser compromise can be a stepping stone to operational manipulation.
• Consider compensating controls when immediate patching is impossible: network segmentation, jump hosts for engineering access, enforced MFA, and strict RBAC.
• Coordinate change control with engineering teams and document all compensating measures. Regulatory and compliance contexts demand auditable decisions if patches are deferred.

---

Vendor response and disclosure timeline (what happened and why it matters)​

• Siemens ProductCERT published SSA‑035571 on February 10, 2026, assigning CVE‑2025‑40587 and documenting fixed versions (V2404.5 and V2410.2). The advisory credits Thales Digital Factory for responsible reporting.
• National authorities and vulnerability trackers mirrored the advisory the same week; public vulnerability databases (Tenable, OpenCVE, CVEDetails) quickly listed the CVE and scored it consistent with Siemens’ CVSS values. This rapid cross‑publication accelerates awareness but also of patching.

Rapid public disclosure is a double‑edged sword: it informs defenders but also makes exploit details more discoverable. For organizations, the takeaway is clear—assume discoverability and prioritize remediation.

---

Strengths in Siemens’ advisory — and areas to watch​

What Siemens did well:

• Clear version thresholds and remediations: fixed versions are explicit, reducing ambiguity when triaging assets.
• Attribution and CVE assignment: the advisory gives a concise technical description tied to a CVE, enabling standard‑tooling consumption and automation.

What remains a concern:

• Exploitability timeline: stored XSS often yields quick exploit proofs, and the presence of an authenticated prerequisite does not materially raise attacker capability in many corporate contexts. Organizations with lax account hygiene remain high risk.
• **Oper: OT environments may not be able to upgrade immediately. Siemens and national guidance emphasize compensating controls, but these require clear implementation and auditability in regulated environments.

---

Detection playbook snippets (quick checks your SOC can run now)​

• Query Polarion metadata export for titles containing "<", ">", "script", "onerror", "onload", "javascript:" and similar markers. Remove or sanitize matches.
• Configure your WAF to log any POST/PUT requests that include suspicious title payloads and block requests that carry obvious script tags.
• On Windows engineering workstations: enable browser telemetry to flag cross‑origin requests from in‑scope destinations to unknown third‑party endpoints. Correlate with recent Polarion document viewers.
• If you find evidence of exploitation (unexpected outbound connections or token theft), immediately rotate session keys, force full session logout for all Polarion users, and reset credentials for accounts that authored suspect content.

---

Final analysis and recommended priorities​

• Patch first: If you operate Polarion V2404 < V2404.5 or V2410 < V2410.2, plan and apply the vendor upgrades as the primary corrective action. Siemens has provided explicit fixed release numbers for these branches.
• Reduce exposure: Isolate Polarion from public networks and enforce strict access controls; assume an attacker can obtain low‑privilege credentials.
• Hunt and remediate existing payloads: Search stored document titles for malicious content and sanitize or remove any confirmed injections.
• Harden endpoint and session management: Require MFA, monitor browser telemetry, and be ready to invalidate sessions and rotate credentials if you detect anomalous activity.
• Document compensating measures: For OT systems that cannot be patched immediately, document compensating controls, their duration, and the risk acceptance rationale for auditors and regulators.

---

Stored XSS in collaboration and ALM platforms is a serious operational risk precisely because the attack surface spans everyday users and routine workflows. Siemens’ CVE‑2025‑40587 advisory gives a clear remediation path—update Polarion to the fixed versions—but effective mitigation requires coordinated action across patch management, access control, and detection capabilities. Prioritize upgrades, tighten access, and hunt proactively for malicious titles: the window for safe, controlled remediation is limited once a vulnerability like this is public.
Conclusion: treat this as an urgent patching and detection priority for any organization running affected Polarion branches, and apply Siemens’ fixed releases or robust compensating controls as soon as operationally possible.

---

Source: CISA Siemens Polarion | CISA