OSV v3 parser shares introduced/fixed commit patches across affected packages #2489

When an OSV advisory contains multiple affected blocks, parse_advisory_data_v3 puts all collected Git commits into each parsed package. Packages with only version ranges inherit commits too.

Reproduced on current main, commit 8af2bd39510f909c852c5cc086e9b56addc8c50a, with Python 3.12.14, univers==32.0.1, and packageurl-python==0.17.6.

Reproduction

Run this in the project's configured Django shell. The package names, repositories and hashes below are synthetic. Parsing these GitHub URLs does not fetch any repositories.

python manage.py shell

from vulnerabilities.pipes.osv_v2 import parse_advisory_data_v3

raw = {
    "id": "x_REPRO-OSV-COMMIT-SCOPE",
    "modified": "2026-11-03T00:00:00Z",
    "affected": [
        {
            "package": {"ecosystem": "PyPI", "name": f"demo-{suffix}"},
            "ranges": [{
                "type": "GIT",
                "repo": f"https://github.com/example/repo-{suffix}",
                "events": [{"introduced": intro * 40}, {"fixed": fixed * 40}],
            }],
        }
        for suffix, intro, fixed in [("a", "a", "b"), ("b", "c", "d")]
    ],
}
advisory = parse_advisory_data_v3(
    raw, ["pypi"], "https://example.org/advisory", ""
)
first, second = advisory.affected_packages
for package in advisory.affected_packages:
    print(package.package, len(package.introduced_by_commit_patches),
          len(package.fixed_by_commit_patches))
print(first.introduced_by_commit_patches is second.introduced_by_commit_patches)
print(first.fixed_by_commit_patches is second.fixed_by_commit_patches)

Actual output:

pkg:pypi/demo-a 2 2
pkg:pypi/demo-b 2 2
True
True

Each package contains both repositories' introduced and fixed commits. Expected output is 1 1 for each package and separate lists: demo-a should only have repo-a commits and demo-b only repo-b commits.

With a Git block and a version-only block in the same advisory, the version-only package receives the Git block's introduced and fixed patches in either order.

Cause

The parser initializes the two commit lists before the affected-package loop and passes them unchanged to every AffectedPackageV2. The constructor validates the lists without copying them, so the parsed advisory associates packages with other packages' commits.

The lists should be initialized for each affected block, alongside its version constraints. Multiple Git ranges within the same block should still accumulate into that block's lists.

I checked existing OSV issues and PRs, including #2080, #2066, #2116 and the current parser PRs, and found no report of this attribution bug. Tests using the real parser and classifier fail for two distinct Git blocks and for a version-only block in either order. The control with multiple Git ranges in one block passes.

I'd like to work on the fix. Would you welcome a PR that scopes the lists to each affected block and adds these regression tests?