Announcement

**Isomorphic** · 28 Jul 2025, 10:43

SmartClient 12.0 requires commons-lang2.6 and is not vulnerable to any of the CVEs related to commons-lang. So the remedy is to put the .jar back - you weren't vulnerable in the first place.

SmartClient 15.0, not due out for a while, does use commons-lang3.

**rameshprakash** · 29 Jul 2025, 08:51

Please check this - https://mvnrepository.com/artifact/c...mmons-lang/2.6
- Direct vulnerabilities:CVE-2025-48924

**Isomorphic** · 29 Jul 2025, 09:27

Sorry, we don't know why you posted this.

There are CVEs against commons-lang 2.6 and none of them cause vulnerabilities in SmartClient.

Is there something else you need?

**rameshprakash** · 4 Aug 2025, 04:58

I am surprised by the response I have received, especially given our long-standing relationship with SmartClient. We have been licensed users and using SmartClient for over 10 years. Shouldn't we have rights to post this ?

As such, I expect a higher level of engagement when raising legitimate security concerns.

https://app.eu.snyk.io/org/fems-exca...SLANG-10734077 or (Please refer the ScreenShot )

Let me be absolutely clear:

Snyk, a widely trusted security tool, has flagged high-severity CVEs tied to commons-lang 2.6.
I’ve already provided the Maven link and outlined the vulnerabilities.
Your statement that “none of them cause vulnerabilities in SmartClient” is not acceptable without technical justification. If SmartClient is bundling or depending on this library, you must explain exactly how these CVEs are mitigated or irrelevant in your context.

This is a security issue, not a theoretical discussion. If you cannot provide a clear and detailed explanation, I will escalate this matter through the appropriate channels.

Please let me know if you need any additional information from us.

Attached Files

**Isomorphic** · 4 Aug 2025, 09:19

The vulnerability mentioned in the CVE is limited to the method ClassUtils.getClass(). Since the SmartClient server framework doesn't call that method, it is not affected.

**rameshprakash** · 4 Aug 2025, 09:33

We are not using the SmartClient server in our architecture. Instead, we are deploying our application on standard application servers such as WildFly or WebLogic. This application server is calling the ClassUtils.getClass()

**Isomorphic** · 4 Aug 2025, 09:52

Let us also be very clear: you are taking the output of basic security tools, and then, without doing security analysis of any kind, demanding that we explain to you the output of your tools.

When you use Snyk in this very simple mode (basically classpath search w/CVE lookup), you are at the starting point of security analysis - you are several steps away from when it would be appropriate to contact a vendor.

Specifically, it would be trivial for you to scan the SmartClient Server code and discover that we don't call the affected method, so SmartClient cannot possibly be vulnerable.

If you don't know how to do this kind of thing, any AI can teach you in about 10 minutes.

As far as support, you certainly have the right to post here - no one is stopping you - but you explicitly declined to purchase any kind of support package, instead choosing to rely on Community Support, not on Isomorphic. To now demand a higher level of support is inappropriate.

So if you wish to "escalate", you can - by buying support.

In the meantime please refrain from posting bogus security vulnerabilities and demanding explanations. This wastes the limited resources we have for free Community Support.

**Isomorphic** · 4 Aug 2025, 10:00

Looks like we have crossed messages.

Based on your organization's other posts, yes you are using the SmarClient Server. The SmartClient Server is a set of .jars deployed into servlet engines like Tomcat or Wildfly.

If you are now saying that you see Wildfly or Weblogic calling the possibly insecure method, why are you demanding an explanation from us? If Wildfly or Weblogic has a security flaw, we can't correct it.

**rameshprakash** · 6 Aug 2025, 06:14

I'm having difficulty understanding the tone of your message. If you're feeling frustrated, it might be helpful to take a short break.

The concern raised was regarding the vulnerability identified by SNYK in the commons-lang 2.6 library. While we attempted to upgrade to commons-lang3.jar and exclude commons-lang 2.6, we encountered a runtime error in the ISOMORPHIC dsRequest.execute() method.

I assume you're able to interpret the stack trace below and understand the relationship between commons-lang 2.6 and Isomorphic.

13:20:24,704 INFO [com.isomorphic.datasource.DSRequest] (default task-1) Executing dropDownDD.fetch
13:20:24,705 WARN [com.isomorphic.servlet.RequestContext] (default task-1) dsRequest.execute() failed: : java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils
at com.isomorphic.datasource.DeclarativeSecurity.dsRequestPassesSecurityChecks(DeclarativeSecurity.java:191)
at com.isomorphic.datasource.DSRequest.passesSecurityChecks(DSRequest.java:4705)
at com.isomorphic.datasource.DSRequest.passesSecurityChecks(DSRequest.java:4701)
at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:2654)
at com.isomorphic.servlet.IDACall.handleDSRequest(IDACall.java:226)
at com.isomorphic.servlet.IDACall.processRPCTransaction(IDACall.java:183)

I’d like to clarify that none of my previous comments were intended to seek an explanation. Given your experience in the software industry, I trust you're familiar with platforms like WebLogic and WildFly.

Since we're using ISOMORPHIC, our expectation is straightforward: if ISOMORPHIC has dependency on a vulnerable library, such as commons-lang 2.6, it should be either mitigated or addressed appropriately. These concerns should be handled and responded constructively, rather than defensively.

I hope you take this feedback positively and respond accordingly.

**Isomorphic** · 6 Aug 2025, 10:34

I’d like to clarify that none of my previous comments were intended to seek an explanation.

This is not true, you not only demanded an explanation, you threatened to "escalate" if you didn't get one:

Your statement that “none of them cause vulnerabilities in SmartClient” is not acceptable without technical justification. If SmartClient is bundling or depending on this library, you must explain exactly how these CVEs are mitigated or irrelevant in your context.

This is a security issue, not a theoretical discussion. If you cannot provide a clear and detailed explanation, I will escalate this matter through the appropriate channels.

So you should not be at all surprised by the tone taken with you.

As far as the technical issues, we have already explained, multiple times and in multiple ways, that there is no vulnerability and you should simply put the .jar back.

Our explanations in this thread are already clear, complete and comprehensive - there is no way to improve upon them. So, your next step is to seek help from a teammate who is able to understand them.

As far as your condescending suggestion that we might need to "take a break", be aware that you are one step away from taking a permanent break from our forums, because you are wasting community resources, lying flagrantly about what you just said, taking a condescending tone toward Support, demanding work that you are not entitled to, and dismissing correct answers because you don't understand them while making no effort to understand them.

You would be only the 3rd person in our 22yr history of hosting forums to be banned for a reason other than spamming. Quite an achievement.

So, if you don't have a teammate better versed in security, we would strongly recommend taking this thread and asking an AI to explain it to you. The AI can act as a "tutor" and explain multiple things you don't seem to understand here.

Further, assuming you use a neutral prompt, the AI will be able to explain to you why you are on the verge of being banned from the forums, and what to do about it.

Announcement

Critical: commons-lang2.6 to commons-lang3 Migration - Dependency Conflict with SmartClient Framework

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment