Trjtdtk

It looks to be trying to exploit some form of command injection. As DarkMatter mentioned in his answer, this was likely a broad attempt to find any vulnerable servers, rather than targeting you specifically. The payload itself just appears to just be testing to see if the server is vulnerable to command injection. It does not appear to have any additional purpose.

In order to test if you would be affected by these specific payloads, the easiest way would be to send them to your own server, and see how they respond. Note, that I only say this because the payloads themselves are benign; I do not recommend doing this with all payloads.

My bet is that your server is not vulnerable, because I would have expected to see follow up request to actually exploit your server.

It is probably nothing. It seems like the broad spam of a scanner looking across the web for any website that evaluates and returns that subtraction when it shouldn't. It is a pretty common thing to see.

The use of actual function names (e.g. print) suggests they're looking for websites that are using eval in some way (note that this could be PHP's eval(string $code), JavaScript's eval(string), and other scripting languages' equivalents).

I note that the executable code appears immediately after the first version parameter after Mozilla/. This means the authors of this attack believe that enough websites in the wild are actually using eval as a (horrible) way of parsing a two-component (major.minor) version number.

So I imagine vulnerable websites were doing something like this (pseudo-code):

var userAgent = request.headers["User-Agent"];

var indexOfVersion = userAgent.indexof( '/' );
var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
var versionNumber = eval( versionText ); // <------- this is the vulnerability!

it looks like they are trying to inject PHP code into log files. The idea being that if the sysadmin is using a PHP app to parse the logs, some might view the logfile as trusted (after all, the user does not normally get to directly alter the logfile) and therefore forego any sanitisation processes.

If you are looking at your log files through a desktop or CLI text editor, you will never be vulnerable to this attack. If you use a PHP app, make sure it treats the logs as untrusted and sanitise it just like you would a normal user input field.

This is simple; they're trying PHP command injection. The process is to substitute a header (in this case the user agent field) with a mathematical expression, then to determine whether the code is being executed view the return value. If the code is executed, the return value will be the result of the expression, rather than the original expression. You'll notice the slightly spammy usage of open and close brackets, semicolons and other characters often used to fool interpreted languages into intepreting data as executable code. Nothing to worry about, automated vulnerability scans like this are par for the course nowadays.