VertexChain is currently pre-1.0 and under active development. Security reports are accepted for the default branch and the most recent public release, when a release exists.

Please do not open a public issue for a suspected vulnerability.

Primary contact: security@vertexchain.io

Use GitHub private vulnerability reporting when it is available for this repository. If private reporting is not available, email the address above or contact maintainers privately and include enough detail to reproduce and assess the issue.

Operational channel: #vertexchain-security (internal Slack)

Helpful details include:

• affected component: Frontend, Backend, contracts, infrastructure, or analytics
• vulnerable endpoint, contract method, or user workflow
• steps to reproduce
• expected impact and affected users
• proof-of-concept code, screenshots, or logs when safe to share
• suggested fix or mitigation, if known

Do not include secrets, private keys, seed phrases, wallet credentials, or real user data in the report.

The project aims to follow this response process:

Complex blockchain, infrastructure, or data-integrity issues may require more time. Maintainers will share status updates when remediation is still in progress.

Please give maintainers a reasonable opportunity to investigate and remediate before sharing details publicly. Coordinate disclosure timing with maintainers, especially when an issue could affect user funds, location privacy, identity privacy, data integrity, or service availability.

Public disclosure should avoid publishing exploit-ready details until users have a fix or mitigation path.

Reports are especially valuable when they affect:

• Soroban contract authorization, state integrity, or asset movement
• location privacy or deanonymization risks
• backend authentication, authorization, or rate limiting
• API access to private or sensitive user data
• frontend wallet interaction or transaction-signing flows
• infrastructure configuration that could expose secrets or production data
• IPFS content integrity or cache poisoning

Out-of-scope reports include:

• vulnerabilities that require compromised user devices or browsers
• social engineering or phishing without a technical platform flaw
• denial-of-service findings based only on extremely high traffic volume
• reports against third-party services not controlled by VertexChain

Good-faith security research is welcome when it:

• avoids privacy violations and data destruction
• does not access, modify, or exfiltrate data that is not needed for the report
• does not disrupt service availability
• is reported privately before public disclosure

Maintainers will not pursue action against good-faith researchers who follow this policy and avoid harming users or the project.

This section documents the primary attack paths for VertexChain, the mitigations in place today, who owns each control, and where the implementation lives in the repository. It is intended for coordinated disclosure, security review, and onboarding — not as a formal certification.

Client (browser / wallet)
    │  POST /gists, CSRF token, rate limit
    ▼
Backend API (NestJS)
    │  sanitize → IPFS pin → Soroban tx → Postgres + Redis cache
    ▼
Soroban (GistRegistry contract)          IPFS / Pinata gateway
    │  on-chain gist_id + content_hash       │  pinned JSON blobs
    ▼                                        ▼
Indexer worker (event poll → upsert)     Cached reads (Redis)

Threat path: An unauthenticated caller floods POST /gists, posts oversized or malicious HTML content, or submits invalid coordinates to pollute the map feed.

Residual risk / planned work

• No backend moderation queue or automated spam classifier is wired to block posts.
• Rate limits are IP/session scoped via NestJS throttler; per-wallet limits are not enforced when author is omitted.
• Track follow-up in Issue #186.

Threat path: An attacker supplies or substitutes a malicious IPFS CID, poisons the Redis cache with tampered gist rows, or serves stale content that no longer matches the on-chain content_hash.

Residual risk / planned work

• No read-time re-fetch from IPFS with CID/content-hash verification before serving cached gists.
• No strict CID format validation (multibase/multihash checks) on ingest.
• Dev mode generates mock CIDs when Pinata keys are absent — must not be enabled in production.
• Track follow-up in Issue #186.

Threat path: A caller replays or duplicates gist-registration events, posts gists without authorization, or causes the indexer to apply stale/conflicting ledger data into Postgres.

Residual risk / planned work

• Add require_auth() (or signed-invocation checks) to GistRegistry::post_gist before mainnet.
• Wire IndexerModule into AppModule and add a UNIQUE constraint on stellar_gist_id so upsert dedup is enforced at the DB layer.
• Deduplicate by tx_hash / ledger sequence in addition to stellar_gist_id.
• Complete real Soroban RPC integration (mock mode bypasses chain-level replay guarantees).
• Track follow-up in Issue #186.

• Contributing — security reporting
• Infrastructure security hardening
• Architecture — security overview
• Security runbooks
• Contract README