Privacy Policy and Cookies

By continuing to use our site, you agree to our Privacy Policy and our use of cookies to understand how you use our site, and to improve your experience. Learn More.
I Agree.
Home  >  Uncategorized

Addressing a Rare SmartClient Server Vulnerability (CVSS 9.8)

Last modified date

All known affected licensees were already notified 3 weeks ago; however, if you are just now learning of this:

TL;DR

  • Severity: CVSS 9.8 (Critical) – CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
  • Affected: SmartClient Server (also used by SmartGWT) when SQLDataSource is in use
    • 13.0+: logged-in attacker could blind-execute arbitrary SQL (potential data corruption, downtime, possible exfiltration with schema knowledge)
    • Older releases: in addition to the above, attacker could potentially execute arbitrary programs on the host
  • Fixed: Patched builds have been available for weeks at smartclient.com/builds.  As usual, grab the latest even though the exploit was corrected a while back.
  • What to do: Update to the latest patched build immediately, especially if your app is exposed to untrusted users.
  • Disclosure cadence: Licensees notified first; broader registered users notified two weeks later; public technical details posted now.

Who should act

If you deploy SmartClient Server / SmartGWT with SQLDataSource, assume you are impacted and patch now. This applies regardless of whether you use Custom Querying-this issue is deeper than that surface area.

Patched builds:

Note on legacy releases:
Versions 11.1 and earlier reached end-of-life over 3 years ago. Custom backports may be possible via Hourly Support:

Timeline & disclosure

  • Day 0: Vulnerability confirmed; trivial, targeted fix implemented and tested within hours.
  • Day 1: Initial advisory sent to all known licensees, including severity (CVSS 9.8) and upgrade instructions.
  • +14 days: Second advisory sent to all registered smartclient.com accounts to catch any users not in the licensee records.
  • Now: Public technical explanation (below) posted, with exploitation-enabling details deliberately omitted.

This aligns with standard responsible disclosure: notify affected users privately first, allow a patching window, then share technical detail publicly.

Impact summary (non-exploit detail)

  • 13.0+ with SQLDataSource: a remote, authenticated attacker could issue blind SQL operations. This can cause downtime (e.g., dropped/corrupted data), data integrity issues, and potential data exfiltration only if the attacker already knows your schema well enough to extract signals.
  • Older versions with SQLDataSource: all of the above, plus a path that could lead to arbitrary program execution on the host.

We have no evidence of real-world compromises resulting in anything beyond minor service disruption. No confirmed data loss, no confirmed remote control of servers.

Technical overview (high level)

We’re sharing enough depth to explain root cause and lessons learned, without including PoC or step-by-step exploit content.

There is a part of the standard SmartClient server request from the client called operationConfig. It contains things like startRow/endRow and sortBy.

  • Historical behavior (2005): server code merged operationConfig into the server-side DSRequest object. At the time, this was not a security issue and provided a convenient way for client code to add custom attributes that the server could read to adjust behavior.
  • Refactor (circa 2019): the server flow was refactored for better caching and resource cleanup. Certain attributes (like customSQL) started being cached on DSRequest.
  • Interaction effect: the combination meant a client could inject properties into DSRequest that overrode cached attributes, unintentionally controlling sensitive server behavior.
  • A third factor involved a timing change in when DSRequests were set up on the server, such that operationConfig could now overwrite developer-specified settings, instead of being clobbered by them.  

So, three independent shifts lined up to create the exploit path.

The fix: we constrained operationConfig to a tight allowlist of safe properties (this already existed on the client side); we ensured no sensitive server-only attributes can be influenced by client-provided state.

Why this is rare for us

Isomorphic was founded by people with extensive backgrounds in network security, which is why this is only the second vulnerability ever found in SmartClient Server code (excluding third-party dependencies) in nearly 25 years. 

The previous one was a minor information disclosure, so this is basically the first substantive security issue.  That’s quite the track record, if we say so ourselves!

In addition, three distinct evolutions in behavior had to combine to produce this issue.  This was not a matter of forgetting to think about security, but rather of thinking carefully about security at 3 different times, getting it right each time, and then missing an extremely subtle interaction.

Here’s hoping we have another very, very long run with no exploits.

What to do next

  1. Upgrade to the latest patched build: https://www.smartclient.com/builds
  2. Validate that all nodes/containers/images in your deployment are updated.
  3. Review logs around upgrade time for anomalous SQL activity or unexpected server-side execution (if you’re on older versions)

If you’re on an EOL release and cannot upgrade immediately, contact us; we can discuss custom backports via Hourly Support.

Credits

A huge thank you to Marcos Garcia Chillon (EUMETSAT), who reported the flaw and demonstrated a working exploit. Marcos, the entire SmartClient / SmartGWT community owes you one.

We are sending Marcos a very nice gift as a thank you.

Closing

We moved fast, communicated privately first, and are now sharing the technical picture responsibly. If you have questions about your specific deployment or need help validating your patch, reach out to Support.

– Isomorphic Software Support

Related Posts