Needs updated to Tomcat 8.5.51 for GhostCat bug fixes

In Ubuntu packages, the AJP connector is disabled by default,
so unless specifically enabled by an admin, deployments made
using the package are not vulnerable to this issue.

OK, this security issue is now open for about one year. Is there any plan to fix this issue?

Hi,
per the the CVE triage this is low risk (as also explained by right Marc when the bug was opened).
Also see https://ubuntu.com/security/cve-2020-1938 for details.

Independent to this issue, but in general I'm wondering if still we should consider a MRE bump to e.g. 8.5.54 for Bionic which is back on 8.5.39 still.

Adding server-triage-discuss tag for that.

@Security - checking past uploads and the package I've found that - since it is in universe there are no usual regular MREs. But there was a security upload for [1] and some former ones.

I've read through [2] and seen that there are a few low [3][4] and one medium [5] case open.
And as reported that would also include [6].

Since the package isn't getting usual MREs (being n universe) but has got MRE bumps for security reasons I wanted to ask if you'd consider doing that again?

OTOH .39 to .61 also sounds like quite some regression risk so I'd absolutely understand a simple "no" as answer. There are more recent versions in newer Ubuntu release, but only of tomcat9 and later, not tomcat8.

I subscribed ubuntu-security for an answer to my question - it felt wrong to "assign" you as that is your call to make.

[1]: https://ubuntu.com/security/CVE-2019-10072
[2]: https://tomcat.apache.org/tomcat-8.5-doc/changelog.html
[3]: https://ubuntu.com/security/cve-2019-17563
[4]: https://ubuntu.com/security/CVE-2019-0232
[5]: https://ubuntu.com/security/CVE-2019-12418
[6]: https://ubuntu.com/security/cve-2020-1938

It wasn't a security update that bumped 8.5.30 to 8.5.39, I believe it was an SRU for openjdk compatibility.

The issue with bumping from .39 to .61, is the same issue will come up as described in the CVE tracker, namely:

"One of the upstream fixes for this issue renames the requiredSecret parameter to secret and adds a secretRequired parameter that defaults to “true”. Adding this change to stable releases will result in servers failing to start until the administrator either changes secretRequired to “false”, or configures an adequate secret. Apache starting supporting a secret in mod_proxy_ajp starting with 2.4.42, which means to enable a secret we will have to issue Apache updates with the backported secret support."

So if an installation was vulnerable to CVE-2020-1938, the update would break it, and they would then need to disable the security fix, or use an updated version of Apache.