✓ProveIt
Examples / Report #1213175 Saved analysis

CVE-2021-22922: Wrong content via metalink not discarded

curl · 2021-05-3011.9s analysis · $0.008 in model calls

What the report claims

When compiled with libmetalink and used with --metalink, curl checks cryptographic hashes but leaves files with incorrect hashes on disk, potentially assuming they are valid.

Compare with curl's recorded outcome

Known vulnerability

A real vulnerability: CVE-2021-22922 Wrong content via Metalink not discarded

Shown for comparison after analysis. The pipeline did not see this label.

ProveIt's finding

Needs human review

The available evidence does not settle the report. A maintainer should investigate.

Why this finding?
  • No curl source code was provided for the metalink hash validation implementation at revision 1c1d9f1affbd
  • Deterministic checks only confirm existence of 'validating' and 'FAILED' strings, not the file disposal behavior
  • The report describes a plausible security issue (failed hash validation should discard file) but the code path cannot be verified
  • External sources confirm metalink spec uses hashes for integrity verification but do not mandate implementation behavior on failure
What still needs checking
  • curl source code for metalink hash validation (likely in lib/metalink.c or similar)
  • Code showing what happens after hash validation fails (file deletion vs retention)
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2021-05-30 (1c1d9f1affbd). Dev evaluation split. Citation verification checks that a referenced line was in the evidence; it does not prove the model interpreted it correctly.

1 · Grounding
grounded
no model · 2 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 1365 tokens · $0.0002
3 · Evidence
0 code snippets
real curl source at 1c1d9f1affbd · 3 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
4527 tokens · 6.3s · $0.0076
5 · Receipts
0 of 0 citations verified
every citation must point at code the judge was shown
Review a draft reply to the reporter

Edit and verify before sending.

Thank you for the detailed report. The metalink hash validation behavior you describe is a plausible security concern. However, we need to examine the actual curl source code handling metalink validation (likely in lib/metalink.c) to confirm whether files with failed hash checks are retained or discarded. Could you point to the specific function or file where the validation result is handled? The deterministic checks show 'validating' and 'FAILED' strings exist in the codebase, but we need to see the implementation to verify the fix is needed.

Inspect all claims and source code 5 claims · 0 code excerpts

Report claims

C1flaw not verifiable

curl checks the cryptographic hash of downloaded files but does not discard files with incorrect hashes

Read the reasoning

No curl source code was provided to verify the metalink hash validation implementation. The deterministic checks only confirm that strings 'validating' and 'FAILED' exist in the codebase, but do not show the code path that handles hash validation failure or file disposal.

C2location not verifiable

The issue occurs when using --metalink with libmetalink enabled

Read the reasoning

Cannot verify the --metalink and libmetalink code paths without the curl source code.

C3trigger not verifiable

A metalink XML file containing an incorrect sha-256 hash causes the validation to fail but the file is still saved

Read the reasoning

Cannot verify the trigger behavior (file saved despite hash mismatch) without the curl source code showing the validation and file handling logic.

C4impact not verifiable

Modified or tampered files are kept and may be incorrectly assumed valid

Read the reasoning

Impact claim depends on C1 and C3 being true; cannot verify without code.

C5reproduction not verifiable

The reproduction involves building curl with --with-libmetalink, creating a metalink XML with an incorrect hash, and running curl --metalink

Read the reasoning

Reproduction steps reference code paths that cannot be verified without the curl source code.

What the report says about other projects

confirmed The metalink specification requires hash validation to verify file integrity

“Hashes are used to verify the integrity of a complete file or portion of a file to determine if the file has been transferred without any errors.” source

Read the original report

Full report on HackerOne ↗

## Summary: When compiled `--with-libmetalink` and used with `--metalink` curl does check the cryptographics hash of the downloaded files. However, the only indication that the hash was incorrect is a message displayed to the user. The files with incorrect hashes are left to the disk as-is. Since curl implements the hash validation and reports incorrect hashes there might be an expectation that files with incorrect hashes would not be kept either. Since the metalink can be used with insecure protocols such as http and ftp, the hash validation might be used an actual way to verify the download integrity against tampering. ## Steps To Reproduce: 1.Configure libcurl `--with-libmetalink` and build libcurl 2. Have metalinktest.xml with `<file name="testfile">` containing incorrect sha-256 hash for it. 3. Execute: `curl --metalink https://testsite/metalinktest.xml` The following message will be displayed: `Metalink: validating (testfile) [sha-256] FAILED (digest mismatch)` Yet, the downloaded file `testfile` with incorrect hash mismatch is kept. ## Fix It might be more sensible to download the file to a temporary name first, verify the hash and only then store the file to final name if the hash is correct. If hash mismatch is found remove the temporary file. ## Impact Modified or tampered files are kept and possibly incorrectly assumed valid

Source code

No source code was retrieved for this analysis. The evidence may be incomplete.