CVEs are useful for all actors in the software chain (developers, sysadmins, customers...) to decide whether or not to take action on existing software. Proof of concepts are deliberately redacted because, as I am going to show, it takes a long time to patch the actual installations.
In a theoretical world, patches are deployed immediately to all devices. This guarantees that all devices are patched and protected. This is impossible.
- T0: A vulnerability in the Linux kernel, affecting the Android kernel, is found and patched
- T1: Google patches AOSP and releases the patch
- T2: mobile manufacturers (e.g. LG, Motorola, Samsung) receive the patch and apply it to their customized build
- T3: the patch is OTA-delivered to consumers
- T4: a company with 1000s of Android business devices from same manufacturer deploys the update to the work devices
This is similar to a case happened to me during my work
- T0: a vulnerability in Apache is found and patched, Apache is released
- T1: a large corporate using Apache for a lot of applications installed internall on a variety of servers schedules the upgrade
- T2 to T100: all Apache instances are upgraded on the corporate systems, involving suppliers and managers to meet and schedule a test plan
CVEs are useful to determine "how old" and "how risky" a software is. By examining the severity and the affected components the IT staff may decide whether to, e.g., not to upgrade for now, upgrade immediately, apply additional temporary security measures (e.g. firewalling, proxying).
In the corporate world there is an intrinsic slowness in software upgrade. I see banks running Java <= 1.5 (again, no later than 1.5) because later versions have not been certified and Java 1.7 is already end of life.
We know companies still run XP because they don't know if all of their existing software base runs on Windows 7, not even dare try 10.
A severe CVE, according to my experience, can be the reason to prioritize a software upgrade in a structured corporate scenario.