Rusty Kaspa PR #1023 fixed an unbounded Stratum line buffer that a reachable client could grow before JSON-RPC parsing or miner authorization. The patch caps an incomplete line at 64 KiB and closes an over-limit connection. Miners and pool operators should run a build containing the fix and restrict unnecessary Stratum port exposure.
Key takeaways
- The vulnerable listener accumulated bytes until a newline arrived, with no maximum size for the incomplete line.
- The path ran before JSON-RPC parsing and miner authorization, so credentials did not protect an exposed listener.
- PR #1023 introduced
MAX_STRATUM_LINE_BYTESat 64 KiB and rejects a chunk before appending if it would cross the cap. - The patch bounds one line buffer; it is not a complete denial-of-service defense for every connection, protocol, or operating system resource.
- Operators should upgrade, bind narrowly, firewall the port, monitor rejections, and test normal miner reconnect behavior.
What was the Stratum memory-exhaustion issue?
The rusty-kaspa PR #1023 explains that spawn_client_listener read TCP data into line_buffer until it saw \n. A client could keep sending non-newline bytes while staying inside the five-second per-read timeout. Because the buffer had no cap, its memory use could continue growing for the life of the connection.
The important security boundary is timing. The listener buffered the line before parsing it as JSON-RPC and before authorizing a miner. Any client able to reach the Stratum listener could exercise the path, regardless of whether it knew a valid address, worker name, or password.
The PR reports the default listener as 0.0.0.0:5555. Binding to all interfaces can make a service reachable from more networks than an operator intends, depending on host, cloud, router, and firewall configuration. The existence of a default does not prove a particular deployment was publicly reachable; operators must inspect their actual socket and network rules.
How does the 64 KiB fix work?
The patch adds a constant named MAX_STRATUM_LINE_BYTES with a value of 64 KiB. A helper checks the current buffer length plus the incoming chunk before appending. If the addition would exceed the cap, the helper rejects it while leaving the existing buffer unchanged. The read loop logs the event and closes the connection immediately.
This order matters. Checking only after append would still permit a large allocation. Checking before append bounds the incomplete application-line data retained for that connection. The pull request says normal Stratum JSON-RPC messages are typically below 1 KiB, leaving substantial headroom for legitimate traffic.
The change is deliberately narrow: 24 additions and one deletion in the listener plus 51 test lines in the pull request’s file summary. It does not redesign Stratum authentication or message framing. It makes a previously unbounded resource bounded.
What should miners and pool operators do now?
First, identify the exact binary running the Stratum bridge and verify that its source or release includes PR #1023’s merged change. Do not assume that a package named “latest” on an image registry, pool appliance, or third-party download contains it. Record the binary version, image digest, build commit, and deployment time.
Second, reduce reachability to the minimum required set:
- bind the listener to a private or loopback interface when miners connect through a local gateway;
- allow only expected miner subnets or VPN ranges in the host and perimeter firewalls;
- remove broad cloud security-group rules for TCP 5555 unless a public pool genuinely needs them;
- place public endpoints behind connection-rate and resource controls appropriate for raw TCP traffic;
- keep management APIs and node RPC ports on separate, non-public paths.
Third, stage the upgrade. Connect representative ASICs, software miners, and proxies; submit shares; send reconnects; and confirm that valid messages stay far below the line limit. A custom extension that emits an unusually large single JSON line deserves review rather than a silent increase to the cap.
How can an operator verify the mitigation?
PR #1023 added five unit cases: normal data under the cap, incremental appends up to it, append at capacity, a single oversized chunk, and exactly-at-limit followed by one extra byte. The author also listed focused tests, Clippy, and formatting checks, while the merged PR page records passing repository checks.
In a controlled staging environment, an operator can test behavior at three boundaries: a valid short request, an incomplete line exactly at the maximum, and one byte over. The over-limit connection should close and produce the expected log without increasing process memory in proportion to continuing input. Never run an adversarial test against a production pool without authorization and a rollback plan.
Monitoring should include connection counts, rejected oversized lines, process resident memory, file-descriptor use, and restart events. A sudden cluster of over-limit rejections may indicate scanning, a misconfigured proxy, or abuse; the log alone does not identify intent.
How does this relate to other Kaspa node upgrades?
Security fixes and consensus upgrades have different urgency models. The Stratum patch protects a service boundary and was merged to master. A Toccata activation requires consensus-compatible node software and coordinated timing. Pool operators need both disciplines: rapid service hardening and carefully staged consensus releases.
The Kaspa Toccata launch-day guide covers operator readiness around a hardfork, while the rusty-kaspa v2.0.1 review focuses on later RPC and sync maintenance. Neither substitutes for confirming that the Stratum bridge build contains this exact patch.
Limitations: what this patch does not solve
A 64 KiB line cap limits one buffer per connection. An attacker may still consume sockets, TLS or proxy resources, kernel buffers, CPU, bandwidth, logs, or memory across many simultaneous connections. Rate limits, file-descriptor ceilings, connection timeouts, network filtering, and capacity monitoring remain relevant.
The patch also does not encrypt Stratum, authenticate peers before TCP acceptance, or repair vulnerabilities in third-party pool software. It has no published CVE or severity score in the cited PR, so this article does not assign one. Describing the reachable pre-authentication memory path is sufficient to justify prompt mitigation without inventing an impact rating.
Frequently asked questions
Does a strong miner password block this issue?
No. The affected buffering happened before miner authorization, according to the pull request.
Should operators simply raise the 64 KiB limit?
Not without a demonstrated protocol need and a security review. The cap was chosen far above the typical message size reported by the patch author.
Is firewalling enough without upgrading?
Firewalling reduces exposure but does not remove the vulnerable code for allowed or compromised clients. Use it as defense in depth alongside a patched build.
Source and verification note
This article is based on kaspanet/rusty-kaspa PR #1023, merged into master on May 29, 2026, and its linked issue #1017. The buffer path, five-second read timing, default bind, 64 KiB cap, rejection behavior, and unit-test cases come from the merged PR. Operators should map the merge commit to the current official release they deploy rather than relying on an assumed version number.
