CVE-2026-7858: Unauthenticated RCE in Teamwork Cloud
| Field | Value |
|---|---|
| CVE ID | CVE-2026-7858 |
| CVSS score | 9.8 (Critical) |
| Attack vector | Remote |
| Auth required | None |
| Patch status | Vendor advisory exists; exact fixed build is not conclusively confirmed from accessible source text. A related vendor document indicates 2026x Hot Fix 2 includes vulnerability fixes, but direct CVE-to-build mapping is not fully exposed in retrieved content. |
TL;DR - Critical deserialization flaw can lead to unauthenticated remote code execution. - Affects Teamwork Cloud and Magic Collaboration Studio in release families 2022x through 2026x. - Exploitation and public PoC are not confirmed, but internet-exposed servers should be treated as urgent patch candidates.
What happened and why this matters
CVE-2026-7858 is a critical deserialization of untrusted data vulnerability affecting Dassault Systèmes collaboration products Teamwork Cloud and Magic Collaboration Studio. This issue affects Teamwork Cloud from No Magic Release 2022x through No Magic Release 2026x and Magic Collaboration Studio from CATIA Magic Release 2022x through CATIA Magic Release 2026x. The impact is severe because the flaw can lead to unauthenticated remote code execution.
For defenders, the important point is not just that this is an RCE, but that it is described as both remote and unauthenticated. That combination typically means the vulnerable service could be attacked before login, through exposed application interfaces or protocols, without valid user credentials. In practical terms, if these products are reachable from untrusted networks, the risk profile is significantly higher than for post-authentication bugs or local privilege escalation issues.
The advisory data currently available is incomplete in a few places. The CVSS base score of 9.8 is confirmed, but the full vector string was not exposed in the returned NVD output used here. Likewise, a vendor advisory exists, but the exact fixed build number for CVE-2026-7858 was not conclusively extractable from the accessible source text. When data is incomplete like this, defenders should avoid assuming the issue is less serious. The safer assumption is that any deployment in the stated affected release families is potentially vulnerable until explicitly proven otherwise by vendor documentation or a verified installed hotfix.
Affected products and versions
The affected version information that is currently confirmed is broad but still actionable. Based on the NVD description, the impacted products and release ranges are:
| Product | Confirmed affected versions |
|---|---|
| Teamwork Cloud | No Magic Release 2022x through No Magic Release 2026x |
| Magic Collaboration Studio | CATIA Magic Release 2022x through CATIA Magic Release 2026x |
That wording matters because it identifies release families, not exact point builds, service packs, or hotfix levels. In many enterprise environments, administrators may know they run “2024x” or “2026x” but may not immediately know which update or hotfix is installed. If your asset inventory only tracks product family and not full build metadata, you should initially classify all systems in those release families as suspect and then validate the exact installed version.
A related vendor documentation page for 2026x Version News states that 2026x Hot Fix 2, released on March 20, 2026, includes vulnerability fixes in modeling tools, plugins, and server products for the CATIA Magic and No Magic portfolios. However, based on the retrieved source text available here, that page does not conclusively expose an explicit statement that CVE-2026-7858 is fixed by 2026x Hot Fix 2, nor does it clearly identify whether older supported branches received backported fixes. Because of that, the exact fixed version number is unknown from the current evidence.
If you are running 2022x, 2024x, or 2026x branches, the prudent operational assumption is that your environment may be affected unless you have a vendor-confirmed remediation bulletin or have already deployed the latest security hotfix validated against this CVE. This is especially true for externally accessible Teamwork Cloud infrastructure or collaboration services integrated into broader engineering environments.
Exploitation status, PoC availability, and urgency
At the time of writing, exploitation in the wild is not confirmed from the available sources. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog, and no source retrieved for this article confirmed active exploitation. That is useful context, but it should not be interpreted as a sign the issue is low priority. Many critical server-side vulnerabilities are exploited before authoritative public confirmation appears in KEV or major incident reports.
Likewise, a public proof of concept is not confirmed from the gathered references. No GitHub proof-of-concept, exploit repository, or vendor-linked exploit reference was confirmed in the source set used here. Again, that reduces noise but does not materially lower risk for exposed systems. Deserialization vulnerabilities are often attractive to attackers because they can be highly reliable once protocol details are understood, and exploit development may remain private even when a public PoC is absent.
The practical urgency remains high because the technical description itself is enough to justify action. A critical score of 9.8, remote reachability, no authentication requirement, and code execution on a server product create a strong remediation case regardless of current exploitation visibility. If your organization hosts Teamwork Cloud or Magic Collaboration Studio on networks reachable by contractors, partners, or the public internet, you should prioritize containment and patch validation now rather than wait for exploitation confirmation.
What defenders should do next
First, identify where these products are deployed and whether those instances are exposed beyond tightly controlled internal network segments. Engineering collaboration platforms are sometimes internet-facing by design, especially in distributed product development environments. Inventory not just production servers, but also test, staging, partner access nodes, and legacy systems that may still be active. Because the affected version ranges are broad, your first response should be asset discovery and exposure reduction.
Second, confirm exact versions and hotfix levels. If you cannot conclusively determine that a deployment is on a vendor-confirmed fixed version, treat it as vulnerable. Since the currently accessible advisory text does not clearly map the CVE to a specific fixed build, defenders should coordinate with vendor support or internal application owners to validate remediation status. Where immediate upgrade confirmation is not possible, restrict access at the network level, place the service behind VPN or IP allowlists, and monitor aggressively for unexpected crashes, Java process anomalies, or suspicious inbound requests to collaboration service endpoints.
Third, prepare for potential post-exploitation review. Because this is an RCE issue, successful exploitation could allow an attacker to run code in the server context, deploy web shells or second-stage payloads, steal repository data, or pivot deeper into engineering and identity systems. If you find signs of suspicious access to the application before patching, plan to collect process execution data, JVM logs, authentication records, reverse proxy logs, and outbound connection history from the affected host.
Risk assessment for SMBs and enterprise teams
For SMBs running a small engineering collaboration footprint, the main challenge is usually incomplete inventory and slower patch validation. These teams may not have deep internal knowledge of No Magic or CATIA deployment details, so the fastest path is often to identify the server owners, isolate exposure, and engage vendor support to validate the fixed version. If the platform is internet-facing and business-critical, put compensating access controls in place the same day.
For larger enterprises, the risk expands because Teamwork Cloud and related collaboration tooling may sit adjacent to design repositories, identity integrations, and sensitive intellectual property. An unauthenticated RCE on such a platform is not just an application compromise risk; it can become an entry point into engineering networks or a data theft path targeting product design information. Even without confirmed exploitation in the wild, the blast radius can justify emergency change handling.
Bottom line
CVE-2026-7858 is a critical unauthenticated RCE affecting Teamwork Cloud No Magic Release 2022x through 2026x and Magic Collaboration Studio CATIA Magic Release 2022x through 2026x. Exploitation in the wild is not confirmed, a public PoC is not confirmed, and CISA KEV does not currently list the CVE. Still, the combination of unauthenticated access and server-side code execution is enough to make this an urgent remediation issue.
The one caveat defenders need to handle carefully is patch specificity. A vendor advisory exists, and a related document indicates 2026x Hot Fix 2 contains vulnerability fixes for relevant server products, but the currently accessible source text does not conclusively confirm the exact fixed version number for this CVE. Until that is verified, assume affected release families remain at risk, reduce exposure, monitor for suspicious behavior, and validate the vendor-approved remediation path as a priority.
For further insights on related security topics, you can explore our articles on what is TLS and software supply chain attacks.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection guidance
Detection for deserialization-driven RCE in Java-backed server software is rarely a single perfect signature. In most environments, the best approach combines version-based exposure identification, web or reverse proxy telemetry, JVM error patterns, and endpoint telemetry from the host running the service. If you do not yet have a vendor-provided indicator set for CVE-2026-7858, look for suspicious requests immediately preceding Java exceptions, service instability, or child process execution from the application server.
You should also look for behavior that is unusual for a collaboration platform: unexpected shell launches, outbound network connections from the server to unfamiliar destinations, archive downloads, or encoded command lines. If the platform normally runs as a dedicated service account, any process tree branching into /bin/sh, bash, cmd.exe, powershell.exe, curl, wget, or scripting runtimes deserves immediate review. Because the exact vulnerable endpoint and payload structure are not publicly confirmed in the available sources, detection must stay behavior-based rather than overly narrow.
Technical Notes
A practical starting point is to search reverse proxy, application, and endpoint logs for suspicious HTTP requests followed by Java errors or unexpected process creation:
# Example suspicious indicators to hunt for
- Repeated POST requests to Teamwork Cloud or collaboration endpoints from unfamiliar IPs
- HTTP 500 responses followed by service restart messages
- Java deserialization-related exceptions such as:
"java.io.InvalidClassException"
"java.io.StreamCorruptedException"
"java.lang.ClassCastException"
"Cannot deserialize"
- Child process execution spawned by the Java service account
Example Splunk query for web and process telemetry correlation:
(index=proxy OR index=web) (dest_host="teamwork-cloud*" OR url="*teamwork*" OR url="*collaboration*")
| eval suspicious=if(method="POST" AND (status=500 OR like(uri,"%api%") OR like(user_agent,"%python%") OR like(user_agent,"%curl%")),1,0)
| search suspicious=1
| join host [ search index=edr parent_process_name="java" (process_name="sh" OR process_name="bash" OR process_name="cmd.exe" OR process_name="powershell.exe" OR process_name="curl" OR process_name="wget") ]
| table _time src_ip host method uri status user_agent process_name parent_process_name command_line
Example Sigma-style logic for endpoint hunting:
title: Java Server Spawning Shell on Collaboration Host
logsource:
category: process_creation
detection:
selection:
ParentImage|contains:
- 'java'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '/bin/sh'
- '/bin/bash'
- '/usr/bin/curl'
- '/usr/bin/wget'
condition: selection
level: high
If you have only network telemetry, alert on external connections to the collaboration server from untrusted IP space where the request pattern is atypical for normal users, especially bursts of POST requests, malformed payloads, or follow-on callbacks from the server to external hosts. Without a confirmed exploit signature, defenders should emphasize anomaly detection and incident triage speed.
Mitigation and patching
The safest mitigation is to move affected systems onto a vendor-confirmed fixed release as soon as that information is validated in your environment. What is currently known is that a vendor security advisory exists and a related 2026x Hot Fix 2 page states that vulnerability fixes were included for CATIA Magic and No Magic server products. What is not known from the accessible text here is whether 2026x Hot Fix 2 specifically fixes CVE-2026-7858, whether a later hotfix supersedes it, or whether 2022x/2024x branches received their own remediations. That uncertainty should drive defenders to verify directly with Dassault Systèmes support or official release notes before closing the ticket.
Where immediate patching is not feasible, the priority workaround is exposure reduction. Remove public internet access where possible, require VPN access, restrict source IPs to trusted administrative or engineering networks, and place the service behind a reverse proxy or WAF if one is already in use. These measures do not eliminate the vulnerability, but they can materially reduce attack opportunity while you validate and deploy a fix. Because the vulnerability is unauthenticated, perimeter access control is one of the few meaningful short-term compensating controls.
Technical Notes
Because the exact packaged upgrade workflow varies by deployment model, defenders should use vendor-approved procedures. If your environment uses Linux service packaging, a controlled maintenance workflow may look like this:
# Example: document current installed version before change
systemctl status teamworkcloud
rpm -qa | egrep -i 'teamwork|nomagic|magic'
dpkg -l | egrep -i 'teamwork|nomagic|magic'
# Back up application and config paths before patching
tar -czf /var/backups/teamworkcloud-$(date +%F).tgz /opt/teamworkcloud /etc/teamworkcloud
# Stop service before applying vendor hotfix package
sudo systemctl stop teamworkcloud
If the vendor supplied a hotfix archive or installer for 2026x, the operational control you need is not the exact shell syntax from an unverified blog, but a repeatable and documented upgrade step. A generic workflow might be:
# Example placeholder workflow only; replace with vendor-documented installer path
sudo ./install.sh --target /opt/teamworkcloud
sudo systemctl start teamworkcloud
sudo systemctl status teamworkcloud
For Windows-hosted deployments, capture installed version details before and after remediation and restart services in a maintenance window:
Get-Service | Where-Object {$_.Name -match "teamwork|magic"}
Get-ChildItem "C:\Program Files" | Where-Object {$_.Name -match "Teamwork|Magic|No Magic"}
If you cannot immediately upgrade, implement a network workaround now:
# Example temporary Linux firewall restriction
sudo iptables -A INPUT -p tcp --dport 8111 -s <trusted_admin_subnet> -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8111 -j DROP
Replace ports and paths with values used in your environment. The key requirement is to apply a specific, documented control: verified hotfix installation or explicit network restriction. “Apply the patch” is not enough unless you can prove which patch contains the fix.
References
- Dassault Systèmes Trust Center security advisory for CVE-2026-7858: https://www.3ds.com/trust-center/security/security-advisories/cve-2026-7858
- Teamwork Cloud product page: https://www.3ds.com/products/catia/no-magic/teamwork-cloud
- No Magic collaboration solutions product page: https://www.3ds.com/products/catia/no-magic/collaboration
- 2026x Version News page: https://docs.nomagic.com/VN/2026x/2026x-version-news-272747012.html
- CISA Known Exploited Vulnerabilities catalog lookup for CVE-2026-7858: not listed as of 2026-06-01