Inconsistent API results for CVE-2017-14158 in scrapy

[harelhiluh]

CVE-2017-14158 affecting scrapy in versions: 0-2.13.3
checked with: curl -s https://api.osv.dev/v1/vulns/CVE-2017-14158 | jq .
results:
"events": [ { "introduced": "0" }, { "last_affected": "5f69ec98f70e1e1e5f65fb36eb1cfb23d0be5b45" } ]

Therefore, I would expect for querying 2.14.0 to be not vulnerable, however when I query I get a different range: [0.7,]
curl -s https://api.osv.dev/v1/query \ -H 'Content-Type: application/json' \ -d '{ "package": {"name": "scrapy", "ecosystem": "PyPI"}, "version": "2.14" }' | jq .
results:
"events": [ { "introduced": "0.7" } ]

It is hard for me to understand from that, which versions are vulnerable for srapy and which are not.

[another-rex]

It looks like even upstream there is some confusion of what this affects: scrapy/scrapy#482

There definitely seems to be some inconsistencies happening here, but I'm not sure whether this is something we can fix. What is happening here is there are 3 different records from 3 different upstream sources:

• osv.dev/CVE-2017-14158: We converted this from the upstream NVD entry, which only specifies version 1.4 as affected (the latest published version when the original CVE was published. This has not been updated properly since newer versions have been released and this was not fixed)
• osv.dev/PYSEC-2017-83 which says every single version is affected since 0.7, and has not been fixed. From what I understand this is the correct status of this vuln.
• osv.dev/GHSA-h7wm-ph43-c39p which was manually reviewed in 2022, and they put last_affected as 2.11.1. I believe this is also incorrect, as generally we recommend using "Fixed" for vulnerabilities that have been fixed. So this is likely to be an issue of this vuln not being updated when 2.11.2 came out and it having not fixed the issue.

@G-Rath It looks like you are actually credited as an analyst on this bug, do you happen to know whether this one is actually fixed or not?

[G-Rath]

afaik it's not fixed - I've got a credit because I was the one that bothered to update the advisory everytime a new version was released as GitHub policy is to always have a bounds on advisories unless a project is malware or unsupported; I stopped updating the advisory after Ackama migrated the only usage we had of the tool, in part because of this advisory.

For what it's worth, as I understand it the fix is to implement a high water mark as the vuln is your standard "tool that consumes input will crash if it gets input that is larger then the amount of resources it has"