New severity for security reports

[Mark Thomas <ma...@apache.org>]

All,

We have had quite a few security reports recently that are technically 
valid vulnerabilities but have pre-requisites that are such that it is 
almost certain no users are impacted by them.

Currently we assign these a severity of LOW. Do we want to handle them 
differently?

Possible options:
- Don't issue CVEs for these
- New severity for "Lower than low" name TBD
- Something else?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: New severity for security reports

[Rémy Maucherat <re...@apache.org>]

On Wed, Jul 15, 2026 at 11:03 AM Mark Thomas <ma...@apache.org> wrote:
>
> All,
>
> We have had quite a few security reports recently that are technically
> valid vulnerabilities but have pre-requisites that are such that it is
> almost certain no users are impacted by them.
>
> Currently we assign these a severity of LOW. Do we want to handle them
> differently?
>
> Possible options:
> - Don't issue CVEs for these
> - New severity for "Lower than low" name TBD
> - Something else?

+1 for no CVE. Hallucinated LLM usage scenarios read like fantasy
novels, so if we know for sure they can never happen then it should be
rejected.

Rémy

> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: New severity for security reports

[Christopher Schultz <ch...@christopherschultz.net>]

Mark,

On 7/15/26 9:40 AM, Mark Thomas wrote:
> 15 Jul 2026 14:35:52 Tim Funk <fu...@apache.org>:
> 
>> Call it "hardening"? (Or something similar)
>>
>> It'll acknowledge it has potential for a security flaw, but not enough 
>> for
>> a CVE?
> 
> That is the part I struggle with. It is the issues where there is a very 
> slim chance that there would be security consequences for a user. In my 
> mind that needs a CVE. But at the same time I recognise that at least 
> 99.99% users won't be affected therefore we don't want to put them in a 
> position where they need to upgrade (because of their own security 
> policies re CVEs).

I agree with the "slim chance" situation. Typically, these things are 
"nothing to see here" for like 99.99% of downstream users. For that 
remaining 0.01%, it's probably a critical security vulnerability, and 
usually due to some terrible security practice (or non-practice).

My guess is that most downstream users fall into 3 categories when it 
comes to security reports for Tomcat:

1. My Tomcat 4.1.39 instance has an 18 year uptime. w00t!

2. Any CVE against any version requires an upgrade.

3. Actually reads the announcements and makes their own determinations.

We can ignore #1 (derelict) and #3 (smart). But we can't do much about 
#2. Mostly these are going to be users who are having security 
requirements imposed on them from the outside, such as from a "security 
scanner" type of system or service.

These days, every few weeks there are OS updates for all major OSs which 
require installation and reboot. I think it's okay to produce CVEs when 
have real implications for downstream users, even if they are in the 
significant minority.

> Then again, with the current volume of CVEs there are likely to be a 
> couple of genuine LOW or greater severity CVEs anyway so does a handful 
> of lower severity CVEs really change very much?
> 
> Maybe we need to document the pre-requisites for being exposed to a CVE 
> more explicitly. But then we run the risk of needing more CVEs if we 
> don't do that correctly.
> 
> As you can probably tell, I don't have a clear idea of what I think the 
> right answer is yet.

Me, too. I think we need to err on the side of caution which is why I 
typically am very liberal when it comes to recommending a CVE be 
allocated for a security report.

-chris

>> On Wed, Jul 15, 2026 at 5:03 AM Mark Thomas <ma...@apache.org> wrote:
>>
>>> All,
>>>
>>> We have had quite a few security reports recently that are technically
>>> valid vulnerabilities but have pre-requisites that are such that it is
>>> almost certain no users are impacted by them.
>>>
>>> Currently we assign these a severity of LOW. Do we want to handle them
>>> differently?
>>>
>>> Possible options:
>>> - Don't issue CVEs for these
>>> - New severity for "Lower than low" name TBD
>>> - Something else?
>>>
>>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: New severity for security reports

[Mark Thomas <ma...@apache.org>]

15 Jul 2026 14:35:52 Tim Funk <fu...@apache.org>:

> Call it "hardening"? (Or something similar)
>
> It'll acknowledge it has potential for a security flaw, but not enough 
> for
> a CVE?

That is the part I struggle with. It is the issues where there is a very 
slim chance that there would be security consequences for a user. In my 
mind that needs a CVE. But at the same time I recognise that at least 
99.99% users won't be affected therefore we don't want to put them in a 
position where they need to upgrade (because of their own security 
policies re CVEs).

Then again, with the current volume of CVEs there are likely to be a 
couple of genuine LOW or greater severity CVEs anyway so does a handful 
of lower severity CVEs really change very much?

Maybe we need to document the pre-requisites for being exposed to a CVE 
more explicitly. But then we run the risk of needing more CVEs if we 
don't do that correctly.

As you can probably tell, I don't have a clear idea of what I think the 
right answer is yet.

Mark


>
> -Tim
>
> On Wed, Jul 15, 2026 at 5:03 AM Mark Thomas <ma...@apache.org> wrote:
>
>> All,
>>
>> We have had quite a few security reports recently that are technically
>> valid vulnerabilities but have pre-requisites that are such that it is
>> almost certain no users are impacted by them.
>>
>> Currently we assign these a severity of LOW. Do we want to handle them
>> differently?
>>
>> Possible options:
>> - Don't issue CVEs for these
>> - New severity for "Lower than low" name TBD
>> - Something else?
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: New severity for security reports

[Tim Funk <fu...@apache.org>]

Call it "hardening"? (Or something similar)

It'll acknowledge it has potential for a security flaw, but not enough for
a CVE?

-Tim

On Wed, Jul 15, 2026 at 5:03 AM Mark Thomas <ma...@apache.org> wrote:

> All,
>
> We have had quite a few security reports recently that are technically
> valid vulnerabilities but have pre-requisites that are such that it is
> almost certain no users are impacted by them.
>
> Currently we assign these a severity of LOW. Do we want to handle them
> differently?
>
> Possible options:
> - Don't issue CVEs for these
> - New severity for "Lower than low" name TBD
> - Something else?
>
>