Finding and judging a vulnerability

As text, the character 1 comes before 7, so a plain sort puts 3.0.13 ahead of 3.0.7 and leaves the oldest release last. The -V flag reads each run of digits as a number, so 13 is correctly greater than 7. It does not reverse the order, does not strip the dots, and does not skip lines that begin with a digit; a plain sort reads all of them, just as text.

Reachability, currency and impact are the three that change a fact into a decision. The port number tells you where the service is but not who can reach it, the device name is an identifier rather than a risk, and uptime says nothing about whether the software carries a known issue. A version on its own is not a finding until you have asked those three questions.

A service bound to the loopback address accepts connections only from the device itself, so the ways an issue could be reached are far fewer than for one bound to the network. That lowers the priority rather than raising it; it does not remove the finding, and it does not make the traffic unencrypted or require immediate removal. The version did not change, only the exposure did.

Some fixes, such as binding a port below 1024, need root, and on an ordinary phone that is simply not available. The honest move is to say so and take the option that does not need it: updating a package with pkg upgrade, or binding the service to loopback so it cannot be reached from the network. Pretending a command will work, or dismissing the finding entirely, both leave the record wrong.