Safety reports its own dependecy (jinja2) as vulnerable without fix available

[washeck]

• safety version: 3.2.0
• Python version: 3.11
• Operating System: Linux

Description

Safety includes a dependency to jinja2 (which we otherwise don't need in our project) and because SafetyDB includes also disputed vulnerabilities, we are getting this error:

-> Vulnerability found in jinja2 version 3.1.4
   Vulnerability ID: 70612
   Affected spec: >=0
   ADVISORY: In Jinja2, the from_string function is prone to Server Side Template Injection (SSTI) where it takes the "source" parameter as a template object, renders it, and then returns it. The
   attacker can exploit it with {{INJECTION COMMANDS}} in a URI. NOTE: The maintainer and multiple third parties believe that this vulnerability isn't valid because users shouldn't use untrusted...
   Fixed versions: No known fix
   CVE-2019-8341 is CRITICAL SEVERITY => CVSS v3, BASE SCORE 9.8
   For more information about this vulnerability, visit https://data.safetycli.com/v/70612/eda
   To ignore this vulnerability, use PyUp vulnerability id 70612 in safety’s ignore command-line argument or add the ignore to your safety policy file.

It think it would be good if security scanner did not report its own dependencies as vulnerable without fix available. In general, I think you should not include the disputed vulnerabilities by default, because all of them I investigated are useless and it just forces me to add evergrowing list of excludes.

[MichaIng]

This CVE was reported back in 2019 and popped up again in 2022, highly disputed and ignored (reasonable IMO) that time: GHSA-f6pv-j8mr-w6rr

I do not see a single other reference, that this has somehow worsened with latest jinja2 or that it has been newly found to be more problematic than rated (by the majority) that time. To me it looks like Safety just hit an update button, triggering this CVE to be recognised again, while nothing has changed: https://data.safetycli.com/v/70612/97c/

The very same applies to CVE-2018-20225 from 2018/2019: https://data.safetycli.com/v/70612/97c/
About a "vulnerability", which IMO is totally natural for any kind of package index system, so you could call APT from Debian/Ubuntu vulnerable as well. When adding "extra" indexes for additional packages, newer versions or binary vs source builds, this is naturally something the admin must take care of, there is no solution. And pip even has the --index-url option to enforce a particular index, compared to --extra-index-url, which does and behaves exactly how it should, IMO.

Triggering such old, disputed and (reasonably IMO) ignored CVEs to make every safety run fail does not make sense. Not sure what the purpose behind this is, probably to move free to paid plans. As free user, one does not see that there is no solution for any of the two CVEs, but that they have been intentionally ignored since years. EDIT: Sorry for the insinuations, it was probably not intentional and/or externally triggered.

EDIT: Okay, the update was probably triggered from other databases: https://nvd.nist.gov/vuln/detail/CVE-2019-8341#VulnChangeHistorySection, https://nvd.nist.gov/vuln/detail/CVE-2018-20225#VulnChangeHistorySection

The exact same happened there on exactly the same dates:

CVE Modified by MITRE 3/20/2024 10:34:17 PM

Action	Type	Old Value	New Value
Added	Tag		MITRE disputed

A disputed tag was added in March, and then other updates without visual change until mid May. Probably safety should recognise tags which indicate that it is disputed, and ignore old CVEs then. So yeah, fully agreeing with OP here.

EDIT2: Probably these are better reported here as false positives? https://github.com/pyupio/safety-db/issues
EDIT3: Similar case with some comments from safety maintainer: pyupio/safety-db#2363 (comment)
Makes sense that free users see this just now, due to 30 days delay.

[nickste]

Hi folks - we’ve revisited this issue and now believe it was a mistake not to fix it. I'd like to explain our updated thinking and get your feedback before we proceed.

We want to introduce a disputed category for vulnerabilities in the Safety database, which will be ignored by default. A scan won’t fail due to disputed vulnerabilities, but the CLI output will note them as “1 disputed vulnerability ignored.” Users will have the option to modify this default in the Safety policy to instead flag all disputed vulnerabilities.

This implementation requires a CLI upgrade and will take time. In the meantime, for the jinja2 case specifically, we plan to remove it from our database as a vulnerability. This temporary solution resolves the issue without requiring a CLI update, though we recognize it’s less transparent until the disputed mechanism is in place.

[MichaIng]

This sounds both very reasonable. I agree the jinja2 case is not as transparent as desired, when there are other disputed vulnerabilities which still cause a check failure. But that safety reports it's own dependency in this particular case, is maybe reason enough to temporarily accept this inconsistency.

[nickste]

Thanks for the feedback! As of today we've removed the Jinja2 disputed vulnerability.