I have an Ubuntu 16.04 server and one of the crons has a major vulnerability which has been listed as a "Won't Fix" for 16.04, but was fixed in Ubuntu 20.04. I want to pull the patch down, but when I use sudo apt upgrade cron it tells me that it is the latest version (which probably makes sense since it is the latest version for that OS). This is a production server and there isn't currently scope to upgrade the OS completely.

Is there any way to upgrade this without breaking the whole server?

  • Compile and build .deb package from the newer source. Commented Dec 9, 2020 at 8:18
  • I take it the question is more general than the specific cron vulnerability which prompted it, but would you mind saying which vulnerability you’re referring to? Commented Dec 9, 2020 at 8:21
  • @StephenKitt as far as I can tell its CVE-2017-9525 I am not a SysAdmin so these things are a bit confusing to me.
    – Naynay
    Commented Dec 9, 2020 at 8:23
  • @IporSircer will this not affect other parts of the server? I want to just get all my ducks in a row before this is tackled so that there isn't significant downtime if there does need to be downtime
    – Naynay
    Commented Dec 9, 2020 at 8:26

1 Answer 1


If your release doesn’t provide an update you’re interested in, your “best” option is typically to download the source package (specifically, the .dsc and related files), and rebuild the package locally. (See this answer for a brief example detailing how to rebuild a package.)

However this does bring a number of risks, the two main ones being:

  • other changes made to the package since the version you’re currently using may affect its functionality, for example current versions may assume a working environment similar to their target release rather than the one you’re actually using;
  • you will no longer receive automatic updates for the package, should the need arise — effectively you’re shouldering the burden of providing support for the package.

In this particular instance, CVE-2017-9525, the scope of the vulnerability is limited, as detailed in the notes:

I believe that actually exploiting the bug requires updating the cron package. So long as there’s no updates for cron, the vulnerable code doesn’t run. So if we find a second bug in cron then we really should fix the race condition at the same time, but so long as we don’t push a cron update, the vulnerable code just plain doesn’t run. the patch just narrows the time window for the race condition.

The vulnerability is only an issue if the package post installation script is run, which in most cases only happens if the package is upgraded. (It is possible to force it manually, with dpkg-reconfigure, but that won’t happen automatically.) Thus it seems the safest bet for you is to leave the package alone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .