Unhandled exception happened: 'hashes'

[danrossi]

Checklist

• I agree to the terms within the Safety Code of Conduct.
• I have searched existing issues to ensure this bug hasn't been reported before.

Safety version

3.7.0

Python version

3.13

Operating System

Windows 11

Bug description

After multiple attempts to upgrade vulnerable packages. Pipenv check is failing with the following error. It was just working before. It's a clean shell environment.

Account: API key used
 Git branch: master
 Environment: cicd
 Scan policy: None, using Safety CLI default policies

Python detected. Found 1 Python Pipfile lock file
Unhandled exception happened: 'hashes'

pipenv check --scan  --key apikey

or

safety scan  --key apikey

Steps to reproduce

1. safety scan --key apikey

Command and output

Account: API key used
 Git branch: master
 Environment: cicd
 Scan policy: None, using Safety CLI default policies

Python detected. Found 1 Python Pipfile lock file
Unhandled exception happened: 'hashes'

Additional context

No response

[github-actions]

Hi @danrossi, thank you for opening this issue!

We appreciate your effort in reporting this. Our team will review it and get back to you soon.
If you have any additional details or updates, feel free to add them to this issue.

Note: If this is a serious security issue that could impact the security of Safety CLI users, please email security@safetycli.com immediately.

Thank you for contributing to Safety CLI!

[Palodeaza]

Hi everyone! I've been investigating this issue and managed to track down the root cause.

The KeyError: 'hashes' isn't actually happening directly inside Safety's core logic, but rather in the upstream dparse library that Safety uses to read dependency files.

When dparse parses a Pipfile.lock, it loops through all dependencies and strictly expects a "hashes" key for every single one. If your project has even one dependency (like a specific local package or a custom install) that didn't generate a hash, dparse crashes completely and aborts the Safety scan.

I've just submitted a PR #887 that fixes this. I added a pre-processing step that intercepts the Pipfile.lock content and safely injects an empty "hashes": [] list into any dependency that is missing it before handing it over to dparse. This stops the crash and allows the scan to complete successfully.

It would also be a huge help if you @danrossi could tell if the package 'hashes' or similiar where included in the Pipfile lock file. That way we could narrow even more the scope of where the crash happened.

Let me know if it works!