15 KiB
Executable File
Security review and production readiness — 2026-10-20
Decision: NO-GO for public production or valuable assets
Stage-1 follow-up: Node resource controls adds global admission/byte budgets, bounded canonical pages, browser cache/history limits and marketplace read improvements. SEC-01 and SEC-06 remain open: full-history client/reconciliation, DAG/disk growth and production-scale capacity evidence are not solved. Original source line references below describe review-time locations and may shift as remediation proceeds.
Stage-2 follow-up: Encrypted local wallets now provide explicit same-identity migration, encrypted-at-rest vault records and lock-aware signing sessions. SEC-03's original new-record plaintext-storage behavior is remediated after migration, but the production wallet hold remains: old plaintext copies, unlocked-page compromise and independent multi-browser/recovery review are not resolved. The historical finding below records the pre-remediation state.
This is an internal, source-assisted review with automated regression and dependency checks, not an independent security audit, penetration test, formal consensus proof, or production certification. The candidate has not been launched and no approval/attestation was set. Do not interpret passing tests, the existence of a mainnet profile, or the arrival of its candidate genesis date as permission to launch.
Scope: current consensus/ledger/P2P/RandomX integration, HTTP entry point, browser wallet/backups, marketplace authorization/accounting/reconciliation, Docker configuration and candidate startup gates. The operating hosts, real reverse proxy, public peers, wallets and funds were not accessed or assessed. No active Internet-facing adversarial load test or independent native-code audit was performed.
Findings that block production
Real-money settlement is not implemented end-to-end. The selected direction is direct Monero custody with a pooled liability ledger; no production deposit, credit, withdrawal, or customer-facing live settlement path exists. SEC-04/SEC-05 remain open.
Stage-4 follow-up: Operations/recovery tooling provides explicit trusted proxy IP/CIDRs, opt-in separate loopback diagnostics and aggregate monitoring checks, a proxy example (not installed), stopped-node SQLite pair snapshots/verification and new-directory restore. Native integration replays restored reference proofs and preserves marketplace identity/orders/receipts. SEC-07 and SEC-09 remain open pending intended-host deployment, off-host recovery and real alert/on-call evidence.
Stage-3 follow-up: Consensus calibration tools and evidence add an offline native benchmark and deterministic actual-helper scenarios plus validator timestamp regressions. Initial target is 16 expected hashes; a short quota-limited sample is not a network calibration. SEC-02 remains open pending representative hashpower, adversarial/multi-host evidence and independent review; no consensus/genesis change was made.
| ID | Priority / scope | Evidence and impact | Required disposition |
|---|---|---|---|
| SEC-01 | High · public node availability | HTTP full-state routes return full cloned canonical snapshots. The ledger retains all DAG nodes in memory; state-root calculation rebuilds the NFT set. Read cost and startup replay grow with chain/fork history. Per-IP request limits do not impose a global CPU, response-byte, memory or disk budget. | Bounded/paged public RPC and a compatible paged client; tested caching/indexing; validation admission budgets; disk/fork retention or a reviewed archival strategy. Demonstrate the intended workload and malicious traffic do not starve consensus or trigger OOM/disk exhaustion. Do not add an arbitrary consensus height cap. |
| SEC-02 | High · chain security | Initial target succeeds with probability approximately 1/16 per hash, and retarget uses ten-block windows. This is inherited testnet calibration, not evidence of a secure 15-minute production launch. Timestamp/retarget manipulation, hashpower concentration and private-chain rewrites require quantified analysis. | Independent consensus/economic review; measured launch hashpower; adversarial retarget/clock/partition simulations; choose and freeze final launch parameters and genesis before approval. Changing these changes chain identity. RandomX's shared algorithm does not inherit Monero's hashpower or security. |
| SEC-03 | High · valuable NFT keys | Browser wallet creation/storage persists an extractable P-256 private key without password encryption in IndexedDB. Encrypted portable backups do not encrypt that stored key. Same-origin script compromise, profile access or a sufficiently privileged extension can sign/export it. | A reviewed production wallet model with encrypted-at-rest storage/unlock lifecycle or isolated/hardware signing, explicit XSS threat model and tested recovery. Non-extractable keys alone do not stop malicious same-origin signing; storage encryption does not protect an already unlocked page. |
| SEC-04 | High · real-money marketplace | Payment adapter is deliberately mock-only. Buyer-controlled mock payment can lead a seller to sign a real card transfer. Listing reservations are not consensus locks. There is no reviewed live deposit/credit flow, seller XMR destination registration, treasury withdrawal reconciliation, fee-recipient payout, refund/dispute system or custody controls. | Keep real money blocked. For valuable cards, disable mock-sale delivery/listings or keep the entire deployment explicitly valueless. Implement and review the complete direct-custody ledger and treasury path; do not replace the mock adapter with a simple HTTP call. |
| SEC-05 | High · future live refunds/finality | NFT transfer signatures have no expiry/revocation and payment state is not a consensus commitment. A transfer absent during refund review may be rebroadcast or reappear after a reorg. An off-chain refund cannot cancel a previously signed NFT transfer. Recognizing current canonical delivery (fixed below) does not solve this general issue. | Explicit escrow/atomic-settlement design or a reviewed reserve/dispute/manual risk policy, late-payment/delivery rules, and recovery tools. Never promise trustless exchange or unconditional automatic real refunds. No finite confirmation count guarantees finality on a small PoW network. |
| SEC-06 | Medium · market availability | Reconciliation synchronously scans journal rows/chain and writes journal state. Public browsing invokes it. Lifetime 10,000-listing/order caps stop new business without a built-in archival workflow; signed unfunded bids and reservations have little economic cost. Nonces/receipts are not an economic spam defense. | Separate/cached read paths and indexed incremental reconciliation; measured event-loop/IO budgets; account/global anti-abuse policy; bounded receipt/storage management and a tested archive process that preserves payout/idempotency history. |
| SEC-07 | Medium · deployment availability | The app leaves Express proxy trust at its default. Behind a reverse proxy, IP-based limits may group clients under the proxy IP, allowing one client to throttle everyone. Conversely, blindly enabling proxy trust would permit spoofed forwarded IPs. Health reports process liveness, not peer synchronization, native-engine readiness or market reconciliation health. | Configure trusted proxy hops/CIDRs against the real topology; reject direct backend access and untrusted forwarded headers; apply edge/global limits and connection/time/body budgets. Add private monitoring for peer freshness, tip lag, reorgs, queues, RandomX failures, disk/WAL usage and market review states. Test actual TLS/HSTS/certificate renewal. |
| SEC-08 | Medium · release supply chain | Lockfile installation and the pinned RandomX commit help, but Docker base tags and OS package selection are mutable. Native self-tests and npm advisory checks are not native/container security scans. Current builds require network retrieval. | Pin reviewed base image digests and publish exact resolved dependency/toolchain/native revisions, SBOM, image digest/signatures and provenance. Scan the actual runtime image and native build; protect CI/release access. Add native fuzz/sanitizer and reproducibility checks. |
| SEC-09 | Operational blocker | Startup gates check configuration syntax/approvals/date, not actual independent review, peer independence/online status, TLS reachability, data recovery or economic security. No real topology, backups, alerting or incident ownership was verified here. | Named operator/reviewer sign-off with attached evidence, multi-host rehearsal and restore drill. Do not set independent-review-complete merely because this internal report exists. |
These are prioritized risks/readiness gaps, not claims that each is an already exploited vulnerability. In particular, the mock adapter cannot presently lose real XMR because it never sends or accepts any.
Fixed during this review
SEC-F01 · delivery submitted outside the market could be missed
Before the correction, reconciliation recognized delivery only using an order's stored transferId, which was set by the market's deliver command. A seller could pay/agree to a sale and submit its exact NFT transfer through the normal transfer endpoint, CLI or peer gossip. The market saw the buyer own the card but had no stored delivery identity, so it could classify the paid order as refund-required. That created incorrect mock accounting and would be dangerous if copied into live settlement.
The new deterministic delivery identity derives from the agreed card, seller, buyer, sequence and chain, independent of submission route/signature bytes. Canonical and pending checks and the refund guard use that identity. Direct delivery of an unpaid order enters review instead of triggering a payout. Regression tests cover direct canonical delivery, direct pending delivery, refused duplicate refund, and unpaid delivery. This does not solve SEC-05's late/reorged-signature problem.
SEC-F02 · overly broad Docker build context
The prior Docker exclusions covered only dependencies and compiled UI. The build stage's COPY . . could incorporate local environment files, ledger/market databases, Git history, host native binaries or wallet backups into build layers/cache. No evidence of an actual leaked secret was obtained, and no sensitive files were intentionally opened to investigate.
Added exclusions for the data directory, Git metadata, environment files, common wallet/backup/database/private-key formats, host native builds and editor state. This is defense in depth, not a guarantee against an arbitrarily named secret. Build from a clean controlled checkout, keep secrets outside the build tree, and review images/cache access. If a sensitive checkout was previously built or pushed, assess exposure, remove affected artifacts according to retention policy, and rotate affected secrets; a later ignore rule does not remove an old layer.
Controls checked and retained
- Network/chain/signature domain separation, strict public-key/curve/SPKI checks and NFT sequence/maturity validation. Both counterparties sign atomic card trades.
- SQLite transactional ledger updates and serialized mutations; no automatic reset on chain mismatch/corruption. Marketplace instance/actor/action/nonce/expiry binding and fee policy signatures.
- Fixed peer-origin configuration, bounded uncompressed responses/timeouts, DNS answer checks and connection-pinned lookup, no automatic redirect following. Fixed Wikimedia HTTPS sources and bounded API responses.
- Pinned upstream RandomX source commit, bounded native input parsing and subprocess queues, shell-free spawning, and secure JIT/W^X flags. No selectable fake PoW production fallback.
- Local backup PBKDF2-SHA256 / AES-256-GCM with authenticated headers, bounded input, key-pair validation and network checking. This is separate from the browser-storage issue above.
- Non-root runtime, dropped capabilities, no-new-privileges, read-only root and separate data volume in candidate Compose. These settings do not establish host security.
- Mock-only payment enforcement on all profiles; fixed 1% fee rate/recipient is public policy, not a hardcoded secret. It is disclosed and bound to sale signatures and order accounting. Existing orders are not silently repriced.
Intentional behaviors not reported as vulnerabilities: first-seen equal-work ties; exact auction deadline rejection; delivery window beginning at payment; seller delivery recipient checks; fail-closed handling of corrupted persisted transactions; and keeping settled orders in manual review after reorg rather than risking a second payout. The source checks the buyer and sequence on each delivery; a claim that an alternate recipient can be submitted through that endpoint was not supported.
USD authorization followed by a separately displayed XMR quote is not itself a critical exploit in this mock-only implementation. A future live checkout must bind/review the actual invoice ID, currency, destination, amount, expiry and fee allocation at the payment authorization step; that work remains part of SEC-04.
Checks performed
- Node 24 TypeScript/Vite build: passed.
- Full suite after corrections: 78 passed, 0 failed, 0 skipped, including real reference RandomX known-vector/build coverage and two-node HTTP marketplace/transfer integration. Tests include the new read-only preflight and direct-delivery regressions.
- npm production-only and full dependency advisory queries: 0 known advisories reported for the locked tree at review time. This does not cover unpublished issues, malicious packages, Alpine/Node/native vulnerabilities or registry availability. Repeat against the final artifact before release.
- Fixed fee address decoded independently as 95-character Monero Base58, 69 decoded bytes, prefix 18 (mainnet standard address); Keccak-256 checksum matched (
c752185b). This proves formatting/checksum only, not ownership or intended recipient. Verify control out of band before any future live transfer; never share seed/private keys. - Mainnet preflight exercised with approvals absent: reports
NO-GO,productionReady: false,paymentMode: mock; no node/ledger/network startup. Mainnet manifest/configuration remains candidate-only.
Not performed: independent audit, production-host penetration test, adversarial sustained load/fuzz campaign, private-key/hardware review, actual XMR deposit/credit/withdrawal, real peer/miner independence validation, or a production backup/restore exercise. See operator launch procedure for evidence required before explicit approval.