While asking my magic ball (aka Google) for a path to the solution, I realised that path traversal and local file inclusions, although often mentioned in the same context, are two different mechanisms and offer different ways of getting a shell or flag at the end, and should be treated differently.
The main problem was that Apache normalises URLs to prevent path traversal, but in this case it introduced a way to traverse the path from the root of the web server to directories that should not be seen by a remote unauthenticated user.
A simple demonstration for this vulnerability would be to access /etc/passwd on the victim server with curl. curl www.victim.com/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd With this method it was quite easy to get the first flag as it resided in the home directory of the apache user.My next goal was to get the second flag which was located in root/flag.txt, but it was not as easy as traversing down the path, as the apache user didn't had the correct permissions. This led me down an hour long rabbit hole as I thought I could turn the path traversal into an LFI into RCE,completely disregarding the fact, that I haven't found any .php files or upload endpoints on the server, as I thought this was the way to achieve RCE via LFI. After realizing this I concentrated my efforts again on the path traversal itself and looking for sensitive files like backups, .confs, logs etc. During my initial recon I found out that there was also a Tomcat running on the server. After some minutes I was able to find tomcat-users.xml with a username and password to the manager console of Tomcat. From there I was able to upload a malicious .war file as my reverse shell and I had command execution on the server.