Abelian Security Advisory ASA-2026-001
Coordinated disclosure of ABEL-001 to ABEL-004 · 12 October 2026
1. Summary
On 31 August 2026, independent security researcher byfor (GitHub: byfor8) privately reported four vulnerabilities to the Abelian Foundation, following a review of the public source code of the abec full node, the pqringctx and pqringct cryptographic libraries, and the abewalletmlp wallet.
The original ABEL-001–004 findings are mitigated in the code revisions listed in Section 3. Following an independent review of those revisions, the reporting researcher confirmed the mitigation on 22 September 2026. This confirmation concerns the specified code revisions; independently operated nodes and wallets must still upgrade to versions containing the fixes.
| ID | Severity | Component | Issue |
|---|---|---|---|
| ABEL-001 | Critical | pqringctx, pqringct, abec | Non-canonical key-image encoding allowed the same RingCT coin to be spent more than once |
| ABEL-002 | High | abewalletmlp | MLP wallet creation printed root seed material to standard output |
| ABEL-003 | Medium | abec | GetWork RPC server lacked authentication and bind restrictions |
| ABEL-004 | Medium | abec | Oversized P2P message allocation enabled memory exhaustion |
Section 5 explains what this advisory does and does not say about historical exploitation. Severity ratings follow the illustrative examples in Section 7 of our Vulnerability Disclosure Policy.
2. What you need to do
| If you are… | Action |
|---|---|
| A node operator, miner or mining pool | Upgrade to abec v3.3.0. Official downloads. Direct platform links are listed in Section 3. The reviewed source revision is listed separately there. |
| An exchange or custodian | Upgrade as above and confirm that all of your nodes run an official release containing these fixes. |
| A user who created a wallet with abewalletmlp | Upgrading to abewalletmlp v3.1.0 (official downloads in Section 3) removes this output for future wallet creation. It does not revoke secrets that have already been exposed. If output from wallet creation may have been read by an unauthorised party (for example through systemd journals, Docker or container logs, CI output, or shared terminal sessions), treat the affected wallet secrets as compromised. Create a new wallet with fresh keys using abewalletmlp v3.1.0 and move your funds to it. Restrict access to any logs that may contain the old output. Keep any copies needed as incident evidence in secure storage, and dispose of other sensitive copies under your data-retention process. |
| Operating the GetWork server | Leave the GetWork server disabled unless you need it. If you enable it (--enablegetwork), use an official release containing the fix and configure administrator rpcuser/rpcpass credentials; limited RPC credentials cannot call the mining methods. Keep TLS enabled, set rpccertgetwork and rpckeygetwork, configure mining clients to verify the certificate, bind the server to the intended interface using rpclistengetwork, and restrict access to trusted mining clients using network controls. If TLS is disabled with notlsgetwork, the listener is restricted to loopback addresses. Port 8668 is the default GetWork port on mainnet; other networks may use different ports. |
3. Verified revisions
The mitigation of ABEL-001–004 was verified at the following code revisions. The node and the wallet are listed separately.
| Component | Verified revision | Qualification |
|---|---|---|
| abec (node) | 08d27a8341685f9b7ae98e11eec86862ea763797 | Source version v3.3.0. Full package build and targeted unit and race tests passed. |
| pqringct | 6b50482b26a576d89573d5d3e320ecb6b5d9511d | Dependency pinned by the reviewed node. |
| pqringctx | d526987fdaa5326250bd83b69f4736e3eb0196bd | Dependency pinned by the reviewed node. |
| abewalletmlp (wallet) | 43bd1b09fd4f697668f3ea16e809251ebc83f482 | Includes seed-output fix 9b7e89d1d81c8fddb566052dc0d3fc1fcdc560d2. Internal verification was by source and diff inspection. |
The node packages tested were wire, peer, syncmgr, blockchain and the root package. This verification was not a full-wallet runtime test, and it does not certify that every possible denial-of-service issue has been eliminated. Later commits are not automatically covered by this verification.
Official releases: abec v3.3.0 and abewalletmlp v3.1.0. The official downloads page lists 28 September 2026 as the release date for both.
abec v3.3.0: macOS Apple Silicon | macOS Intel | Windows | Linux x64 | Linux ARM64
abewalletmlp v3.1.0: macOS Apple Silicon | macOS Intel | Windows | Linux x64 | Linux ARM64
4. Technical details
ABEL-001 (Critical): Non-canonical PolyANTT encoding produced distinct serial numbers for one RingCT coin
Background. A RingCT spend is valid when its ring signature verifies and its serial number has not already been recorded against the ring. The serial number is a hash of the serialised key-image polynomial.
Root cause. The polynomial serialiser encodes each coefficient as a signed 33-bit value. Before the fix, deserialisation checked only the number of coefficients. It did not check that each coefficient was in the canonical range, from −(q_a−1)/2 to (q_a−1)/2. Signature verification reduces coefficients modulo q_a, so a key image and a variant with a coefficient shifted by ±q_a are the same value algebraically, but they serialise to different bytes. The two versions therefore hashed to different serial numbers.
Impact. Only the owner of a RingCT output could exploit this. By re-signing with an alternate encoding, the owner could spend the same output more than once, creating ABEL not backed by an unspent output. Each extra serial number also used up a slot in the ring; once all slots were full, the remaining honest members of that ring could no longer spend their coins.
Fix. Coefficient range validation is now enforced in both the pqringctx and pqringct decoders, so non-canonical encodings are rejected before they can reach the serial-number hash.
ABEL-002 (High): MLP wallet creation printed root seeds to standard output
Root cause. During wallet creation, abewalletmlp printed the coin spend-key root seed and related root seeds to standard output before encrypting them into the wallet database. This output is separate from the mnemonic backup prompt.
Impact. Anyone who could read the process output (for example service logs, container logs or CI output) could obtain seed material sufficient to spend without the wallet passphrase.
Fix. The five seed print statements have been removed (commit 9b7e89d1d81c). Upgrading does not revoke secrets that were already exposed; see Section 2.
ABEL-003 (Medium): GetWork RPC server lacked authentication
Root cause. When enabled with --enablegetwork, the separate GetWork JSON-RPC server (default mainnet port 8668) did not authenticate callers, treated every caller as an administrator, and always listened in plaintext without the localhost restriction applied to the main RPC port.
Impact. Anyone who could reach the server could call the mining methods getwork, submitwork and submithashrate. The researcher's review found that coinbase rewards continued to be paid to the node's configured mining address, and identified the impact as disclosure of block templates and disruption of mining.
Fix. GetWork requests are now authenticated, and the mining methods require administrator RPC credentials. TLS is enabled by default, with a minimum of TLS 1.2 and dedicated certificate and key paths (rpccertgetwork, rpckeygetwork). Plaintext listeners are restricted to loopback addresses on all networks. These properties were confirmed by code-level checks, not by a dedicated endpoint integration test.
ABEL-004 (Medium): Memory exhaustion through P2P message size
Root cause. After the MLP/AUT upgrade, the maximum message payload in the source was 320 MiB. The need-set-result (nsresult) message accepted payloads up to that limit, and the node allocated the full length declared in the message header before reading the payload.
Impact. A single peer could cause memory exhaustion and make the node unavailable.
Fix. The node no longer initiates legacy needset downloads. Incoming nsresult messages are rejected at the header before their payloads are read or allocated, and a peer's claimed version cannot re-enable this receive path. Replacement downloads use full witness blocks or bounded pruned-block reconstruction with response validation, deadlines and cleanup. Serving incoming legacy requests remains for compatibility.
Follow-up hardening
The researcher also suggested additional validation at the serial-number helper and a lower legacy message-size ceiling. These are tracked as follow-up hardening and are not prerequisites to the confirmed mitigation of the original findings at the revisions listed above.
5. Exploitation assessment
The remediation verification does not determine whether these vulnerabilities were exploited historically. Any exploitation assessment will be reported separately with the investigation method, coverage and limitations, including automated analysis tooling under his direction and an independent verification pass on separate machines at the pinned revisions. Users should follow the applicable upgrade and wallet-exposure guidance above.
6. Timeline
| Date | Event |
|---|---|
| 31 August 2026 | Researcher reports ABEL-001 to ABEL-004 to general@abelian.info |
| 1 September 2026 | Abelian Foundation acknowledges receipt and begins triage |
| 22 September 2026 | Fixes committed to abec, pqringctx, pqringct and abewalletmlp. Researcher confirms the mitigation at the revisions listed in Section 3. |
| 28 September 2026 | Official releases containing the fixes published. Release date listed on the official downloads page for abec v3.3.0 and abewalletmlp v3.1.0. |
| 12 October 2026 | Coordinated public disclosure. |
7. Credit
We thank byfor (GitHub: byfor8) for reporting these issues responsibly, keeping them confidential during remediation, and independently reviewing the fixes.
8. Reporting vulnerabilities
The researcher could not find a dedicated security contact when he reported these issues. Our reporting process now identifies security@pqabelian.io as the dedicated contact and GitHub private vulnerability reporting as the preferred channel for sensitive technical details. The policy and security.txt references are listed below.
To report a suspected vulnerability, please use GitHub private vulnerability reporting on the affected repository (Security → Report a vulnerability). Alternatively, email security@pqabelian.io with "SECURITY" in the subject line. Ordinary email is not end-to-end encrypted, so please use GitHub private reporting for sensitive technical details. Do not report vulnerability details through public GitHub issues, pull requests or discussions.
References
- Abelian Vulnerability Disclosure Policy: https://pqabelian.io/security
- security.txt: https://pqabelian.io/.well-known/security.txt