safety is pulling in jinja2 with a vulnerability and failing the safety check

[hangonlyra]

• safety version: 3.2.3
• Python version: 3.11
• Operating System:

Description

When I install safety and run the check, it fails on jinja2 vulnerability. My application doesn't use jinja2. It's a dependency of safety.

What I Did

python3 -m pip install safety
 safety check -i 54318 -i 62044 -i 64396 -i 64459 -i 65213 -i 67599

Console output

#17 38.44 + python3 -m pip install safety
#17 39.25 Looking in indexes: <REDACTED>
#17 39.52 Collecting safety
#17 39.65   Downloading https://<REDACTED>/repository/pypi-all/packages/safety/3.2.3/safety-3.2.3-py3-none-any.whl (146 kB)
#17 39.66      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 146.7/146.7 kB 22.7 MB/s eta 0:00:00
#17 39.68 Requirement already satisfied: setuptools>=65.5.1 in ./build_env/lib/python3.11/site-packages (from safety) (70.0.0)
#17 39.68 Requirement already satisfied: Click>=8.0.2 in ./build_env/lib/python3.11/site-packages (from safety) (8.1.7)
#17 39.68 Requirement already satisfied: urllib3>=1.26.5 in ./build_env/lib/python3.11/site-packages (from safety) (1.26.18)
#17 39.97 Collecting requests (from safety)
#17 40.04   Downloading https://<REDACTED>/repository/pypi-all/packages/requests/2.32.3/requests-2.32.3-py3-none-any.whl (64 kB)
#17 40.05      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 64.9/64.9 kB 11.3 MB/s eta 0:00:00
#17 40.05 Requirement already satisfied: packaging>=21.0 in ./build_env/lib/python3.11/site-packages (from safety) (24.1)
#17 40.22 Collecting dparse>=0.6.4b0 (from safety)
#17 40.29   Downloading https://<REDACTED>/repository/pypi-all/packages/dparse/0.6.4b0/dparse-0.6.4b0-py3-none-any.whl (11 kB)
#17 40.93 Collecting ruamel.yaml>=0.17.21 (from safety)
#17 41.07   Downloading https://<REDACTED>/repository/pypi-all/packages/ruamel-yaml/0.18.6/ruamel.yaml-0.18.6-py3-none-any.whl (117 kB)
#17 41.07      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 117.8/117.8 kB 21.8 MB/s eta 0:00:00
#17 41.31 Collecting jinja2>=3.1.0 (from safety)
#17 41.50   Downloading https://<REDACTED>/repository/pypi-all/packages/jinja2/3.1.4/jinja2-3.1.4-py3-none-any.whl (133 kB)
<TRUNCATED>
#17 52.14 + safety check -i 54318 -i 62044 -i 64396 -i 64459 -i 65213 -i 67599
#17 56.67 -> Vulnerability found in jinja2 version 3.1.4
#17 56.67    Vulnerability ID: 70612
#17 56.67    Affected spec: >=0
#17 56.67    ADVISORY: In Jinja2, the from_string function is prone to Server
#17 56.67    Side Template Injection (SSTI) where it takes the "source" parameter as...
#17 56.67    Fixed versions: No known fix
#17 56.67    CVE-2019-8341 is CRITICAL SEVERITY => CVSS v3, BASE
#17 56.67    SCORE 9.8
#17 56.67    For more information about this vulnerability, visit
#17 56.67    https://data.safetycli.com/v/70612/eda
#17 56.67    To ignore this vulnerability, use PyUp vulnerability id 70612 in safety's
#17 56.67    ignore command-line argument or add the ignore to your safety policy file.

[romanzdk]

We are facing the same issue :(

[officialankan]

This is all of a sudden causing massive issues in all places where we are using safety.

[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.

[nickste]

As of today we've removed the Jinja2 disputed vulnerability.