When building parallelized applications using Java, a developer sometimes finds himself with a thread being blocked indefinitely because of a four-year-old bug in the spring-bean-web-rest-foo-bar-factory - dependency, possibly ruining the carefully orchestrated parallel architecture without any log message pointing to a problem.

Sometimes though, the developer also just forgets to allocate enough threads or forgets to set a timeout.

I have been there both.

So, usually, you would simply restart the application and take a thread dump using JStack or similar. But sometimes you are working in a thin Linux image on Docker with nothing more than a barebones JRE running the application and an irreproducible hangup that only occurs once per month and only with production workloads.

So, I was thinking of adding a (hidden) REST endpoint that will return a nice thread dump like this to the caller.

But of course, leaking technical information of the service to a possible end-user? That sounds like I created a gaping security hole for attackers to exploit. But maybe not? I mean, it's just a thread dump after all, you don't see what kind of information is being processed. Heap dumps would be much, much worse.

So, are publicly available thread dumps a security concern? I am very exited to see your answers.

  • Why not just secure that endpoint with a PSK from your config file? Also, if you run docker you also very likely run behind a reverse proxy. Why not just block that route in the proxy and call the endpoint from a bastion host?
    – marstato
    Commented Jun 6, 2019 at 12:19
  • @marstato Valid point, both very possible. Still, are there any security implications when it isn't protected like that? Commented Jun 6, 2019 at 12:27
  • (un)fortunately, i never had to look ad a thread dump, so i dont really know what it contains. But even just a stracktrace could reveal vulnerable dependencies.
    – marstato
    Commented Jun 6, 2019 at 12:33
  • @marstato How for example? I just can't think of anything. Commented Jun 6, 2019 at 12:39
  • Certain methods in the stacktrace can point to a specific (or small) range of versions of the dependency. Given that version range one can lookup applicable vulns, e.g. cvedetails.com/vulnerability-list/vendor_id-15866/…
    – marstato
    Commented Jun 6, 2019 at 12:46

1 Answer 1


It is a kind of information leakage. An attacker armed with this could figure out what libraries you are using and possibly figure out the versions using the stack trace information.

This would enable a malicious user to go and find any know vulnerabilities and attempt to exploit them much more easily.

I wouldn't consider it to be a serious security problem, but it could magnify the impact of any other security weaknesses. The idea of configuring it to not be accessible to the general internet is good. You may also want to layer some additional controls onto it such as usually running with the endpoint disabled entirely by application configuration and only turning it on if you are seeing problems. Defense in depth is your friend when it comes to these sorts of things.

  • I think the basic answer is correct: the risk is basically equivalent to exposed stack traces which is definitely not a secure practice. "possibly figure out the versions using the stack trace information" I think this is a bit weak though, it's very easy to determine libraries and line numbers in the trace will likely give away the version.
    – JimmyJames
    Commented Jun 6, 2019 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.