Latest news (10:52)
- The core of XperienCentral is not vulnerable
- All custom code of the installations GX is managing were checked and no CVE-2022-42889 vulnerabilities were found.
- However, it is possible that proprietary customisation is vulnerable. There is a way to check that yourself, see the 15:10 update.
CVE-2022-42889 is a vulnerability in the widely used Apache Commons Text library. It can be exploited via code execution by malicious input. On 18 October 2022, this vulnerability was published by the National Cyber Security Centre and reported to GX.
The vulnerability arises from an insecure implementation of Commons Text's "variable interpolation functionality". Some standard lookup strings could potentially accept untrusted remote input from attackers. Examples include DNS requests, URLs or inline scripts.
October 18th, 10:24
Notification of vulnerability received.
First notifier informed of investigation started from Product, System Administration, Consultancy, Data Protection Officer and Customer Services. GX Software is investigating the impact of the notification and whether it will impact XperienCentral
This page has been created in English and Dutch to inform everyone simultaneously.
It is not yet known whether this vulnerability will impact XperienCentral. As soon as more is known about this, substantive information will be posted here.
Apache Solr usually seems to use a vulnerable version of the plugin that includes CVE-2022-42889. However, we found that Solr in XperienCentral does not use the two specific vulnerable methods.
The vulnerable plugin is also located in the Modular Content functionality of XperienCentral. However, again, no code was used where the vulnerabilities were found.
XperienCentral's source code has been scanned for vulnerable plugin versions. Two versions are present in XperienCentral.
- One version is included in Apache Solr (XperienCentral's search engine). In turn, Apache does not provide any notifications about the CVE. Furthermore, Solr's source code was searched. In it, no references were subsequently found to the vulnerable methods, as listed on https://nitter.it/i/status/1582051770884272129.
- Another version of the vulnerable plugin is embedded in XperienCentral's Modular Content Addon. There, it helps trigger the import and export of content and therefore has an interdependency with Solr. Again, we see that the vulnerable plugin was not directly used there (and the analysis of Solr already showed no risk).
Finally, our own XperienCentral test environment was scanned for the presence of the vulnerable plugin versions. Outside the locations mentioned above, the mentioned plugin was not found.
Conclusion so far: XperienCentral has so far not been found vulnerable to CVE-2022-42889
It is possible the vulnerability is in developed customisations. To rule this out, GX architects have been asked to immediately check the customisations present on the installations they are responsible for.
All GX architects are informed.
There is a technical briefing internally for how to check whether the customisation in XperienCentral is susceptible to CVE-2022-42889. This briefing is the basis on which architects (but also partners or organisations writing their own customisations for XperienCentral) can do their check. This briefing will appear here soon.
15:10 - how to check custom code
If you develop your own custom code.
There are several ways to check whether the customisation developed in XperienCentral is susceptible to CVE-2022-42889. The first step is to check for the presence of the plugin in XperienCentral. This can be done in two ways:
Option 1 (check it yourself)
Search the customisation code for plugins that have a dependency on org.apache.commons.text versions 1.5 to 1.9. For example, such a dependency looks as follows:
However, to get certainty, option 2 is better.
It is also possible to scan the file system, of the server on which XperienCentral is installed. If this is desired, please contact Customer Services. We will then provide these instructions on a customised basis. A system administrator can easily follow these instructions.
- Note: If you search for the presence of the plugin in this way, you will find references in this plugin to the webmanager-solr-bundle plugin and the wmamodularcoontentimport-export plugin. These plugins were checked earlier today (posts of 11:43 and 12:05) and are not susceptible to this vulnerability.
Once (using Customer Services' steps) it is known which plugins depend on commons-text, it is then important to check whether these plugins are actually vulnerable.
If the plugin has a dependency on a version of commons-text other than 1.5 to 1.9, it is not vulnerable. If the plugin does use a version of 1.5 to 1.9, check the code. Does it use any of the following methods?
Note: The method calls do not necessarily have to be included in the code exactly like this. Method 2 can also be included in the code as:
StringSubstitutor interpolator = StringSubstitutor.createInterpolator(); interpolator.replace(<input>);
In conclusion, the moment the custom code...
- uses one of these methods, AND
- its input can be entered by an end user...
...you are at risk of exploitation. In this case, it is advisable to update the dependency in the relevant plugins to version 1.10 of commons-text in which this vulnerability has been fixed.
Customer Services is preparing steps to inform organisations personally about the steps to be taken. Expect a message from your contact with further information later today.
Customer Services has informed all CISOs (Chief Information Security Officer; responsible for the information security policy from within an organisation) of the latest information and GX's planned steps. If you are in doubt on your own whether your organisation has been informed, please contact your organisation's CISO. If this is not possible for reasons, you can also liaise with Customer Services.
October 19th, 09:47
GX architects have had joint discussions and a key emphasis we want to make is that the vulnerability is in the Apache Commons Text library but as long as the vulnerable method is not called, you are not vulnerable. In addition, we see that Solr is in the process of creating a patch for the vulnerability. Once that patch is ready, we will incorporate it into the next version of XperienCentral and can patch installations as required. Again for your information: to date, the core of XperienCentral has not been found vulnerable.
Almost half of the organisations have been audited by the responsible architects. None of these organisations found vulnerabilities on the custom code developed by GX.
96.7% of organisations have been audited. To date, no vulnerabilities found in the customisation developed by GX.
October 20th, 07:56
99,2% of organisations checked. No vulnerabilities found in GX's custom code.
Expect our final statement around 11:00am
10:32 - Final statement
100% of organisations have been thoroughly checked. All custom code from installations managed by GX has been checked and no vulnerabilities are found during this exercise.
Customer Services is now initiating the procedure to inform all organisations about the final statement and the steps taken. Expect your personal notification later this morning and we expect to have notified everyone by the end of the day. The communication is through your CISO who was also the addressee for our notification on October 18th between 16:50 and 17:50. If you already have questions or have a situation that cannot wait, please ask Customer Services.
The CISOs of all organisations have received a message from Customer Services. In case you missed the message or are also interested:
Two days ago, on 18 October, we informed you of a possible vulnerability in the Apache Commons Text (namely CVE-2022-42889). Fortunately, within a quick 2 hours we were able to conclude that this vulnerability did not occur in the core of XperienCentral. In addition, we wanted to completely rule out the possibility that this vulnerability occurred in the developed custom code that GX has (possibly) built for your XC installation in the past. We can confirm that no vulnerabilities were found.
16:05 - Conclusion
- The core of XperienCentral is not vulnerable to CVE-2022-42889 in Apache Commons Text library, also known as Text4Shell / Text2Shell / Act4Shell.
- The same applies to custom code developed by GX; this has been checked by architects and the vulnerability has not been found.
We hereby also close this live blog. Nevertheless, if you still need information from GX, please contact Customer Services.