Skip to main content
All CollectionsProduct updates
log4j Security Vulnerability and MSSNGR
log4j Security Vulnerability and MSSNGR

Details on if our systems were affected by the log4j ("log4shell") vulnerability (CVE-2021-44228)

Simon Brückner avatar
Written by Simon Brückner
Updated over 3 years ago

As you might have read in the news recently, a severe vulnerability named "log4shell" was published on Dec 10 2021.

The attack uses a vulnerability in the Java logging library "log4j" which is used on plenty of server installations. Through this attack, it might be possible to inject code via a logging string and then execute java code on the compromised machine.

We have extensively checked all our systems as soon as we became aware of the vulnerability and have come to the conclusion that none of our systems holding user data were affected.

Following, you'll find a few details about our research and measures we took in case there were possible attack vectors found:

MSSNGR Main Backend Infrastructure

  • MSSNGR Core System: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR API: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Databases: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Asset Delivery: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR File Storage: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Carbon: Java is not installed, thus neither log4j nor the attack can be executed.

MSSNGR End User Clients

  • MSSNGR WebApps: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Android Apps: The affected versions of log4j are not compatible with Android so the attack can not be executed

  • MSSNGR iOS Apps: Java cannot be run on iOS, so the attack cannot be executed.

MSSNGR Ancillary Systems

  • MSSNGR Backup Systems: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Error Logging: Java is not installed, thus neither log4j nor the attack can be executed.

  • MSSNGR Access Logging: Java is installed and Elastic Search is used, which could be possibly affected. However the logging is not publicly writable (the writes are proxied through the aforementioned client and backend systems), which is a precondition for the attack to be executed. Also, for GDPR reasons, all personal data is anonymized on the system, which would make a possible attack senseless. However as a matter of precaution, we have still changed a JVM setting to mitigate the attack vector as advised by the Elastic Search team.

Did this answer your question?