⬡ VITOCOIN SECURITY AUDIT REPORT CONFIDENTIAL

The merchant engine is seeded from a mnemonic phrase that is hardcoded as a string literal in node.py. Anyone with read access to the file (all three VPS root accounts, the Git repository history) can derive every payment address and their private keys for any index.

_merchant_mnemonic = 'cinnamon between manual satisfy off child deputy violin crowd shuffle never wrist'
_me = create_merchant_engine(chain.utxo, lambda: chain.height)
register_merchant_from_mnemonic(_me, 'vitocoin-merchant', _merchant_mnemonic, ...)

Both the Python and JavaScript implementations use PBKDF2-HMAC-SHA512 with only 2048 iterations for mnemonic-to-seed derivation. The BIP-39 reference spec recommends 2048 but this predates modern GPU cracking. NIST SP 800-132 recommends ≥310,000 iterations for SHA-256 and modern hardware can perform ~1 billion SHA-512 PBKDF2 iterations/second on a GPU, making brute-force of weak passphrases practical.

The export function serialises _wallets (which includes raw mnemonics and WIF keys) to a JSON file and triggers a download with no encryption or password protection.

_validate_block iterates over non-coinbase transactions and validates each against the current UTXO set without tracking which inputs are consumed by earlier transactions in the same block. If two transactions in the same block spend the same UTXO, the first will pass validation and remove the UTXO from the set, while the second transaction will correctly fail with "UTXO not found". However, a malicious miner constructing a custom block could craft a scenario where this ordering-dependent validation creates an inconsistency.

# blockchain.py _validate_block — UTXOs not tracked within-block
for tx in block.transactions[1:]:
    for inp in tx.inputs:
        utxo_out = self.utxo.get(inp.prev_txid, inp.prev_index)
        if utxo_out is None:
            return False, f"UTXO not found ..."
        # ← no set to track "already spent in this block"

The transaction signature preimage (sighash) does not include any chain-specific identifier. A signed mainnet transaction is structurally valid on testnet and vice versa. If a future hard fork is introduced without replay protection, transactions could be replayed across chains.

Both the module-level _rate_limit() function and the class-level RateLimiter derive the client IP from the raw X-Forwarded-For header without validating that the request originates from a trusted proxy. An attacker can set X-Forwarded-For: 1.2.3.4 on every request to appear as an arbitrary IP and completely bypass per-IP rate limits.

def _get_client_ip(handler):
    xff = handler.headers.get("X-Forwarded-For", "")
    if xff:
        return xff.split(",")[0].strip()   # ← no trusted-proxy check
    return handler.client_address[0]

The POST /tx endpoint accepts JSON with Access-Control-Allow-Origin: *. While signed transactions protect funds from fabrication, a malicious page could use fetch() to trick a user's browser into broadcasting a pre-constructed transaction that the user previously signed and the attacker captured. Combined with the wallet's session state stored in localStorage (accessible from the same origin), an XSS attack can directly broadcast transactions.

The API sends X-Frame-Options, X-Content-Type-Options, and Referrer-Policy but omits Content-Security-Policy. The Vercel-hosted frontend also lacks a CSP (confirmed in infrastructure audit). Without CSP, XSS payloads can exfiltrate localStorage wallet data to arbitrary external servers.

The miner registration function attempts to auto-ban IPs that claim >85% of total network hashrate. However, the threshold is computed against self-reported hashrate values submitted by miners themselves via the API. A malicious miner can report a tiny hashrate (e.g., 1 H/s) while actually submitting valid blocks. Conversely, a miner could report an inflated hashrate for competing IPs to trigger false bans.

# api.py _register_miner — ban check uses attacker-controlled value
network_hr = sum(v["hashrate_hps"] for v in _MINER_REGISTRY.values())
if network_hr > 0 and hashrate_hps / network_hr > 0.85 and hashrate_hps > 5_000_000:
    _MINER_BAN_LIST.add(ip)   # ← hashrate_hps is self-reported by the miner

The network currently has only 3 nodes, all operated by the same entity. SEED_NODES are the three VPS IPs; DNS seeds (seed1.vitocoin.net, seed2.vitocoin.net) do not resolve. With so few peers, eclipse attacks (surrounding a node with adversarial connections) are trivially achievable: an attacker running 4 nodes can disconnect a victim node from the honest chain.

The genesis block is created with nonce=0 and its hash almost certainly does not satisfy the stated GENESIS_BITS=0x1d00ffff target. The comment reads "For testnet/dev: accept genesis without valid PoW." This sets a precedent that the genesis block is a special case exempt from PoW, which is fine by convention — but the code comment could lead future developers to create dev environments with consistently invalid genesis blocks.

The orphan pool is capped at 5,000 blocks by count. A 4 MB block at maximum size means 5,000 orphans could consume up to 20 GB of RAM on a node, causing OOM. Orphan blocks should be limited by total memory weight, not count.