compute_content_id_v2 Produces Identical Hashes for Different Advisory IDs

Line 690 in 7975a38

elif isinstance(advisory_data, AdvisoryDataV2):

The input for the compute_content_id_v2 function is aliases, summary, affected_packages, references, severities, weaknesses, and patches.

Let’s say we have two AdvisoryDataV2 obj with the same severities but different advisory_id values. Since we don’t have aliases and advisory_id is not part of compute_content_id_v2, it will produce the same hash, which leads to ignoring these vulnerabilities.

Suse Scores data example:

CVE-2022-50034:
  cvss:
    - version: 3.1
      score: 5.5
      vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVE-2022-50035:
  cvss:
    - version: 3.1
      score: 5.5
      vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

yield AdvisoryDataV2(
    advisory_id="CVE-2022-50034",
    aliases=[],
    severities=severities,
    references=[],
    url=self.url,
)

aliases is already a part of computation of content ID, also even if the content ID is same. We have a unique together on advisory ID, data source ID and content ID. So even if we have same content ID we should have stored all advisories distinctively ?

@TG1999

@TG1999
the main problem is not in the model , yes we have unique together on advisory ID, data source ID and content ID
but insert_advisory_v2 function do only look up and create new advisory_obj using unique_content_id and url.

vulnerablecode/vulnerabilities/pipes/advisory.py

Line 319 in 7975a38

advisory_obj, created = AdvisoryV2.objects.get_or_create(

        advisory_obj, created = AdvisoryV2.objects.get_or_create(
            unique_content_id=content_id, <--- same unique_content_id
            url=advisory.url, <-- same url
            defaults=default_data, <-- the values used only for creation, not look up 
        )

@ziadhany

@ziadhany gotcha, then we should fix the lookup instead. An advisory should be located by advisory_id, data source and unique content ID. And not by unique content ID and URL.

@TG1999

@TG1999 Okay, I will create a quick fix for this and add a test.

Thanks! 🙇🏻

@TG1999

@TG1999 I think this will require either updating the model ( not recommended ) or modifying the unique_content_id function to include the advisory ID in its inputs.

Updating the lookup alone won’t work since unique_content_id is unique in our model:
https://github.com/aboutcode-org/vulnerablecode/blob/main/vulnerabilities/models.py#L2909

and we can't create two AdvisoryV2 that have the same unique_content_id .

@ziadhany

@ziadhany i see in that case we need to use advisory_id for computing unique content ID. Sorry for the oversight

this is done:

see:

Avoid producing identical hashes for different advisory IDs. #2164

Navigation Menu

Repository navigation

compute_content_id_v2 Produces Identical Hashes for Different Advisory IDs #2162

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

compute_content_id_v2 Produces Identical Hashes for Different Advisory IDs #2162

Description

Activity

TG1999 commented on Feb 13, 2026

ziadhany commented on Feb 13, 2026

TG1999 commented on Feb 13, 2026

ziadhany commented on Feb 13, 2026

TG1999 commented on Feb 13, 2026

ziadhany commented on Feb 13, 2026

TG1999 commented on Feb 13, 2026

ziadhany commented on Feb 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions