Out of curiosity, what exactly are the known security vulnerabilities with these versions?

An example for Apache Tomcat: Apache Tomcat could allow a remote malicious user to execute arbitrary code on the system, caused by a flaw in the AJP connector. By sending a specially-crafted AJP request, an attacker could exploit this vulnerability to execute arbitrary code or obtain sensitive information on the system.

Description for AngularJS: In AngularJS the function `merge()` could be tricked into adding or modifying properties of `Object.prototype` using a `__proto__` payload.

Description for jQuery: jQuery as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.

An example for Bootstrap: In Bootstrap, XSS is possible in the tooltip or popover data-template attribute.

Thanks for the comment, that is interesting. Just to take the first example re Tomcat: the AJP Connector is disabled by default in FME Server since FME 2019, see https://knowledge.safe.com/questions/92201/apache-tomcat-rce-vulnerability-april19-windows.html

For older versions you can disable the AJP connector simply by commenting out a single line in the Tomcat config.

So I don't really understand how that's an issue?

Regarding the javascript stuff: is this really a server that will be standing in a DMZ and be outwardly visible to "everybody"?

@david_r, Yeah, I'll outcomment the lines in the server.xml and see if that solves the Apache high risk already.

About the Javascript stuff: it is indeed a server in a DMZ outwardly visible for "everyone", so security is critically important. Any idea how I can easily update these for the whole configuration?

For critical stuff I'm not sure I'd dare put FME Server with full visibility on the internet, but of course that's just my opinion. In the couple of cases where I've been involved we've ended up building a custom web interface on top of FME Server for the outward facing functionality, thereby massively limiting access to e.g. the API and GUI functionality.

The principle is that the less a potential attacker knows about your system, the less attack vectors there are to exploit. In that regard FME Server is not only very well documented, a potential attacker could even very easily install a trial version themselves to play around with locally, which would be extremely helpful for a motivated intruder.

I'm guessing you can certainly try manually upgrading all the underlying javascript libraries but I suspect there's a fairly high probability that something breaks and then all bets are off as to support. Another thing is that simply upgrading libraries without proper integration testing might even introduce new vulnerabilities.

Hi David, thanks for your response and advice. So also with a CA certificate installed it is not recommended to have the FME Server 'open' through a public IP and certain ports?

If you need an official answer to that question you'll have to ask Safe, I think. But then again FME Cloud is a thing, and it seems to be working pretty well so it might be that I'm exaggerating.

It's just my opinion that I personally would avoid that as much as possible. But then again it depends on how critical your server is, and what the consequences of an intrusion would be. Would it be a nuisance, or would it be the end of the world as we know it.

Hi @geojan,

Please could you reach out to so that we can investigate these vulnerabilities with you further?