Finding and judging a vulnerability

A version is a fact. A vulnerability is a judgement about that fact: that something about this service, at this version, on this device, could be made to do what it should not. In this lesson you will move from one to the other. You will read the version of a component on your own device, compare versions the way the numbers actually order, and then decide whether what you have found is worth acting on. The decision matters more than the finding, because a list of old versions with no judgement is not an assessment.

What you'll be able to do

• Read the version and build details of a component on your device.
• Compare two version strings the way their numbers order.
• Ask the three questions that turn a version into a judgement.
• Decide between patching, disabling and accepting, and record the reason.

Step 1: Read a version in full

Start with a component that is on every device and that has a version you can read directly. openssl version -a prints the version and the details behind it.

openssl version -a

OpenSSL 3.0.19 27 Jan 2026 (Library: OpenSSL 3.0.19 27 Jan 2026)
built on: Fri Apr  3 12:29:32 2026 UTC
platform: debian-amd64
options:  bn(64,64)
OPENSSLDIR: "/usr/lib/ssl"
Seeding source: os-specific

The first line holds the version, 3.0.19, and the date that release was cut. The built on line is when this copy was compiled, which is often later than the release date because distributions rebuild packages. The platform line names the target. The three numbers in 3.0.19 are major, minor and patch, and it is the patch number that moves most often, because it is where small fixes land.

Read the version as a point in time. A build date from months ago is not automatically a problem, and a recent one is not automatically safe. What the version gives you is a thing to compare against the version that carries the fix, if there is one.

Step 2: Compare versions the way the numbers order

Before you can say whether a version is old, you have to compare two of them correctly. A plain sort gets this wrong, because it compares text, and as text 3.0.7 sorts after 3.0.13. The -V flag asks sort to compare version numbers instead.

printf '3.0.7\n3.0.13\n3.0.19\n' | sort -V

3.0.7
3.0.13
3.0.19

Run the same lines through a plain sort and you get 3.0.13, 3.0.19, 3.0.7, which puts the oldest release last and would lead you to the wrong conclusion. sort -V reads each run of digits as a number, so 13 comes after 7 where it belongs. Use it whenever you line up versions, and treat any comparison that was done as plain text with suspicion.

Step 3: Ask the three questions

A version on its own is not a finding. Three questions turn it into one.

The first is reachability. Who can reach this service? A component on 127.0.0.1 can be reached only from the device itself, so the ways an issue could be used are few. The same component on 0.0.0.0 is reachable from your whole network. The version did not change between those two cases, and the risk did.

The second is currency. Is this version behind the one that carries a fix? You answer that by comparing version strings with sort -V, and by reading the release notes or advisory for the component. An old version with no known issue is a lower priority than a slightly newer one with a known issue.

The third is impact. If the worst happened, what would it cost? A service that reads public files matters less than one that holds a key or a password. The impact of the same flaw is not the same on every device.

Step 4: Act, or accept, and record it

Once you have a judgement, there are three honest endings. You patch: you update the component to the version that carries the fix. You disable: you stop the service or bind it to 127.0.0.1 so it cannot be reached from the network. Or you accept: you decide, on purpose, that the finding is not worth the cost of the other two, and you write down why.

Updating a package is pkg upgrade, which needs no root. Binding a service to a port above 1024 needs no root either, which is why Termux uses 8022 for its SSH server rather than 22. What does need root is binding a port below 1024, and on an ordinary phone that is simply not available. Where a fix needs root, say so plainly rather than pretending it is possible, and take the non-root option instead.

Whatever you choose, write it down with the date and the version you were looking at. The next time you run this assessment, that record is what lets you see whether anything changed.

Quick reference

Command	What it does
openssl version -a	Prints a component's version and build details
sort -V	Orders lines as version numbers, not as text
sort	Orders lines as text, which gets versions wrong
ss -tln	Shows whether a service is bound to loopback or the network
pkg upgrade	Updates installed packages, without root

Next steps

• Service versions and what they tell you is the step before this one, where the version is read.
• Reading a port scan properly shows how the reachable ports are found in the first place.
• Passwords and keys explains what is at stake when a component holding a secret is the one you are judging.