Port 8333 – Bitcoin (Bitcoin Core P2P Mainnet Node)

Port 8333 is the default TCP port for the Bitcoin mainnet peer-to-peer (P2P) protocol — the channel that bitcoind / Bitcoin Core and other full-node implementations (Bitcoin Knots, btcd, bcoin, libbitcoin) use to gossip blocks and transactions to one another. An open 8333 means a machine is running a publicly reachable Bitcoin full node: it will complete a Bitcoin version/verack handshake with anyone who connects, announce and relay transactions, serve blocks, and hand out lists of other peers. Crucially, the P2P protocol has no authentication by design — the network is permissionless, so any peer is allowed to connect, and “unauthenticated” here is a feature of Bitcoin, not a misconfiguration. That doesn’t make an exposed node risk-free: the open port fingerprints the exact node software and version, invites peer-table and resource-exhaustion attacks, and pins the operator to whatever consensus/DoS bugs their build still carries. Note the port distinction up front: 8333 is the P2P port; the JSON-RPC control interface is 8332 (testnet uses 18333 for P2P and 18332 for RPC, signet 38333, regtest 18444). The wallet and private keys live behind RPC and never travel over 8333.

Why It’s Open

Port 8333 is open because someone is running a Bitcoin full node and either deliberately allows inbound connections or forwarded the port so other nodes can reach them. A healthy Bitcoin network depends on reachable nodes: they let newly-starting clients download the chain, propagate transactions and blocks quickly, and improve the network’s resilience. Bitcoin Core listens on 8333 for inbound peers by default whenever the node isn’t behind a NAT that blocks it, and node operators, exchanges, block explorers, Lightning routing nodes, and enthusiasts routinely publish a reachable node on purpose.

Because the protocol is peer-to-peer and permissionless, there is no login, no API key, and no allowlist between strangers on the network — a node must accept connections from unknown peers to do its job. Public node crawlers (the Bitnodes project is the best-known) continuously scan the internet for open 8333 and 18333 listeners and map the reachable network, so an exposed node is discoverable within hours. On a corporate host, an unexplained 8333 is worth a second look: it can mean sanctioned research or blockchain infrastructure, or it can mean a rogue/opportunistic node someone spun up on company hardware.

Common Risks

• Software + version fingerprinting. The version message a node sends during the handshake advertises its protocol version, service flags, block height, and a user-agent string (e.g. /Satoshi:25.0.0/ or /Satoshi:0.16.2/). That single field tells an attacker exactly which implementation and release you run — and therefore which unpatched consensus or DoS bugs to aim at. An old user agent is a targeting signal.
• Eclipse attacks / peer-table poisoning. An attacker who floods your node’s address manager with attacker-controlled IPs (via repeated addr messages) and grabs all your inbound and outbound connection slots can “eclipse” you — you then see only the attacker’s view of the network. That enables double-spend against the victim, N-confirmation attacks, and selfish-mining amplification. This is the foundational P2P risk on 8333, formalised in the 2015 “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network” research.
• Sybil attacks. Standing up large numbers of fake nodes to dominate a victim’s peer connections is the building block eclipse attacks rely on and a way to degrade the network’s gossip.
• Resource exhaustion / memory DoS. Malicious peers can try to exhaust a node’s memory or CPU with floods of crafted P2P messages (the INVDoS bug below is exactly this), or simply open many connections to consume slots and bandwidth.
• Consensus / DoS bugs. Bitcoin’s history includes real, remotely-triggerable crash and validation bugs (see the CVEs below). A node left on an old build is exposed to whichever ones it never patched.
• Simply being internet-exposed. An open 8333 is a stable, easily-crawled datapoint tying an IP (and often a rough geolocation and ISP) to “runs a Bitcoin node.” That’s an information-disclosure and de-anonymisation concern for some operators even when the node itself is fully patched.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

An external tester interacts with 8333 the way any other peer does — by speaking the Bitcoin P2P protocol. Remember the boundary: the handshake, peer list, and version banner are all reachable over 8333 without credentials, but anything that reads the node’s internal state (getnetworkinfo, getpeerinfo, wallet data) is RPC on 8332 and needs local access or RPC auth — you cannot run those against a stranger’s node.

Detect the service and version

nmap -sV -p 8333 <target>

Pull node info over the P2P handshake (Nmap NSE)

Nmap ships two safe, discovery-category Bitcoin scripts that complete the handshake for you:

# Extract protocol version, node/service flags, block height, and user agent
nmap -p 8333 --script bitcoin-info <target>

# Ask the node for its peer list (getaddr -> addr)
nmap -p 8333 --script bitcoin-getaddr <target>

bitcoin-info returns the version banner and user agent (your fingerprint), and bitcoin-getaddr returns known-peer addresses — the same addr data an eclipse attacker studies when mapping and poisoning a node’s peer table.

Confirm it’s really a Bitcoin node

# A raw connect will not do much on its own — 8333 speaks a binary protocol,
# not a text banner — but it confirms the port is answering.
nc -nv <target> 8333

A proper check requires sending a valid version message and reading the verack reply; the Nmap scripts above (or a small Python client using the Bitcoin message format) do this cleanly. A node that completes the handshake and answers getaddr is a live, reachable full node.

Map reachability from the outside

Public crawlers such as Bitnodes already index reachable nodes by IP, port, user agent, and country — checking whether a target IP appears there tells you how discoverable the node is and what version it advertises, without you touching it.

Inspect a node you control (RPC on 8332, not 8333)

If you own the node or hold RPC credentials, the local control interface — not the P2P port — is where the real state lives:

bitcoin-cli getnetworkinfo     # version, subversion (user agent), connections
bitcoin-cli getpeerinfo        # every peer, their user agents and addresses
bitcoin-cli getblockchaininfo  # sync height, chain, verification progress

Record every open 8333, the exact user-agent/version it advertises, and its peer exposure so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no “just being a node” CVE — an unauthenticated peer connection to 8333 is normal, permissionless behaviour. The vulnerabilities that matter here are implementation bugs in the node software (overwhelmingly Bitcoin Core / bitcoind), reachable over the P2P protocol, and the design-level P2P attacks the network has to defend against. Verify the exact user agent first, then match it to these:

• CVE-2018-17144 — The most consequential modern Bitcoin bug. Bitcoin Core and Bitcoin Knots 0.14.0 through 0.16.2 could be crashed (assertion failure / remote DoS) by a miner who mined a transaction spending the same input twice. More alarming than the crash was the latent risk that the same duplicate-input handling could have been used to inflate the money supply (create coins from nothing). It was disclosed conservatively as a DoS to buy time for upgrades, and patched in an emergency 0.16.3 release in September 2018. CVSS 3.1 7.5 (High).
• CVE-2018-17145 — “INVDoS.” A remote memory-exhaustion denial of service: a peer floods the node with many transaction inv messages carrying random hashes, driving unbounded memory growth (CWE-400). It affected Bitcoin Core / Knots 0.16.0–0.16.1 and a long list of forks (btcd, Litecoin, Namecoin, Bcoin, Decred), was fixed in 0.16.2, and is the textbook example of the “resource-exhaustion” risk on an exposed P2P port. CVSS 3.1 7.5 (High).
• CVE-2012-2459 — A Merkle-tree block-validation DoS in bitcoind / Bitcoin-Qt before 0.4.6, 0.5.x before 0.5.5, 0.6.0.x before 0.6.0.7, and 0.6.x before 0.6.2. Because Bitcoin duplicates the last hash on odd tree levels, an attacker could craft an invalid block with the same block hash as a valid one; a node that saw the invalid version first would mark that hash bad and then reject the legitimate block — a block-processing outage / incorrect block count. CVSS 2.0 5.0 (Medium).

Design-level P2P attacks (not CVEs, but the real day-to-day threat model):

• Eclipse attacks — monopolising a victim node’s peer connections by poisoning its address manager, so it only sees an attacker-controlled view of the chain. Not a single CVE; a class of attack Bitcoin Core has hardened against over many releases (more address buckets, feeler and anchor connections, block-relay-only peers), which is one more reason to stay current.
• Sybil attacks — flooding the network with fake node identities to dominate connections and enable the above.

Note on the previous version of this page. It framed port 8333 around “Bitcoin mining,” high CPU/GPU/power use, and “wallet exposure.” That framing is inaccurate: 8333 relays blocks and transactions — it is not a mining port (pool mining uses Stratum, and solo mining talks to a node over RPC/8332), and the P2P port does not expose the wallet or private keys, which live behind RPC. The two CVEs the old page cited (CVE-2018-17144 and CVE-2012-2459) were both checked against NVD, confirmed to be genuine Bitcoin Core issues, and are retained above; the INVDoS memory-exhaustion CVE was added, and eclipse/Sybil were reclassified from “exploits” to the design-level attacks they actually are.

Mitigation

• Keep Bitcoin Core current. Almost every CVE above is fixed in a modern release, and the eclipse-attack hardening only helps if you run it. Track releases and upgrade promptly — an old user agent on 8333 is an invitation.
• Decide whether you need inbound peers at all. A node works fine making only outbound connections. If you don’t need to serve other nodes, don’t port-forward 8333 or open it in the firewall — you lose nothing but discoverability. If you do serve peers, that’s a deliberate contribution, not a leak.
• Never expose RPC (8332). The P2P port is meant to be public; the RPC port is not. Bind RPC to 127.0.0.1, protect it with a strong rpcauth cookie/password, and firewall 8332 (and 18332) off every untrusted network. Unlike a web service on HTTP port 80 or HTTPS port 443 that sits behind its own auth layer, an exposed Bitcoin RPC is direct wallet access — treat it like any other sensitive internal daemon (a mistake as dangerous as an internet-facing Redis on 6379).
• Run behind Tor for privacy. If tying your IP to “runs a node” matters, expose the node as a Tor onion service so peers reach you without learning your address.
• Limit connections and resources. Cap maxconnections, run the node as an unprivileged user in a container or VM, and monitor memory/CPU so a resource-exhaustion flood degrades one sandbox rather than the host.
• On corporate networks, treat an unexplained 8333 as an inventory question. Confirm whether the node is sanctioned; if not, stop the service, firewall 8333/18333, and rescan to confirm it’s closed.

Real-World Example

The clearest real-world case on this port is CVE-2018-17144, disclosed in September 2018. A subtle change three years earlier had left every Bitcoin Core release from 0.14.0 to 0.16.2 crashable: a miner who included a transaction spending the same input twice would trip an assertion and take the node down. Worse, the same flawed duplicate-input handling opened the door to creating bitcoin out of thin air — a supply-inflation bug in the one system whose entire value proposition is a fixed, verifiable money supply. The developers judged the inflation angle too dangerous to publish immediately, so the fix shipped as an “important DoS” in an emergency 0.16.3 release while node operators scrambled to upgrade; the fuller inflation disclosure came only once enough of the network had patched. It’s the definitive port-8333 lesson: the open, unauthenticated P2P port itself is normal and expected, but the software behind it is the attack surface — and an operator running last year’s bitcoind is exposed to bugs the network already fixed.

FAQ

What is port 8333 used for?

Port 8333 is the default TCP port for the Bitcoin mainnet peer-to-peer protocol. Full nodes running bitcoind / Bitcoin Core (and compatible implementations) use it to relay transactions and blocks, complete the version/verack handshake with other peers, and share peer addresses. It is how nodes stay in sync with the blockchain. Testnet uses 18333, and the node’s separate JSON-RPC control interface is 8332.

Is it dangerous to have port 8333 open?

Open by itself, no — the Bitcoin network is permissionless and a reachable node is a normal, useful thing. The risks are indirect: the port fingerprints your exact node software and version (aiding targeting of unpatched bugs), exposes you to peer-table/eclipse and resource-exhaustion attacks, and makes the node crawlable. Keep the software current and it’s a reasonable service to run; leave it on an old build and it’s exposed to fixed CVEs.

Does an open port 8333 mean the machine is mining Bitcoin?

No — this is a common misconception. Port 8333 only relays blocks and transactions between full nodes. Mining pools use the Stratum protocol on their own ports, and solo miners talk to a node over RPC (8332), not over the P2P port. An open 8333 means a full node, which typically uses modest bandwidth and disk but not the heavy GPU/ASIC load of mining.

Is the wallet exposed through port 8333?

No. Wallet operations and private keys are handled through the node’s RPC interface (port 8332) or the local bitcoin-cli, never over the P2P port. The P2P protocol only carries public blockchain data. What you must protect is the RPC port — bind it to localhost, require authentication, and firewall it off untrusted networks.

Do I need authentication to connect to a Bitcoin node on 8333?

No, and that’s intentional. The Bitcoin P2P protocol is unauthenticated and permissionless by design — any peer can connect and complete the handshake. That is not a security hole in the port; the security work is in the node validating everything it receives and defending against malicious peers (eclipse/Sybil floods, resource exhaustion), which is why running a current, hardened version matters.

How do I check or close port 8333?

Scan it with nmap -sV -p 8333 <host> and pull node details with nmap -p 8333 --script bitcoin-info <host>; on a node you control, bitcoin-cli getnetworkinfo shows the version and connection count. To stop serving inbound peers, remove the port forward / firewall rule for 8333 (the node still works outbound-only), or stop bitcoind entirely if the node is unauthorized, then rescan to confirm the port is closed.

TL;DR

• Service: Bitcoin mainnet peer-to-peer protocol — bitcoind / Bitcoin Core and compatible full nodes relaying blocks and transactions (RPC is the separate port 8332; testnet P2P is 18333)
• Default port: 8333/TCP (unauthenticated and permissionless by design — not a misconfiguration)
• Biggest risk: version/user-agent fingerprinting that pins the node to unpatched consensus/DoS bugs (CVE-2018-17144 crash/inflation, INVDoS memory exhaustion), plus eclipse/Sybil peer-table attacks — the software behind the port is the real attack surface, not the open port itself
• Mitigation: keep Bitcoin Core current, only accept inbound peers if you mean to, never expose RPC/8332, consider running behind Tor, cap connections and sandbox the node, and firewall 8333 if nothing legitimately needs it