I've read multiple times that leaked ETags from Webservers are considered an information leakage vulnerability.
For example in the server response headers:
ETag: X/"1234-56789"
But I have not found a reason why this is a problem or how this may be abused.
Of course any additional information that is not required for the application to function should be redacted, but what's the damage a a leaked ETag (therefore inode) can do?
Edit: Rapid7 for example see's this as with a severity of four.
The ETag header is used for effective caching of server side resources by the client. The server send an ETag header in the HTTP response to some string and the client caches the response content and associates the string given in the ETag header with it. If the client wants to access the same resource again it will send the given string within some If-None-Match header in the HTTP request and the server will only return the full content if the resource has been changed and otherwise tell the client that the cached content can be used. See Wikipedia for more details.
This means, that every client can get such an ETag header from the server, i.e. the value of the header is not secret. Thus contrary to your question the leakage of such a header itself is not the problem.
The problem is instead if the value of the header (i.e. the string) provides information about the server which should stay secret. Often the value of the header is just a hash over the content of the resource which is not a problem at all. But for example the Apache web server can base the ETag on the inode number, last modification time and/or size of the file. Using these meta information a unique ETag can be created much faster compared to computing the hash of the content. Only, at least the inode number is considered internal information to the server and should not be exposed to the client. While not be usable in attacks directly knowledge of lots of inode numbers can be used to gain for example information about the underlying file system which might help in further attacks against the server.
This means that the inode number should not be extractable from the ETag header because it should stay secret. This was fixed with Apache 1.3.27 (long ago), i.e. the inode number is still used to compute the ETag but in a way that it cannot be extracted from the ETag value.
Edit: Rapid7 for example see's this as with a severity of four.
The CVSS score is computed from several parts. The details for this specific problem can be seen here but it essentially boils down to that it is trivial to use, can be done over the network, needs no authentication and provides some internal information about the server.
