As you are likely aware, late last week, Apache disclosed that the Log4j 2 utility contains a vulnerability that may be exploited for unauthenticated remote code execution. We are actively monitoring this issue and are working to patch any Thomson Reuters product that uses the vulnerable component Log4j 2.

Since the disclosure of the vulnerability, our internal cybersecurity experts have been working continuously to analyze our products and services to understand where the tool may be used and taking expedited steps to remediate any systems that may have a potential vulnerability. To date, our investigations continue to show that there is no evidence that Thomson Reuters systems have been negatively impacted. Thomson Reuters data and systems continue to be secured in accordance with industry standards.  

At this time, we can confirm that the vulnerability either does not exist or has been remediated in the vast majority of Thomson Reuters products.  Our investigation into the situation is ongoing, as are any further remedial actions that may be required.  As such, in an abundance of caution, our teams will be performing additional maintenance tasks throughout this coming weekend, beginning during the evening today, which may result in your platform being temporarily unavailable outside of normal deployment and maintenance windows, although we expect this to be overnight for the majority of regions in order to minimise disruption.

Our top priority is ensuring the integrity of our systems and the information that our customers rely on and this is purely a preventative measure to ensure that we continue to be unaffected by this evolving situation.  If Thomson Reuters becomes aware of unauthorized access to Customer Data, we will notify impacted customers as soon as reasonably possible. 

  • Thanks Mark! Appreciate the updated info. Have a great weekend.

  • Mark apologies for any ambiguity, that was not my intention. Obviously, with the ever evolving situation, we are having to monitor the situation carefully and provide centralized communications to our entire customer base when necessary.

    From your perspective, your HighQ platform instance is now using log4j 2.17.0 as standard. This will be updated to 2.17.1 with the next maintenance release for the platform, which will begin deployment from next week onward. Should the risk assessment change, then we will of course accelerate that.

  • Mark. Thanks for this. Apologies, as your response was a bit ambiguous. :( When you say: "The majority of our platform elements are now using 2.17.0 as standard in production and we will be supplementing this with 2.17.1 over the coming weeks where necessary."

    Does that mean currently EVERYTHING is on 2.17.x: some things are on 2.17.0, the rest are on 2.17.1, and anything on 2.17.0 will be upgraded to 2.17.1 in the coming weeks?

    Or does this mean that some things are still on 2.16.x currently, but that everything will be upgraded to 2.17.x in the coming weeks?

  • Hi Mark. Thanks for following up. As I mentioned above, our plan following the initial remediation of the vulnerabilities was to ensure that we kept our log4j components up to date in subsequent maintenance releases, which is exactly what has happened. The majority of our platform elements are now using 2.17.0 as standard in production and we will be supplementing this with 2.17.1 over the coming weeks where necessary.

  • Mark Edwards  My security team is pressing for an answer on the current state of the patch. I asked you "so no plan to upgrade to 2.17 for the main platform?" and you replied ambiguously: "Yes, absolutely."

    Will HighQ be updating the main platform to 2.17 or is the answer that you don't feel there is a need to do this? If you plan to upgrade to 2.17, has this happened yet and if not, do you know when.