** Using WeBWorK **

Your IT seems to be confused about something.  Those are static asset files.  Any file served under the webwork2_files path is a static asset (although they can be dynamically generated images and such they are still considered static assets).  None of those files contain user sensitive data.  Particularly the ones you listed.  Furthermore, all files under the webwork2_files path are meant to be publicly accessible.

Yes, there is no actual directory named webwork2_files. There never is an actual directory that matches the URL on any server for about any file that is served, so that is completely off the point.

Note that a file path traversal attack means that someone could modify a URL to access any file they wanted to on the server because the server does not protect against such modifications and allows any file to be served via such an approach.  For example, if the server had a route named loadFilename that accepted a URL parameter that will serve the given file like https://server.name/loadFilename?filename=image.png, and an attacker could use https://server.name/loadFilename?filename=../../../etc/passwd and get the secure file passwd because the server does not check the path that is passed and just serves that file.

I do not believe that there is such a case where that can be done with webwork2, and of course if there is let us know and we will fix that.

Although, here is where I believe your IT is confused.  The MathJax tex-svg.js file would have the URL http://localhost:3005/webwork2_files/node_modules/mathjax/es5/tex-svg.js?version=^3.2.2.  The version URL parameter in this case does not in any way dictate what file is loaded.  In fact, it is completely ignored by the webwork2 app.  The only reason it is there is to make the URL change when the version of the MathJax library changes (for instance when webwork2 is upgraded and a new MathJax version is switched to with that upgrade), and thus browser caching will be prevented.  This sort of thing is standard practice, and there is certainly nothing insecure about it.  Most likely your IT is seeing that and thinking it is something like the filename parameter in the previous example.  However, it is nothing like that and no file path traversal attack is possible using the version parameter.

For the bootstrap css file most likely there is similar confusion by your IT.  They are most likely seeing the hash in the file name and thinking that means that the file is user specific content that is being served. Again it is not.  In fact that hash will be the same on any webwork2 server using the same version of webwork2.  I see that my server has that exact hash.  The hash is based on the content of the file, and will change anytime the content of the file changes which again might happen when webwork2 is upgraded, and this has the exact same purpose as the version parameter to prevent browser caching.  This is also standard practice, there is nothing insecure about doing this, and it is completely impossible to use it for a file path traversal attack.

As to the maa_logo.svg file, that is completely off base.  That file does not have a parameter on its URL, and there is nothing that should make anyone believe there is a potential file path traversal attack.  The URL is /webwork2_files/themes/math4-green/images/maa_logo.svg, and the actual file served is /opt/webwork/webwork2/htdocs/themes/math4-green/images/maa_logo.svg.  This is the same as for a default apache2 server serving a file located in /var/www/html.  The URL would be /images/filename.svg and the file is /var/www/html/images/filename.svg.  Again, it is extremely rare that a file path on the server actually matches the URL path.  It is also not possible to, for instance, use a URL like /webwork2_files/../../../etc/passwd and gain access to the /etc/passwd file.

So long story short, your IT (or perhaps some automated tool they are using for this check) is completely unfounded with this.  It also is not possible for your IT to validly detect a potential file path traversal vulnerability just by looking at URLs.  So something is completely wrong with their assessment.  The only way to detect a potential file path traversal vulnerability would be to analyze the code of the server and application.  Just by looking at the URL they can not see if there are protections in place against exactly the sort of things listed (like using dot-dot sequences, using a suitable file system API, etc).