The inode is the server's internal information specific to a file, so many security scanning software would report this as a vulnerability.
However, there is very little information you can find on the web on how this can translate to a real hack. It may assist in discovering things that a file A is a hard-link (same file, on the same filesystem) as a file B, not much more.
Apache at one point included the inode of a file as part of the value of the ETag
header (which is configurable and possible to disable). Apache stopped this inclusion by default since version 2.4.
NGINX itself never used the inode of a file as part of its ETag
header.
However, security scanning software would still report NGINX as leaking inode info just because they never know whether it's proxying old Apache or other software that actually leaks inode info.
So you can say it's a false positive if you are running an NGINX-only setup.
And if you don't, you can still say that it is false positive, because "OK, this is internal to the server, but nobody ever was able to do anything with it".
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…