In many cases, they will cherrypick security fixes and other major bugfixes from the bleeding edge version, and put those fixes in the old versions of the software.
This is the same thing the PHP folks would do while the old PHP is supported. Once the old PHP is out of support but Ubuntu LTS is still in support, then the Ubuntu folks have to put in the extra work to do the cherrypicking.
There are community backports (like Sury's Debian builds) for PHP, including a branch of PHP 5.6 originally released in 2014. Most other notable languages and major packages have something likewise as well, right down to major packages like Drupal 6. It's not always easy, but it's doable and the work is usually either already done or can be paid for.
Weird things that are truly too difficult to support are also often excluded. Eg Spectre/Meltdown fixes were non-trivial and had to be backported to a fairly wide range of things but that only went so far back. Some old systems just never got those fixes and instead have to be ran with a workaround ("don't run untrusted code"). I don't know how things are with the new offering but large complicated packages with lots of moving parts like OpenStack used to be excluded from the full extended support cycle before as well.
That would be the logical conclusion, but I believe Debian uses the old version for years after it's unsupported and might backport security fixes depending on how severe they are. Either way, I personally wouldn't trust Debian or Ubuntu to properly fix security issues with a program (or in this case, programming language) that they do not actively develop or maintain themselves.
For each Ubuntu LTS release, Canonical maintains the Base Packages and provides security updates, including kernel livepatching, for a period of ten years.