The AppThreat vulnerability-db maintainers take security reports seriously. If you believe you have found a vulnerability in vdb, please report it privately through GitHub Security Advisories.
Use this private reporting link:
https://github.com/AppThreat/vulnerability-db/security/advisories/new
Please do not open a public GitHub issue for suspected security vulnerabilities. Public issues are appropriate for bugs, feature requests, documentation improvements, data quality issues, and hardening suggestions that do not expose users to immediate risk. For anything that could affect release integrity, published database artifacts, package installation safety, database query safety, credential handling, or downstream scanner results, use the private advisory flow first.
A good report usually includes:
- the affected version or commit
- the impacted component or file if known
- a clear description of the issue
- reproduction steps or a proof of concept
- expected behavior and observed behavior
- any constraints, assumptions, or exploit prerequisites
- your assessment of impact
If your finding involves a third-party dependency, upstream vulnerability feed, registry, GitHub, Hugging Face, GHCR, ORAS, SQLite/APSW, or an external workflow tool rather than vdb itself, please consider reporting it to the upstream maintainer as well. If the impact on vdb users is still meaningful, report it privately here and explain the dependency relationship.
After the initial report, maintainers will triage the finding, may ask for more detail, and will coordinate remediation and disclosure as appropriate.
The following response targets are best-effort goals, not contractual guarantees.
| Severity | Initial Response | Triage / Confirmation | Remediation Target | Disclosure |
|---|---|---|---|---|
| Critical such as release pipeline compromise, malicious published database artifacts, arbitrary code execution during default install/use, or compromise of GHCR/Hugging Face publishing | 48 hours | 5 business days | 15 business days | Coordinated with reporter |
| High such as SQL/query injection with practical impact, path traversal in custom data loading, unsafe artifact download behavior, token leakage, or vulnerability-result integrity failure with broad impact | 5 business days | 10 business days | 30 business days | Coordinated with reporter |
| Medium such as denial of service on crafted database/feed input, validation bypass with limited impact, misleading metadata indexes, or security control regression | 10 business days | 15 business days | 60 business days | Next suitable release |
| Low such as minor hardening gaps, verbose non-sensitive errors, documentation ambiguity, or low-impact defense-in-depth improvements | 15 business days | 30 business days | Best effort | Next suitable release |
When remediation is available, maintainers may publish a GitHub Security Advisory and request a CVE where appropriate.
The following classes of issues are generally in scope for vdb.
- Supply chain and release integrity issues. This includes compromise or meaningful weakening of Python package publishing, GHCR image publishing, Hugging Face dataset publishing, ORAS artifact generation, or workflow integrity.
- Published database artifact integrity issues. Reports are in scope if an attacker can cause public
.vdb6files, metadata, compressed artifacts, or tags to be malicious, misleading, or not traceable to the intended workflow. - Unsafe database handling. SQL injection, unsafe SQLite URI handling, path traversal through database paths, unsafe temp/journal behavior with security impact, or crafted database files that trigger unsafe behavior may be in scope.
- Unsafe source ingestion. Bugs that let crafted vuln-list, OSV, NVD, GitHub, npm, custom JSON/YAML/TOML, or zip inputs trigger code execution, uncontrolled file writes, credential leakage, or denial of service may be in scope.
- Credential or secret leakage caused by vdb. If
vdbexposes tokens, secrets, credentials, sensitive environment data, or registry credentials in normal output, logs, metadata, or published artifacts, that is in scope. - Vulnerability reporting integrity failures. A bug that can materially suppress, misstate, or poison results in a way that creates security risk for downstream scanners may be in scope.
- Unsafe download behavior. Issues in ORAS/Hugging Face/GHCR database download paths that allow unintended overwrite, unsafe extraction, trust bypass, or malicious artifact selection may be in scope.
- MCP server impact. Vulnerabilities in
packages/mcp-server-vdbthat expose data, execute unintended code, bypass expected tool boundaries, or misrepresent results are in scope.
The following are generally not considered vdb vulnerabilities on their own.
- Vulnerabilities in a user's project or package. If
vdbcorrectly reports a vulnerable dependency or OS package, that is a finding about the target, not aboutvdb. - Upstream feed data quality without a vdb-specific exploit. Missing, incorrect, delayed, or disputed data in OSV, NVD, GitHub, npm, or vuln-list is usually a data quality issue unless
vdbprocesses it unsafely or introduces a security-relevant misrepresentation. - Dependency CVEs with no demonstrated impact. Automated reports that only state that a dependency has a CVE are not enough. Please explain reachability or impact on
vdb. - Operator-controlled unsafe deployment choices. Running untrusted custom data, replacing database URLs with untrusted mirrors, or exposing local files through broad mounts may be important guidance but is not always a product vulnerability by itself.
- Expected behavior of SQLite or external package tooling. Report upstream unless there is a clear
vdb-specific unsafe delegation or trust-boundary bypass. - Debug or explicitly verbose output. Reports should show why the observed output exceeds what the chosen mode reasonably implies.
- Social engineering, phishing, or local workstation compromise. These are outside normal product scope unless there is a repository-specific exploit path.
- Scanner-only submissions with no reproduction or impact story. Reports need enough context to evaluate exploitability and product impact.
Some findings require case-by-case review.
- False positives and false negatives. Not every accuracy bug is a security vulnerability, but systematic suppression or poisoning of results in default workflows can be security-relevant.
- Environment variable poisoning.
vdbuses environment variables for paths, source selection, and workflow behavior. If a bypass meaningfully crosses trust boundaries beyond ordinary environment control, it may be in scope. - Large-feed denial of service. Memory, disk, temp-file, or journal growth is often a reliability issue, but crafted data that makes common workflows unsafe may be security-relevant.
- Custom data processing. Local custom vulnerability data is powerful and usually trusted. In hosted or automated flows, the impact depends on who controls the custom data path and files.
vdb sits at the intersection of vulnerability intelligence, SQLite storage, artifact publishing, and downstream scanner integrations. Security responsibility is shared between the project, its users, and upstream systems.
| Area | Responsibility | Key Controls |
|---|---|---|
| Own code safety | Preventing injection, traversal, unsafe defaults, and unintended behavior in the vdb codebase |
parameterized SQLite queries, safe temp-file handling, bounded batch processing, tests |
| Database artifact integrity | Publishing trustworthy .vdb6 and metadata artifacts |
pinned workflow actions, least-privilege permissions, reproducible builds, metadata, controlled publishing |
| Source ingestion safety | Handling large or malformed upstream feeds safely | cached fixtures, streaming downloads, zip filtering, row-count and size tests |
| Search integrity | Returning accurate package and vulnerability matches | deterministic conversion tests, version comparison tests, metadata index tests |
| Artifact hygiene | Avoiding accidental leakage through metadata, logs, or release assets | no token logging, environment review, artifact review |
| Timely remediation | Addressing genuine product vulnerabilities in maintained versions | private advisory intake, triage, fixes, and coordinated disclosure |
| Area | Responsibility | Guidance |
|---|---|---|
| Database source trust | Choosing where database artifacts come from | Prefer internal mirrors or workflows for production. Use public AppThreat artifacts as bootstrap/defaults. |
| Deployment safety | Running VDB and MCP integrations in an appropriate trust environment | Restrict access to local database paths and server/tool integrations. |
| Custom data trust | Controlling custom JSON/YAML/TOML vulnerability definitions | Treat custom data as trusted policy input. Review it before use in CI or hosted services. |
| Filesystem and temp space | Providing safe storage for databases and SQLite temporary files | Set VDB_HOME, VDB_CACHE, and VDB_TEMP_DIR to controlled paths with sufficient space. |
| Network egress | Controlling access to external sources and artifact registries | Pin internal mirrors when required and monitor artifact provenance. |
| Result interpretation | Making remediation decisions with appropriate context | Validate critical findings against upstream advisories and package context. |
Security fixes are normally applied to the latest released major version. VDB v6 is the maintained SQLite-based line. Older v5 users should upgrade unless they have a specific compatibility requirement.
Please allow maintainers time to investigate and remediate before public disclosure. Coordinated disclosure helps protect downstream scanners, CI users, and teams that mirror the public database artifacts.