✓ProveIt
Examples / Report #3295650 Saved analysis

Exposure of Hard-coded Private Keys and Credentials in curl Source Repository (CWE-321)

curl · 2025-08-1211.1s analysis · $0.013 in model calls

What the report claims

Hard-coded private keys and example credentials are embedded in the public curl source repository, exposing sensitive secrets that could be exploited.

Compare with curl's recorded outcome

Labeled AI slop

curl's maintainer lists this report as AI slop

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?
  • The central claim (C1) cannot be verified because the content of tests/data/testprivkey.pem and docs/examples/http-auth-example.txt is not provided in the curl_source. The deterministic checks only confirm file existence, not content.
  • Test private keys and example credentials in tests/ and docs/examples/ directories are common in open-source projects and are often intentional fixtures for testing, not production secrets. Without seeing the actual file contents, it is impossible to distinguish a real vulnerability from a false positive.
  • The project policy does not explicitly address test keys, but the 'Debug & Experiments' section suggests test-only artifacts are not security issues. The impact claims (C4) are speculative and depend entirely on the nature of the keys.
  • External sources confirm that hard-coded secrets are an anti-pattern flagged by tools like gitleaks, but do not address whether test fixtures in test directories constitute a vulnerability.
What still needs checking
  • Contents of tests/data/testprivkey.pem (full file)
  • Contents of docs/examples/http-auth-example.txt (full file)
  • Any documentation or comments in those files indicating they are test/example fixtures
  • Whether these keys are used in any production CI/CD, release signing, or infrastructure (vs. only in unit/integration tests)
How this analysis ran 5 claims · 0 citations verified

Checked against curl master on 2025-08-12 (efe871068c49). Test 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 · 1 references checked out, 0 did not
2 · Claims
NVIDIA-Nemotron-3-Nano-30B-A3B
5 claims · 1938 tokens · $0.0002
3 · Evidence
0 code snippets
real curl source at efe871068c49 · 6 docs via Tavily
4 · Judgment
Nemotron-3-Ultra-550b-a55b
8487 tokens · 7.9s · $0.0130
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 report. The repository does contain the files you mention (tests/data/testprivkey.pem and docs/examples/http-auth-example.txt), but we need to examine their actual contents to determine whether they hold real production secrets or intentional test fixtures. Could you please share the full contents of those two files, or confirm whether they contain headers/comments marking them as test-only? Many projects include test keys in tests/ directories for TLS/SSH test suites, which are not vulnerabilities. If these are production keys, we will treat this as a critical issue and rotate them immediately.

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

Report claims

C1flaw not verifiable

Embedding full private RSA keys and plaintext credentials in the public repository

Read the reasoning

The report claims that tests/data/testprivkey.pem and docs/examples/http-auth-example.txt contain full private RSA keys and plaintext credentials. However, the <curl_source> section explicitly states '(no curl code could be retrieved for this report)', so the actual content of these files is not available for verification. The deterministic checks confirm the revision is 'grounded' (files exist), but do not reveal file contents. Without seeing the file contents, it is impossible to determine whether these are real production secrets or intentional test/example fixtures (which are common in test directories and not vulnerabilities).

C2location supported

Repository root (./tests/ and ./docs/examples/)

Read the reasoning

The deterministic checks confirm the revision efe871068c49 (master on 2025-08-12) is grounded, and the report's reproduction steps reference ./tests/ and ./docs/examples/ which are standard repository locations. This claim about file locations is not disputed.

C3trigger supported

Cloning the repository and running gitleaks or grepping for '-----BEGIN' or 'password'

Read the reasoning

The reproduction steps (cloning the repo and running gitleaks/grep) are standard secret-scanning procedures and are not disputed. The deterministic checks confirm the repository is accessible at the given revision.

C4impact not verifiable

Attackers can impersonate curl services, decrypt traffic, pivot into build/CI systems, and cause supply chain attacks

Read the reasoning

The impact claims (impersonation, decryption, CI pivot, supply chain attacks) depend entirely on whether the keys/credentials in C1 are real production secrets. Since C1 is not_verifiable, the impact cannot be assessed. If the keys are test-only fixtures (common in tests/data/), the impact is negligible. The external sources (E1-E6) discuss general risks of hard-coded secrets and compliance standards but do not address whether test keys in a test directory constitute a vulnerability.

C5reproduction supported

git clone https://github.com/curl/curl.git; gitleaks detect --source=.; grep -r '-----BEGIN' ./tests/; grep -r 'password' ./docs/examples/

Read the reasoning

The reproduction commands are concrete and match the file locations in C2. They are not disputed.

What the report says about other projects

not addressed Use of hard-coded cryptographic keys is discouraged by security best practices and may violate compliance standards such as GDPR, PCI-DSS, and HIPAA.

confirmed Hard-coded secrets in source code are considered a security anti-pattern and are flagged by static analysis tools like gitleaks.

“| Gitleaks | Hardcoded secrets across Git history and source files | Gitleaks is the right secret scanner; AgentShield focuses on secrets flowing through tools, logs, responses, and agent context.” source

confirmed Hard-coded secrets in source code are considered a security anti-pattern and are flagged by static analysis tools like gitleaks.

“Explain the security risks of hard-coded secrets in source code. Configure and use GitHub Secret Scanning and push protection. Navigate and manage secret scanning alerts in GitHub repositories. Analyze security alerts using GitHub Copilot's Ask mode. Remediate hard-coded secrets using GitHub Copilot's Agent mode.” source

Read the original report (excerpt)

Full report on HackerOne ↗

Multiple private/test RSA keys and example credentials were discovered embedded in the public curl source repository and associated documentation. These sensitive secrets were detected using automated tools (gitleaks) and manual review. Their presence could allow attackers to impersonate trusted curl infrastructure, decrypt traffic, or pivot into build or CI systems if reused, creating a severe supply chain risk. Such exposures also risk compliance violations (e.g., GDPR, PCI-DSS, HIPAA) and undermine trust in open source releases. This report, including the verification steps and analysis, was prepared using an AI security assistant to ensure comprehensive and reproducible results. Affected version Confirmed in curl master branch as of August 2025. Also observed in prior tags (≥ 7.80.0) on Linux and macOS. Example version for testing: curl 8.1.2 (x86_64-pc-linux-gnu) libcurl/8.1.2 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.4 nghttp2/1.51.0 Release-Date: 2023-06-12 Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp ws wss Platform: Linux 5.15.0-83-generic x86_64 Steps To Reproduce: Clone the curl repository: git clone https://github.com/curl/curl.git Run a secret scanning tool (e.g., gitleaks detect --source=.) to identify hard-coded secrets. Alternatively, search for likely private key and credential strings with: grep -r '-----BEGIN' ./tests/ grep -r 'password' ./docs/examples/ Review identified files to confirm the presence of full private keys or functional credential examples, such as tests/data/testprivkey.pem or docs/examples/http-auth-example.txt. See .gitleaks/report.json for a consolidated findings report. Supporting Material/References: Example evidence: tests/data/testprivkey.pem containing full private key Example evidence: docs/examples/http-auth-example.txt with plaintext credentials Full scan log: .gitleaks/report.json (generated via gitleaks) curl/curl GitHub repository Screenshot evidence as required (available on request) Severity: Critical / CWE-321 (Use of Hard-coded Cryptographic Key) ## Impact ## Summary:The security impact of this vulnerability is severe and multi-faceted: Impersonation & Privilege Escalation: Attackers can use leaked private keys to impersonate curl servic …

Source code

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