Incidents

The LNbits team said that, as a precaution, it has disabled all instances on its own hosted service. According to the project, services should resume within 24 hours.

The official Electrum account announced release 4.8.4 and described it as another security update. The vendor publishes release notes and binaries via the link in the post. The announcement does not say which specific flaw is fixed.

The LNbits project reported a wave of attacks and said it has a number of security patches to release. Until they are available, the team advises stopping LNbits servers as a precaution. The announcement gives no vulnerability details and no list of affected versions; further updates are promised.

LNbits has issued a precaution for all operators: if the Paywall extension is enabled, disable it immediately while the team investigates a potential bug. The source does not describe the nature of the flaw, affected versions, or whether a fix exists, and the message does not confirm any exploitation.

Keystone says the expected iOS app update is now live and advises users to update. The message was posted in the same thread as the earlier notice about a cyberattack on Nexus App services. The vendor does not name an iOS version number in this message.

Blink says that if the Spark operators vanish, the 12-word seed phrase alone cannot recover your bitcoin on-chain. You also need a snapshot of the wallet state made while the operators were online. Starting with release 3.0.46, the app keeps such a snapshot: it is created after your first transaction, refreshed after every payment, and saved together with your cloud backup. In July the vendor ran a unilateral exit itself on mainnet with a real wallet and 100,000 sats, using open-source tooling, and documented every failure. The vendor's posts have the full write-up.

Keystone says some Nexus App services were recently hit by a cyberattack, and for a period some users could not use the app normally. The team responded and hardened server security. Based on the vendor's investigation so far, there is no evidence that user assets or personal information were affected. Version 1.3.7 adds further security hardening. It is live on Google Play for Android, and the iOS version is, per the vendor, awaiting App Store review.

According to myNode, the Raspberry Pi kernel with the fix for the TCP vulnerability (CVE-2026-98432) has been released. Previously this platform had no kernel fix, and the v0.3.52 release included only mitigations. The vendor has described how to install the kernel on MyNode OS v0.3.52.

Start9 announced the Trusted Keys mechanism in StartOS 0.4.1.2: every operating system and service update is checked for a signature from developers you trust. If an update is not signed by any of the keys you have chosen, StartOS stops the installation and shows a warning. The operator decides which developers to trust.

In its quarterly report, Blockstream says Jade firmware 1.0.41 shipped in August and fixes issues found through dozens of AI-assisted scans and human reviews of the Jade code. The Jade firmware developers recommend upgrading as soon as it can be done safely. The report does not disclose details of the flaws. The company says Jade itself was unaffected by the security incidents of the quarter. It also says firmware 1.0.42, with fixes for less serious findings, is on a shorter development timeline.

Keystone says the order check page it promised is now live. A customer enters the email used when placing the order, completes a CAPTCHA, and sees whether the order was affected by the incident. The result "No matching record found" means the order was not affected. According to the vendor, the entered email is not stored, and affected users' email addresses are kept in the database only as hashes. The vendor also warns that the page asks only for an email: any request for a recovery phrase, private keys or a payment is a scam.

Alby Hub v1.24.6 is described as a patch with bug fixes and security updates. Changes include validating swap-out and refund addresses against the hub's network, rejecting app public keys that are not valid points on the curve, disabling MPTCP by default in Hub binaries, and no longer reusing IDs of deleted rows after a database migration. The source gives no details of the underlying vulnerabilities and no signs of exploitation.

The vendor announced Bisq2 v2.1.15 and described it as an important security update. It adds a sandbox to isolate the Tor process and includes the latest Tor security release and Java security updates. According to the source, updating to this version is required to continue trading. The announcement does not describe specific vulnerabilities or defects.

The Bisq project has released version 1.10.11, which the vendor calls an important security update. It adds a sandbox that isolates the Tor process and includes the latest Tor security release and Java security updates. The vendor states that updating is required to continue trading. The source does not name specific vulnerabilities or report any exploitation.

The release lists security-related changes: credentials, keys, seeds and other sensitive data are wiped from memory once no longer needed; user sighash flags are validated before signing with any signer, including hardware signers; in multisig, the PIN password returned by the server must be at least 36 characters, and the value and asset of explicit Liquid UTXOs are taken from the transaction rather than from the server. It also fixes a use-after-free when websocket clients are destroyed (Wamp), rounds up the RBF replacement fee as Bitcoin Core does, and reports out-of-range output indices as user errors. The source does not describe a vulnerability, exploitation or urgency.

The Core Lightning project says point release 26.06.10 fixes vulnerabilities reported responsibly by a number of researchers, and strongly recommends upgrading as soon as practical. The fixes cover signature checks on the peer's tx_signatures in dual funding and splicing, HTLC resolution in onchaind, gossip resource limits, connectd, runes and commando, plugin hooks and hsmd, plus a number of remote-crash and hardening fixes. There is no embargo: the release and its fixes are available immediately. The project is temporarily withholding the tests for the security fixes, to make it harder to quickly turn the fixes into working exploits and to give users more time to upgrade. Reproducible amd64, arm64 and armv7 binaries are provided for Ubuntu 22.04, 24.04 and 26.04 (amd64 also for Fedora 40), along with multi-platform Docker images.

The vendor announced Liana v16.0 and listed among its changes a fix for an RBF attack that a malicious Electrum server could carry out. The announcement does not explain how the attack works; the vendor points to its blog post for details. The release also adds BIP138 encrypted descriptor backups, Taproot by default, address labels inherited by coins and transactions, a reworked interface, and new interface languages (French, Italian, Brazilian and European Portuguese).

Blink 3.0.46 requires an authenticator code to add an email or phone number or to turn off two-factor authentication. 2FA is now suggested as a custodial balance grows and required above a set amount, with the option to move to self-custody instead. The release includes security fixes to the app lock, PIN lockout and PIN fallback, and blocks screen capture on cloud backup and restore, recovery phrase entry and authenticator setup. Self-custodial wallets now keep an encrypted recovery bundle, updated after every payment, with its last-update date shown in the app and verifiable even when Blink's services are unavailable.

Nutshell 0.22.0 includes, per the release notes, security fixes and hardening across mint accounting, authentication, seed handling, logging and request validation. The notes do not describe the individual defects or whether they are exploitable. The release also includes mint database migrations, BIP-39 mint seed support via MINT_MNEMONIC (MINT_PRIVATE_KEY is deprecated but still supported), in-memory response caching without Redis, and changes to Lightning payment handling. A patch is available.

According to myNode, release v0.3.52 mitigates CVE-2026-98432 and also includes a NodeJS upgrade for CVE-2026-111497 and a Bitcoin upgrade for CVE-2026-117349, plus new firewall rules. The vendor says the fixes are required to prevent possible unauthorized access and control of the device. On Raspberry Pi, an error message may remain on the home page after the upgrade because no kernel update with the TCP fix is available for that platform; for such devices the release includes mitigations: LND v0.21.6, new firewall rules and MPTCP disabled.

Release notes for the Blink mobile wallet prerelease 3.0.44 list changes to access protection. The app lock is now kept in place through the logout it triggers. The escalating delay after incorrect PIN entries is back and keeps growing after the attempt limit is used up. Seed-phrase screens are now gated by the screen guard and fail closed. This implies that earlier builds could let the lock be interrupted during logout, had no escalating PIN lockout, and did not reliably protect seed-phrase screens with the screen guard. The release also adds Enhanced-mode telemetry behind an Incognito privacy gate. The source describes this as a prerelease and gives no exploitation details or deadlines.

On 1 November 2026 the vendor received reports of Bitcoin and Litecoin stolen from BTCPay Server hot wallets. Its investigation found the attacks targeted servers running 2.4.1 (released 23 July 2026) or earlier, using a different method to exploit the vulnerability fixed in 2.4.2 (7 August 2026). Further security updates followed, including 2.4.4 and 2.4.5. The vendor stresses that updating cannot remove access an attacker may already have gained, and that an unchanged wallet balance does not rule out an earlier attack. It has not established when exploitation began. Funds in wallets whose spending keys are held off the server, including hardware wallets, were not affected by these thefts, and the vendor still recommends accepting payments into such wallets.

After its incident response investigation, the BTCPay Server team says the attack vector it identified targets instances running version 2.4.1 (July 23, 2026) or older. The vendor has no credible reports of hot wallet drains for users on the latest release, 2.4.7. It again urges everyone to keep BTCPay Server updated and asks anyone affected to send all details and logs to its security contact given in the announcement. If your instance runs through a hosting provider, it may have been shut down automatically to keep older versions from being exploited. The vendor thanks hosting providers for their swift action after its initial announcement.

A BTCPay Server developer reports that on affected instances an attacker was able to log in as an administrator; the team is still working out how. According to the developer, the attack reports concern installations before 2.4.2, and the project's own public servers running 2.4.7 were not attacked. The cause and the full list of affected installations are not stated.

Umbrel has released umbrelOS 2.0.1 as an important security update. On Umbrel Home, Umbrel Pro and other x86 devices, it includes a Linux kernel patched for the recently disclosed CVE-2026-98432. On Raspberry Pi, where a patched kernel is not yet available, umbrelOS blocks the network traffic needed to trigger the vulnerability. The same release fixes a HEIC decoder vulnerability triggered when generating a thumbnail of a specially crafted image, removes trust in certificate authorities recently distrusted following a security incident, hardens the updater and includes recent Debian security updates.

The release fixes XSS (user-controlled data is escaped and order logs are stored as JSON), adds coordinator checks of reward sources and buyer payouts against Lightning node data with an optional withdrawal limit, fixes repeated crediting of collateral from a single slashed bond, and updates Django and Pillow. The changelog names fixes for two GHSAs, but the fix for one of them is subsequently marked as reverted. The Tor bundled with the Android app has been updated: according to the release, the previous Tor version can no longer connect to the network.

Start9 reports that StartOS 0.4.1 has been published and contains important security updates, and asks users to update as soon as possible. The vendor's message does not identify the nature of the issues fixed.

According to myNode, release v0.3.52 fixes CVE-2026-98432 and includes other security fixes and mitigations: a kernel update with a fix for PC platforms, LND v0.21.6 with an MPTCP mitigation, and disabling MPTCP on Raspberry Pi. The message does not disclose details of the flaws.

The vendor reports that v0.3.52 is now available: it includes kernel updates where available and mitigations for other platforms, as well as LND v0.21.6 with an additional fix. The vendor still provides no details of the defect; on platforms without a kernel update, the release provides mitigation rather than an updated kernel.

Start9 has released start-cli 2.6.0, in which the commands for mounting a backup, obtaining backup information, restoring a package and adding/editing a CIFS target read the password from a hidden prompt instead of a positional argument; automation must switch to the BACKUP_PASSWORD and CIFS_PASSWORD variables, while PASSWORD remains a separate credential for CLI authentication. In the same release, package installation and OS update operations on StartOS 0.4.1 and later require an enabled trusted signer by default, while the new --trust flag allows this to be overridden while retaining mandatory signature and integrity checks; the auth session kill command now accepts --pubkey and --token instead of positional session identifiers.

According to lnd, releases v0.20.7 and v0.21.6 contain a Go-specific mitigation — disabling the MPTCP flag — for CVE-2026-98432, a use-after-free in the Linux kernel's IPv4 TCP implementation. The source stresses that this is a kernel-level vulnerability: only a kernel patch fully fixes it, since any network service may be affected; known PoCs use MPTCP, but other vectors are not ruled out. The developers recommend that all users update.

In addition to the previously announced vulnerability, vendor myNode has released a new mitigation: an iptables rule to run in a Linux terminal on the node itself.

The myNode vendor has announced a security vulnerability affecting all nodes, and a patch with mitigations and fixes “where available” later the same day. According to the vendor, switching to Tor-only in settings may help, but the best measure is to remove remote access to the node or temporarily shut it down; the message suggests a kernel update may not yet be available for Raspberry Pi. The vendor gives no details of the defect.

A post by a BTCPay developer, retweeted by the project's official account, asks owners of BTCPay Server Docker installations to run the updater: a critical Linux vulnerability is being patched automatically on all machines. The message does not name the vulnerability or provide technical details or an identifier; the change is accompanied by a link to a pull request in the btcpayserver-docker repository (links in the post).

The vendor reports measures in response to its incident: shipments have been suspended, affected devices are being quarantined at all warehouses, including Amazon facilities; shipping data retention has been reduced from 180 to 90 days, and affected users have received emails from the official support address. Separately, the vendor warns that emails about the incident come only from this address, that it never asks for a seed phrase, and promises to explain the next steps in the coming days.

The post (a researcher's retweet) reports that an implant has been found not only in Ledger devices but also in Trezor devices sold by reseller CryptoBilis since March 2026. This concerns a specific reseller's sales channel, rather than purchases directly from the vendor. The author invites owners of suspicious devices to contact him for analysis and offers to cover shipping. The post provides no evidence that anyone's funds have already been withdrawn; the vendor has published its own statement about the reported implant.

Through its responsible disclosure program, Trezor received a report of one Trezor Safe 5 with a hardware implant, bought from reseller CryptoBilis in August 2026; the device itself has not yet been provided to the vendor, but it considers the report credible and is warning buyers in advance. No CryptoBilis customer has reported a loss of funds to the vendor. On October 9, 2026, Trezor removed CryptoBilis as a reseller following reports of tampered Ledger devices sold through it; no signs of tampering were found in the four Trezor devices inspected since then.

On its account, the BTCPay Server team describes 2.4.7 as an emergency update that fixes one critical and several medium-severity vulnerabilities; they were reported through an open-source code scanning program, and the vendor is not disclosing details. The vendor recommends updating as soon as possible, and asks node platform users to install the update as soon as it becomes available there.

The vendor published an analysis of the consequences of its website breach. Confirmed: order data for 2024–2026 may have been exposed, and the attacker has the web authentication key. According to the vendor, this key can be used to build a counterfeit device that passes authenticity checks as genuine, so hardware wallets received on or after October 20, as well as packages in transit, are suspect. The vendor considers devices delivered before October 20 unaffected and recommends checking them using the previous verification page. The firmware signing key, according to the vendor, is separate from the leaked key and unaffected; the vendor says firmware updates are safe. All stock of the current model has been designated for destruction, and new orders are being taken as preorders with new keys and a 4–6-week lead time. The page for checking whether you are affected is not yet live. There is no released fix for the key leak itself: it will only be addressed by changing the keys in the next batch.

The vendor has released 2.4.7 and describes it as a bug-fix release addressing security, reliability and payment accounting issues; the scan report lists 85 findings fixed (1 Critical, 13 High, 52 Medium, 19 Low), with details of Critical and High findings deliberately withheld. The named fixes include: canceled payouts can no longer be reopened to bypass pull payment limits; confirmation policies and expiry limits apply to anonymously created BitPay API invoices, reading an individual invoice requires authentication, and supplied tokens are checked against the authenticated identity; cases where forms, search, notifications and Greenfield listings exposed another store's data or forms have been fixed; 2FA attempt limits have been strengthened for concurrent logins; LNURL-auth challenges expire after five minutes and are invalidated when credentials change; cached addresses are checked for ownership by the current wallet after replacement, deletion or multisig setup. The vendor strongly recommends the update, particularly for servers shared by several merchants. The legacy /invoices/create routes have also been removed in favor of /stores/{storeId}/invoices/create.

The vendor has released Sparrow v2.5.6: eMudhra root certificates have been removed from the build, and the bundled Tor has been updated to the client protocols currently required by the Tor network. The release also lists improvements to screen-reader support and keyboard operation. The source does not give reasons for removing the certificates or details of the defect.

In release 2.5.6, Sparrow verifies the signatures of its own inputs before adding an unconfirmed transaction to the wallet history — the fix was ported from Electrum following its security advisory (the release is linked in the post). Other additions include: verifying recipient input signatures in payjoin before checking the proposal fee, comparing saved block hashes with the header store on the wallet's first load and re-querying the script hash during a reorganization, marking a confirmation as unverified if its block has been replaced, rejecting output descriptors without extended public keys (including addr()), checking the claimed number of cosigners when importing Electrum multisig wallets, extending the wallet lock to label imports, sweep, message signing and password requests, deleting a backup only after saving a password change, and additional checks for Satscard, Tapsigner and Satschip operations. Separately, the bundled Tor has been updated to meet network requirements, and eMudhra root certificates have been removed from the bundled Java trust store.

According to Bitcoin Core's disclosure, platforms other than Linux use a select()-based socket monitoring backend that monitored exceptional socket conditions regardless of whether reading was paused. By sending TCP urgent (out-of-band) data, a malicious peer bypasses backpressure and forces the node to queue an unbounded amount of data; the source says that, in practice, this makes it trivial to crash any Windows, macOS or BSD node to which the attacker is connected. Severity is rated Medium; only the select() code path is affected, and Linux nodes are unaffected. Fixes were released in versions 29.5, 30.4, 31.2 and 32.1.

Bitcoin Core adds announcements to the send queue even for peers marked as paused because the queue is full. Peers that do not support nonced ping (BIP 31) are not disconnected after the 20-minute timeout, so a malicious peer can pretend to be one and deliberately read messages slowly — memory grows without limit, estimated by the source at up to 2 MB per hour per inbound peer and up to 5 MB per hour per outbound peer. The project rates the issue as Medium severity and easy to detect; nodes using -blocksonly are affected significantly less because transaction announcements make up most of the queue. Fixes have been released in versions 29.5, 30.4, 31.2 and 32.1.

According to Bitcoin Core's disclosure, positions within rev*.dat were stored as 32-bit integers, while undo-file sizes were unrestricted: a miner can mine blocks with disproportionately large undo data, causing new records to overwrite old ones and the file to be truncated. During a reorg, the node then cannot read the undo data and shuts down; restarting does not help. On Windows and 32-bit systems, the node crashes during writing, even without a reorg, and does not start after a restart. The source classifies the issue as Low severity and considers exploitation on 64-bit systems practically infeasible (non-standard transactions, thousands of blocks, and precisely matching a particular node's file layout). The fix — 64-bit positions and 64-bit positioning calls on Windows — was released in 29.5, 30.4, 31.2 and 32.1; the on-disk format has not changed. According to the report, 32-bit systems and nodes whose blocks directory is on FAT32 remain affected even after updating.

The release announcement says a path has been fixed where a transaction sent through sendrawtransaction with -privatebroadcast=1 could go directly over IPv4/IPv6 when falling back from P2P v2 to v1, bypassing the enforced route through the Tor proxy. Additionally: build 32.0 was tagged but never fully released, and branches 29.x and older have been declared End of Life and will receive no further updates; the source promises disclosure in two weeks of medium- and high-severity vulnerabilities fixed in 30.0 (3 in total).

Foundation has released Envoy 2.3.7, continuing the preventive security work started in 2.3.6. The Passport Prime security check has moved to a new onion address and gained an additional layer of verification; behavior where screenshot protection did not persist when switching from seed words back to the seed QR screen has been fixed. The vendor recommends that all users update.

The release extends the long coinbase maturity soft fork deployed in 29.4.2: rewards for blocks 979919 and later are delayed further, while the 45-day maturity for the 973440–979918 epoch is retained. According to the authors, starting at block 980019, a node on 29.4.2 may accept blocks that this version rejects, and miners on 29.4.2 may produce such blocks from block 986399. The release also fixes a crash during an RPC call and a wallet crash during importdescriptors with a range; the source separately describes known transaction virtual size bugs and the lack of updated translations.

According to ACINQ, this is a patch release with security-hardening fixes, and some of the issues addressed could be exploited by hostile nodes; the vendor strongly recommends updating. A configuration parameter has also been added to control whether unconfirmed inputs may be spent during a splice (not allowed by default). The issues were responsibly disclosed by an external researcher; detailed release notes are linked in the post.

The release discussion reports that v31.1 fixes a path where a connection in -privatebroadcast mode could go over clearnet despite a private network being enabled. The author advises everyone using this mode to update without delay. The message contains no details of the defect or information about exploitation.

According to the release, version 1.2.0 did not serve pure Ed25519 signatures to StartOS 0.4.0.3 servers even though they support them: such updates appeared unsigned, and the interface refused to install them. In 1.2.1, these signatures are served, and 0.4.0.3 servers can once again update the OS to releases signed with keys in gpg. SHA-256 and BLAKE-3 checksums are provided for the amd64, arm64 and riscv64 package builds.

According to the developers, v2.8.5 updates dependencies to address disclosed vulnerabilities and adds stricter transaction validation to protect against malicious servers; verification of signatures on the wallet's own transactions and coinjoin stability fixes are also announced (amounts below 10,000 sats can no longer be queued for coinjoin payments). Sending BIP78 payjoin transactions has been removed — the feature will stop working. Separately, five years ago a clipboard bug in the macOS UI silently truncated and corrupted complex passphrases containing non-ASCII characters when pasted, and these wallets cannot be restored using standard BIP39 tools; the workaround for them will soon be removed.

The vendor has released BTCPay Server 2.4.6 and describes it as another release focused on security, with additional hardening primarily around dependencies. The announcement does not name specific defects; the vendor thanks independent security researchers for their help and refers readers to the full changelog (links in the post).

The release fixes a number of security defects responsibly disclosed by researchers: restricted API keys now stay within their granted store and user permissions, even if the key owner is a server administrator; only absolute HTTP/HTTPS redirects are accepted in key authorization and invoice requests in the Greenfield and BitPay-compatible APIs; new subscriptions can no longer take over existing accounts; sanitization of custom HTML/CSS and handling of untrusted input in the API, wallet, forms, webhooks and Payjoin requests have been strengthened; logging out requires a protected POST. .NET and the Ubuntu container's trusted certificate store have also been updated for the Brotli decoder vulnerability (CVE-2026-111497) and to revoke trust in certificates affected by the compromise of the eMudhra CA key. Breaking change: the deprecated invoice-level notificationEmail option has been removed.

According to the vendor, monitoring detected unauthorized access to the official website on October 20, 2026: an attacker escalated privileges through a vulnerability in a third-party data monitoring system, obtained some customer data and the WebAuth key used to verify device authenticity. The breach affected 25,964 customer records from 2024–2026 containing names, contact details, shipping addresses and order details, as well as 12,873 incomplete checkouts containing names, contact details and shipping information; purchases through Amazon and other channels were not affected. The vendor says the vulnerability has been fixed and unsafe website functions disabled; according to its information, recovery phrases, private keys and payment data were not affected. The key leak makes it possible for a counterfeit device to pass the authenticity check — production has switched to a new key, 18,835 devices in warehouse stock with the old key will be destroyed, and shipments of website orders have been suspended.

According to a researcher's account shared by the vendor, malicious advertising leads to an intermediate “link verification” page: it retrieves the current fraudulent site address from a blockchain contract, allowing the operator to change domains at will, and redirects the visitor to a lookalike domain. There, a commercial fingerprinting service assesses the browser, device, IP and behavior: visitors who look like bots, researchers or scanners are sent to the vendor's real website, while others see a fake “Passport recall” asking them to enter 12 seed words or “create a new vault” whose words the attackers already have. The operator has an admin panel for manually banning and redirecting individual visitors.

According to myNode, the CVE-2026-111497 security issue has been fixed in NodeJS, which runs RTL, Thunderhub and other node applications. myNode v0.3.51 installs the fixed NodeJS, and the home page now warns if NodeJS on the node is out of date. 32-bit devices and Debian 10 remain on NodeJS 18, which will not receive this fix.

Keystone reports that it discovered unauthorized access to its website on October 20, and on October 23, after reviewing API activity with Shopify, confirmed that a third party had obtained customer data: names, contact information, shipping addresses and order details (products and prices). According to the vendor, payment and banking details, recovery phrases, private keys and wallet passwords were not affected. Access has been blocked, the vulnerability has been fixed, an investigation is under way, affected customers are being emailed, and a detailed report has been promised later. The practical risk is targeted phishing and physical targeting: knowing a name, address and order contents lets scammers convincingly impersonate the vendor by phone, SMS, email and postal mail, offering refunds, “device replacements” or an “order correction.”

According to the advisory, a server connected to a lightweight client can “swallow” a broadcast transaction and show a conflicting forgery in the history with the same inputs but an output to the attacker's address; the forged transaction's signatures were not checked because of the lightweight client's design. If the user manually increases the fee on that transaction, they sign and fund a transfer to the attacker. The developers report that some servers are carrying out this attack in practice: they received two private reports from users, one of whom lost funds; the forged address was chosen so that its last four characters matched those of the legitimate address. The fix is included in version 4.8.3 — the client verifies signatures for its own (is_mine) inputs in mempool transactions; “incoming” transactions with other people's inputs are still not validated. The advisory is linked in the post.

The disclosure describes Core Lightning versions v25.02–v26.04 crashing on receipt of a channel_announcement whose node_id_1 and node_id_2 identify the same node: gossipd does not check that the endpoints differ, triggering a duplicate assertion. The announcement is written to gossip_store before loading, so the crash repeats on every restart and the node stays offline until the operator manually removes the entry. All an attacker needs is a controlled, unspent 2-of-2 output, so the cost amounts to the on-chain fee. According to the disclosure, the fix was released in v26.04.1; the current release at the time of publication is v26.06.9.

About two weeks ago, several owners of Ledger hardware wallets in Asia discovered outgoing transactions and empty balances. Researchers found soldered implants in these devices that read the screen contents and transmitted the seed phrase out through a cellular modem. Current information indicates that a single Ledger reseller in Asia made and installed the implants, then sold the devices to customers and other stores. Neither an authenticity check nor correct firmware detects this modification: the genuine device continues to operate normally while the added electronics remain unnoticed.

Researcher Joe Grand found a replacement microcontroller with malicious firmware in two devices — a Model T from Facebook Marketplace (Canada, 2025) and a Trezor One from a TikTok shop (August 2026, shipped from China). Instead of a random recovery phrase, the device produces one of roughly a dozen hardcoded by the attackers, meaning they know the keys from the outset. Integrity checks are bypassed using a copy of the official firmware (on a soldered microSD card or in the second half of flash memory). The Trezor One owner's funds have already been stolen: the current version of Trezor Suite flags this unit during verification, but allows the user to continue using the device. Both models have been discontinued, but are still being bought on the secondhand market; Trezor has publicly stated that there is no evidence of its devices being compromised and is reducing the number of authorized sellers.

The Core Lightning project reports on its channel that older versions of the webpki-roots dependency continue to trust compromised emSign intermediate certificates, which may expose HTTPS requests to MITM attacks. CLN's own code and the Lightning protocol are not affected: the issue is limited to the currencyrate plugin, which is enabled by default. The risk arises when using this plugin's commands and when configuring currency conversion for the bookkeeper plugin. The BIP353 plugin is not affected in practice because it relies on DNS and ignores the vulnerable certificate verification path.

A post by the lead lnd developer discusses CVE-2026-111943 — the compromise of certificate authority eMudhra, which means the root certificate trusted in the builds can no longer be considered reliable. Users of lnd, btcd, tapd and litd are affected: the compromised CA undermines trust in the daemons' TLS connections, the channel carrying RPC connections and the node's external traffic. Releases built with a corrected trust set have already been published for all four projects; the alternative is to rebuild them yourself with Go 1.27.3.

The project team reports a CVE related to the compromise of the eMudhra certificate authority and strongly recommends that users of lnd, btcd, tapd and litd either move to fresh release binaries or rebuild their own from source using Go 1.27.3. The trusted set of root certificates used by the node's TLS connections and related services is affected. While a node runs an old build, its connections trust certificates from the compromised authority.

BTCPay Server's Docker installer includes an optional WooCommerce/WordPress deployment; it was updated following disclosure of a critical PHP vulnerability. Merchants whose WooCommerce stores were deployed specifically through the BTCPay installer are affected. Until the update is applied, the publicly accessible PHP stack of the payment frontend remains on a vulnerable version. The message does not give a CVE number or details of the vulnerability's nature.

ACINQ's official channel announced the Eclair 0.14.5 release, which includes security fixes, and explicitly recommended that node operators update. The message contains no details about the nature of the issues or whether they were exploited. Operators of Eclair Lightning nodes are affected: channel funds and node availability depend on this software.

Since October 9, people who bought Ledger devices through authorized reseller CryptoBilis (Malaysia, Indonesia, the Philippines) have been reporting empty wallets; Ledger confirmed that the affected device contained an unauthorized hardware implant. The implant does not touch the secure chip or change the transactions being signed — it reads what the screen displays, decodes the 24 words during initial setup and sends them out over a mobile network using an eSIM, so the device passed the built-in authenticity check. Ledger says all confirmed losses are linked to this reseller, while its direct sales channel shows no signs of compromise; the total has not been officially confirmed, and blockchain researchers estimate losses of $86–93 million across more than 300 wallets. Separately: on October 13, a major European retail chain suspended Ledger sales after a customer in Germany reported an implant, while an inspection of warehouse and retail stock in Germany found no signs of tampering.

ACINQ has published an Eclair patch release fixing a set of security issues. According to the vendor itself, some of them could be exploited by hostile nodes; the vulnerabilities were reported through responsible disclosure. Operators of Lightning nodes running Eclair are affected; the release is fully compatible with previous versions, and channels do not need to be closed.

ACINQ has released Eclair v0.14.4, a patch release containing security fixes, most of which came through the Loupe project. According to the developers, some of the issues can be exploited by malicious nodes, and updating is strongly recommended. Operators of their own Eclair Lightning nodes are affected: a neighboring node with malicious intent has a way to affect your node until it is updated.

According to the project, log files in Bisq versions 2.1.3–2.1.13 contain the onion private keys of all node identities and, when the API is enabled, user profile private keys as well. The released version 2.1.14 is described as an important security update: it fixes vulnerabilities found during the project audit, includes a recent Tor security release, adds Bisq Easy trade checks (offer and price matching, reputation limits, and amount checks in Bitcoin URIs and Lightning invoices) and storage signatures. On first launch, 2.1.14 removes keys from logs in its own data directory, but all other copies remain exposed: logs previously sent to anyone, backups and docker logs output. A separate announcement states that all nodes must update to 2.1.14 or later by November 25, 2026, otherwise connectivity and data transmission problems will begin.

Ledger is officially asking resellers and distributors in Indonesia, Singapore, Thailand, the Philippines, Vietnam, Malaysia and Hong Kong to suspend sales and remove devices from shelves while the investigation continues. Someone tampered with devices somewhere in the supply chain; confirmed wallet-draining incidents are currently limited to Southeast Asia, and the vendor has not confirmed cases involving devices bought in other regions. According to the vendor, Ledger's own infrastructure, services and direct sales channel show no signs of compromise. Devices received from support staff will be analyzed by the vendor's internal laboratory.

Unchained reports a developing Ledger supply-chain incident: according to the company, Ledger notified it of an issue with devices distributed through a Southeast Asian reseller (CryptoBilis) and the European retail chain MediaMarkt Saturn. Unchained has not yet identified compromised Ledger devices in client vaults, and there have been no notifications of problems with devices from other sales channels. The risk is direct: a substituted or opened device means the seed may have reached third parties, putting funds held under that key at risk.

Ledger reports that, as of October 13, MediaMarkt Saturn has stopped selling Ledger signers in stores and online in agreement with the vendor — prompted by a report from one customer in Germany who found an implant inside a device. No loss of funds has been reported, and there are no signs of compromise of the vendor's infrastructure or services. Ledger support is handling user reports, and the Donjon laboratory will examine the devices it receives. The risk concerns those who bought a device from this retail chain: hardware tampering means potential access to the secret stored on the device.

Ledger Donjon is investigating Ledger signing devices sold by reseller CryptoBilis in Southeast Asia: an unauthorized hardware implant was found inside the casing. The vendor confirmed the finding on October 10 in a device belonging to one victim. The implant reads data displayed on the screen and, when the 24 words of the recovery phrase are shown during initial setup, decodes them with a microcontroller and transmits them over LTE through a built-in eSIM. It is a separate component: the device's Secure Element and operating system are unchanged, and transactions and signatures are not substituted. All confirmed losses of funds associated with the October 9 incident involve signing devices purchased through this reseller; the vendor has not confirmed any theft from a device bought elsewhere. The reseller said it had stopped selling Ledger signing devices for the duration of the investigation. The vendor has not confirmed the total number of victims or the amount lost; the figures circulating online come from third parties and have not been fully verified. The vendor is also investigating reports of implants in other devices and regions. There is no patch here, and there cannot be one: this is physical tampering with the device, and an exposed recovery phrase remains compromised.

The vendor reports that, as of October 12, it is still locked out of Coldcard's official social media account and is waiting for the platform to restore access. This means the account that previously published a phishing post remains outside Coinkite's control.

The vendor reports on its channel that all confirmed cases of drained wallets in the October 9, 2026 incident involve devices sold through reseller CryptoBilis in Southeast Asia. This concerns physical substitution or modification of devices on their way to the buyer; the vendor says its own systems and direct sales channels are not affected. The number of affected devices is described as limited, the investigation continues, and affected customers are being notified individually. There is no patch here: the problem is in the supply chain, not the firmware.

A package named crypto-tax-export has been published on RubyGems, with a native extension build script that executes during gem installation itself. Before running its payload, it checks that this is a real developer workstation rather than a sandbox (CI variables, temporary hostnames and usernames, analysis paths, low uptime, the presence of SSH keys, RubyGems credentials and git configuration), then forks a background process, waits a random number of tens of minutes and uses eval on a base64 payload to open a shell to a hardcoded external host in a reconnection loop. The gem has none of the advertised tax export functionality: the README and native target name were copied from an unrelated Bitcoin RPC package, so the cover story is aimed at Bitcoin developers. The result is full interactive access to a machine holding SSH keys, package publishing tokens and wallet source code.

The package is published on RubyGems as nft-metadata-resolver, but its README describes it as the bitcoin-rpc-lite library, and the native extension build target is named accordingly, although the package contains no actual C/C++ code. The native extension script, which RubyGems runs automatically during `gem install`, decodes a base64 payload and launches it in a detached child process; the payload connects over TCP to a hardcoded IP address and forwards /bin/sh input and output there, giving the remote party an interactive shell on the machine performing the installation. Execution is guarded by anti-analysis checks: CI, sandboxes, “analysis” usernames and hosts with low uptime are skipped, and it triggers only when signs of a real developer machine are present. For anyone looking for a Ruby wrapper for Bitcoin Core RPC, this is a direct path to full control of the workstation, with all its keys, wallet files and access credentials.

A package named perp-funding-rates has been found on RubyGems whose README describes the bitcoin-rpc-lite library and whose native extension name repeats that name — yet the package contains no build source files. The extension script exists solely to execute code during `gem install`: it decodes a base64 payload and launches it in a detached child process with a delay, then connects to a hardcoded command server and forwards /bin/sh to it. Execution is enabled only on machines showing signs of developer use — the presence of SSH directories and files, RubyGems credentials, git, npm and bundler configurations — meaning the targets are workstations and build systems. For the developer, this gives the attacker interactive access to a machine holding signing keys, tokens and access to infrastructure.

The seed-phrase-validator package published on RubyGems declares a native extension but contains no source code: its installation script exists solely to run during installation, decrypt a base64 payload and launch it in a detached process with a delayed start so it survives the installation process itself. The payload opens a TCP connection to a hardcoded address and connects it to a shell, giving the attacker interactive remote access to the host. Execution is filtered by anti-analysis checks: CI and sandboxes are skipped, and it triggers only on machines with developer artifacts such as SSH keys, git and npm configurations, and gem and bundle credentials. The package's identity is inconsistent: its name refers to seed phrase validation, its README is titled as a Bitcoin RPC library, the makefile target is the same, and there are no native sources; the package is therefore masquerading as Bitcoin tooling.

The gem declares a native extension but contains no source code: instead of a build script, it contains the payload itself, which runs automatically during gem install. It decodes a base64 blob and starts a detached process that hands the host's shell to a hardcoded external server. Execution is deliberately restricted to signs of a real developer workstation: the presence of ssh directories, git and npm configurations, gem and bundler credentials, and system uptime; it aborts in CI and sandboxes. The claimed wallet balance scanning is a cover story: the main file and README (which refers to an unrelated library) are empty stubs.

A package has been found on RubyGems whose declared name suggests ERC20 auditing, but whose README and native build target present it as a lightweight library for accessing bitcoin RPC, while the Ruby code itself is an empty stub with two methods. The native extension script runs automatically when the gem is installed: it decodes a hidden payload and launches it as a detached background process with a delay, then connects to a hardcoded remote address and forwards the local shell there in an endless reconnection loop — giving full remote control over the developer's machine. The payload deliberately stays silent in CI, sandboxes and recently booted hosts, and triggers only where it sees signs of an active working environment: SSH keys, git configuration, RubyGems, bundle and npm credentials. Those who installed this gem on a machine used for building Bitcoin infrastructure or holding its keys are at risk.

Malicious code has been found in the gas-refuel-bridge package for RubyGems: the native extension's build script decodes and executes an embedded payload during gem installation. The payload starts a detached background process that waits, connects to an external host and redirects /bin/sh to it — potentially giving an attacker persistent access to the developer's machine. Execution is deliberately skipped in CI and disposable environments, and occurs only if the disk contains signs of a working machine: SSH keys, git configurations, npm and RubyGems credentials, and bundler credentials. The advertised functionality is a cover: the description refers to a “gas refuel bridge,” the README is titled as a bitcoin-rpc library, and the library code itself consists of empty stubs, so the gem could be mistakenly added to a bitcoin project while searching for an RPC client.

In the RubyGems package ton-jetton-tools, the native extension build script contains a base64-encoded payload that is decoded and executed during gem installation itself. The payload launches a delayed background process, connects to an external address and forwards /bin/sh there, giving the operator of that address an interactive shell on the developer's machine. Execution deliberately skips CI and sandboxes and triggers only where developer artifacts are found: SSH keys, git configuration, npm and RubyGems credentials, and bundler settings. The declared package name does not match its README and native module stub, which imitate a Bitcoin RPC access library, so developers of Bitcoin infrastructure appear to be the intended targets.

The package with the Bitcoin-oriented name hd-wallet-generator executes a Base64 payload through eval() in the native extension build script during gem installation itself. The payload connects to a hardcoded remote host and gives its operator an interactive /bin/sh; execution is delayed by 20–40 minutes, guarded by sandbox and CI checks, and triggers only where the disk shows signs of a developer workstation: SSH keys, git configuration, gem and bundle credentials, and npmrc. The package contains no native sources at all: building the extension is merely a pretext, and the name in the metadata differs from the README description. Anyone who installed this gem while looking for an HD wallet library should consider the host and all secrets stored on it accessible to outsiders.

A gem has been published in the RubyGems registry whose metadata calls it eth-gas-oracle, but whose README and native extension name present it as a library for working with bitcoin-RPC — so the lure specifically targets Bitcoin developers. During `gem install`, the native extension build script decodes an embedded payload and launches it in a detached child process: it connects to a hardcoded remote host and hands over a shell, allowing the operator to execute arbitrary commands on the installer's machine. The payload deliberately evades analysis — it waits 20–40 minutes, skips CI and sandboxes, and runs only when developer artifacts such as SSH keys, git and npm configurations and gem credentials are present. The gem has no useful functionality: it is a disposable wrapper for a dropper.

Tangem has reported unauthorized access to a third-party support system, discovered on October 9. Names and email addresses of a limited number of customers may have been disclosed. According to the company, other personal data, wallets and cryptoassets are unaffected. The contact information obtained may be used for phishing emails impersonating Tangem support.

The vendor reports that its investigation of the phishing post found no login, session or account access record, while credentials and offline 2FA remained intact. From this, Coinkite concludes that unauthorized access may have occurred at the platform or platform administration level and asks the provider to preserve logs and involve its security team. The vendor separately notes that it cannot verify a connection to reports of admin access being sold.

The vendor reports that a post containing a phishing link was published from its social media account; the post has been deleted, the cause of its publication is being investigated and account access is being checked. The vendor explicitly asks users not to open or interact with the link and reminds them that Coldcard has only one official website. The risk for device owners is a fake page that may impersonate the vendor to ask for a seed phrase or offer fake “firmware”/an “update”. Anyone who followed the link before the post was deleted may have reached such a page.

The vendor reports: if a seed was generated on an affected firmware version and you continue to use the same seed, a subsequent firmware update does not remove the risk associated with how it was created — the migration steps must be followed. Researchers found the issue and reported it to the vendor; a detailed report is promised after the effectiveness of the measures is verified. Separately, the vendor warns of a wave of scam messages and “fixes”: neither a website nor someone offering help is ever entitled to ask for seed words, a passphrase or private keys.

The vendor reports a new critical vulnerability in seed generation in newer COLDCARD firmware. It asks users to check versions Mk4/Mk5 ≥5.6.0, Q ≥1.5.0Q, Mk2/Mk3 ≥4.2.0. This is a separate finding from the vendor's previous advisories: if a seed was generated on an affected version and remains in use, updating the firmware alone does not remove the risk; migration is required. The post does not state that a confirmed fix specifically for this area has been released, and promises a detailed report later. The vendor separately warns that neither it nor “helpers” ever ask for seeds, and that phishing messages offering a “fix” are possible.

Ledger reports that an unauthorized hardware implant was found in a device belonging to one of the affected users. This concerns batches sold through a third-party reseller store, which has suspended sales of all hardware wallets until the investigation concludes. The vendor says its own systems and services are not compromised, and it is contacting affected users directly. For the owner of such a device, this is a direct risk of losing funds: tampered hardware can expose the seed.

Ledger reports that it is investigating fund-loss reports from users in Southeast Asia who bought devices from a reseller named CryptoBillis. During the investigation, the vendor has asked this reseller to suspend all Ledger device sales and shipments. The risk concerns those who received a device through this channel: a seed associated with such a device cannot be trusted.

According to Kaspersky's analysis cited by Keystone, a new version of the MacSync stealer for macOS is being distributed as a crypto wallet called “Toria,” with its own website and promotion on X and Telegram, as well as in “free” and cracked builds of popular software. Once installed, it can steal the macOS login password and Keychain, browser passwords and cookies, data from wallet extensions and applications, and Telegram, SSH, AWS and Git configurations. The analysis separately notes that its backdoor can replace the installed Ledger application with a version downloaded from the attacker's server. Bitcoin owners who store or sign anything on a Mac, and developers with access keys on the same machine, are at risk.

Blink released the second phase of disclosure about the theft reported on September 19: a public page listing all addresses, transactions and Lightning channels that the team associates with the attacker, updated as the coins move. According to Blink, the attacker has not stopped: in the first week of October, their main node opened a new channel, a second node appeared, coins moved again, and on October 5 they exploited a bug in Second's Ark server (the Bark project) and took 0.75 BTC of the company's own funds — user funds were unaffected. They funded this from the same wallet that received the coins from Blink. Blink considers a cascading pattern likely: proceeds from one target finance an attack on the next. About 0.87 BTC remain at five original addresses, 4.84 BTC are at an address presumed to belong to the attacker, and 1.64 BTC are at addresses involved in the attack on Second.

Start9 reports that a Core Lightning build with security fixes is available in the StartOS Marketplace and asks users to update immediately. This is the same release that fixes a vulnerability capable of causing loss of funds on nodes running earlier versions. Owners of StartOS servers no longer need to wait for packaging: it can be installed right now.

BTCPay Server has updated its bundled Core Lightning to 26.06.9, a release fixing a vulnerability that could cause loss of funds. The update is available to BTCPay users right now through the standard mechanism. If CLN is not used in your installation, the incident does not affect you.

The project has clarified the urgency of release 26.06.9 on its channel: it fixes a newly reported vulnerability that could lead to loss of funds. Nodes on 26.06.8 and earlier are affected. This is stronger than the earlier wording about a “set of security fixes.”

Patch release 26.06.9 fixes vulnerabilities in channel reestablishment, splicing, HTLC handling during closure, onion, onchaind, gossip queries, runes and setconfig, plus a number of remote crashes. It also fixes a 26.06.8 regression that caused a busy node to throttle ordinary gossip, pings and onion messages, and delay channel traffic. Again there is no embargo: the fixes are available immediately, while their tests are temporarily withheld to allow time for updates. Reproducible arm64 and armv7 builds are now available with separate signed manifests.

The vendor has released BTCPay Server 2.4.5 with security hardening around Lightning and LNURL, while also simplifying the standard Docker deployment. Tor is no longer included by default: existing installations must explicitly opt in, or the server will lose its onion address after the next Docker configuration or update. A number of abandoned integrations have also been removed (including JoinMarket, Electrum Personal Server and BWT, BlueWallet LNDHub, Traefik, BTCTransmuter and Configurator, as well as obsolete altcoin chains) — configurations that depend on them will stop building. Public LND and Core Lightning APIs have not been exposed by default since 2.4.2; the btcpay-routes command has been introduced in place of manual Nginx editing.

The Galoy/Blink consent application accepted a scope list directly from a browser form without checking it against what the OAuth client had requested, allowing an ordinary registered user to obtain a token with a full set of administrative privileges. In affected deployments, the admin gateway and admin GraphQL API trusted these scopes without their own checks, allowing access to customer data (balances, history, contacts, login methods), email and phone changes, and account takeover through passwordless login. No compromise of signing keys was required: the identity provider itself issued the tokens, so signature verification does not detect the attack. According to the incident analysis, this method was used to take over 35 custodial accounts at Blink in September 2026 and withdraw about 6.61 BTC from 24 of them.

A disclosure has been published for DoS vulnerabilities in the Lightning implementation Eclair; the fix was released in version 0.14.1. Operators of their own Eclair nodes are affected: denial of service means node unavailability and a risk of channels becoming inoperable. According to the source, users of mobile wallets that use an Eclair node as an LSP (such as Phoenix) are not affected — ACINQ patched its own nodes several months ago.

The package poses as a library for decoding BOLT11 invoices, but has none of the advertised functionality. The native extension executes automatically during gem install: the build script decodes the embedded payload, downloads an archive over unencrypted HTTP into a temporary directory and runs a shell script from it in a separate detached process. Execution is enabled only on machines with directories and files containing SSH keys and gem/npm/bundler credentials, and is suppressed in CI and sandboxes — the dropper specifically targets developer machines with access to keys and registries.

A package named tx-broadcast-utils has been published on RubyGems, advertised as a set of helpers for broadcasting Bitcoin transactions through public esplora endpoints. It has none of the claimed functionality: the library contains only a shortened BIP39 word list, and its only working component is a native extension script that executes an encoded payload during `gem install`. The payload detaches a background process, waits several tens of minutes, then downloads and runs an external archive from a remote server as the installing user. Execution is deliberately suppressed in CI and sandboxes, and triggers only when there are signs of a developer workstation — SSH keys, git configuration and gem credentials.

The wallet-backup-tool package poses as a tool for working with BIP-39, but contains no real library: it provides a shortened word list instead of the full one, and the C extension is an empty stub. The native extension build script, which runs automatically during gem install, contains an encoded payload: it runs in a hidden child process after first checking that the machine does not look like CI or a sandbox and that the home directory contains developer files (ssh keys, git configuration, gem and bundler credentials). Then, after a random delay, the payload downloads an archive over unencrypted HTTP and executes a script from it. It specifically targets developer machines where crypto wallets and secrets sit alongside development keys.

The gem presents itself as a dependency-free library for working with mnemonic phrases, but declares a native extension with no source code: its build script exists solely to execute code during gem install. The script decodes and executes a payload in a detached background process after a delay of tens of minutes, then connects to a hardcoded remote address and forwards an interactive shell there, giving an outsider unauthenticated access to the host. Execution is enabled only when developer artifacts are present on the machine, such as SSH keys, git configuration, gem and bundler credentials, and npm settings, and is suppressed when there are signs of a sandbox or CI. Neither the package name nor the README mentions a native extension, networking or background processes.

The gem with a bitcoin-oriented name contains a base64 blob in its extension installation script, which is decoded and executed during normal package installation. The payload opens a TCP connection to the operator's server and links it to a shell, providing remote interactive access to the developer's machine. Execution is delayed by tens of minutes and disabled in CI, sandboxes and on hosts without signs of a developer's working environment — specifically targeting real workstations with SSH keys and git and gem credentials. The file has no useful functionality: its sole purpose is to execute opaque code.

The gem, whose name differs from bitcoin by one character, declares a native extension solely to execute a build script during `gem install`; the C code itself is an empty stub, and the Ruby part contains only a static helper with a dictionary. The script checks that the machine looks like a developer workstation rather than a sandbox (CI variables, hostname and username, system uptime, the presence of SSH directories, git configuration, RubyGems credentials, bundler and npm), then backgrounds itself and decrypts a Ruby payload. The payload assembles the command-and-control server address from an encrypted blob, waits 20–40 minutes, downloads an archive to a temporary directory and runs a shell installer from there. The paths checked specifically include files containing package publishing tokens, indicating a second stage aimed at stealing credentials, including SSH keys and secrets stored alongside wallet and repository configurations.

A package with a Bitcoin-related name (BIP39) has been published on RubyGems but contains no real native code: the build script decrypts a base64 blob and executes it during `gem install` itself. The payload downloads an archive from a hardcoded IP over plain HTTP, extracts it into a temporary directory and runs a script as the installing user, making the installation appear successful. The downloader deliberately avoids sandboxes and CI, triggers only when it finds signs of a developer workstation (SSH keys, git configuration, gem/bundle/npm credentials), and waits before running — meaning it targets machines where secrets are stored and Bitcoin code may be built.

A RubyGems package with a name one letter different from that of a Bitcoin library contains an empty native stub whose sole purpose is to run the build script during installation. This script decrypts and executes a payload in a separate child process: it assembles the command server address, fetches an archive over plain HTTP into a temporary directory and runs a shell script from it — that is, arbitrary attacker code. The payload specifically looks for signs of a developer machine — ssh directories, git settings, gem and bundle credentials — and skips execution in sandboxes and CI, waiting for a random delay before downloading. Everything accessible through the keys and tokens on such a machine is at risk, including access to repositories and build infrastructure.

On September 19, an attacker exploited authorization flaws in Blink's administrative tools: anyone with a free account could grant themselves support privileges, change customers' email addresses and phone numbers, and log in to their accounts. About 6.61 BTC was withdrawn from 24 accounts through the operational wallet; Blink's shareholders reimbursed the customers, and cold multisig storage and non-self... non-custodial accounts were not affected. Data for another 3817 accounts was also viewed — in some cases a phone number or email; according to the company, names, documents, passwords and seeds were not disclosed. All 24 drained accounts lacked two-factor authentication, while the attacker was unable to withdraw from nine accounts with 2FA.

Since October 2023, anyone with a free Blink account could use a browser to grant themselves support privileges: change another account's email and phone number, log in as its owner and raise its limits — three authorization flaws in the admin tools. On September 19, an attacker took over 35 accounts and withdrew about 6.61 BTC from 24 of them, and also viewed data (in some cases a phone number or email) for another 3817 accounts; this did not include names, documents, passwords or seed phrases. The money came from the hot wallet; cold multisig storage and non-self... non-custodial accounts were not affected. All 22 affected customers had their balances reimbursed by shareholders. None of the 24 drained accounts had two-factor authentication, and nine withdrawal attempts from accounts with 2FA (18 attempts) resulted in zero losses.

The vendor reports on its channel that the released firmware update fixes seed generation only for future keys. The update does not “repair” a seed created on affected firmware — such a key remains defective, and funds at its addresses are at risk. Restoring from backup or cloning the device does not solve the issue: the defect travels with the key. All owners who generated a seed on vulnerable firmware versions are affected.

The Lightning Dev Kit team has reported several security vulnerabilities in LDK, including the possibility of fund theft. Fixes have been released in versions 0.1.13, 0.2.7 and 0.3-rc3. Those running LDK in production with untrusted channel counterparties are primarily at risk: a malicious counterparty is precisely the scenario addressed by the fix. The 0.3 branch remains in testing, with rc3 current for that branch.

In its channel, the Core Lightning project says it has received reports of attackers targeting unpatched nodes. Installations running version 26.06.7 and earlier are affected; a fixed release is already available. For operators, this increases the urgency of the previously announced update: waiting now means an open attack surface against funds in channels.

Two vulnerabilities have been disclosed in the channel-opening flow in Eclair v0.14.0 and earlier. The first (LNF-2026-0003) is a race condition when checking for duplicate temporary_channel_id values: pipelining identical open_channel messages creates orphaned channel actors, and a leak of about 1 MB per second leads to JVM OOM or a garbage collection spiral that takes the node offline. The second bypasses the limit on uncommitted channels by reusing a final channel ID as a temporary one: a single connection with no on-chain cost exhausted 4 GB of heap in about 48 minutes, and because channels are saved to disk, the node crashed again on every restart until the operator increased the heap or manually deleted records. Operators of Lightning nodes running Eclair are affected.

Two issues have been found in the channel-opening flow in Eclair v0.14.0 and earlier. The first (LNF-2026-0003) is a race condition when checking for a duplicate temporary_channel_id: a stream of identical open_channel messages creates orphaned channel actors and a memory leak of roughly one megabyte per second, leading to a JVM OOM crash or a garbage-collection hang that takes the node offline. The second bypasses the pending-channel limiter by reusing the final channel id as a temporary one: a single connection, with no on-chain cost, exhausted 4 GB of heap in about 48 minutes, and because the channels are saved to disk, the node crashed again on every restart until manual cleanup or a heap increase. The attacks require only a connection to the node; the report provides no evidence of exploitation on the network.

Start9 has released StartWRT 1.2.1 with security fixes for the router management interface and asks users to update without delay. According to the release description, every router settings change now requires login, and `startwrt-cli` sends local credentials only to the router on which it is running. A side effect of the update is noted separately: a VPN connection whose configuration specifies the server by hostname could not be routed through another VPN — previous versions accepted such a chain but actually connected directly over WAN; after the update, this setup switches to connecting over the internet, and this is visible in the activity log. The release reports no signs of exploitation.

The vendor has released the next version following the same security audit: it adds verification of BSQ swap inputs and signatures on both sides of the trade (outpoint binding and duplicate input checks), the API no longer allows confirmation that payment has started before the seller's payment details have been received, and Tor has been updated to 0.4.9.13. Bisq says the update is mandatory to continue trading.

According to the advisory, the dotenv-precheck package, posing as a dotenv checking utility, registers its script as postinstall, so it runs automatically when dependencies are installed. The obfuscated code recursively traverses the home directory, including Desktop, Documents and Downloads, reads text files and selects values matching secret patterns: variables containing KEY, SECRET, TOKEN, PASSWORD, SEED, MNEMONIC, WALLET, private keys in Base58 WIF format, and BIP-39 mnemonics validated against the wordlist and checksum. The collected material is sent to the attacker's Telegram bot. The package has none of its claimed functionality, so the sole purpose of installation is to steal secrets.

According to the vendor, Apple has released a fix for CoreGraphics vulnerability CVE-2026-86950, which has already been used in real-world attacks: a single malicious file was enough for full code execution on a device. Devices running iOS 26.7 and corresponding macOS builds are at risk. For a Bitcoin holder, this means a wallet, seed phrase or passwords stored on such a phone or computer may have been read by an attacker.

In Eclair 0.13.1 and earlier, feature vectors were parsed bit by bit: one maximum-length init message generated about 300 MB of heap garbage and occupied the parsing thread for up to 300 ms (LNF-2026-0001). According to the researcher's description, a stream of such messages disconnects all the victim's peers within a minute and exhausts memory within five. The second issue (LNF-2026-0002) is that zlib-compressed channel queries are still accepted without an output size limit: a 64 KB query expands to 64 MB and around 17 million heap objects, and a stream of these messages takes the node offline in seconds. Both are fixed in Eclair 0.14.0.

The vendor has confirmed that on September 19 an outsider withdrew funds from several dozen accounts through a vulnerability in its own software. Affected users' balances have been restored to their pre-incident state, and they have been notified directly. The attacker also gained access to account information for about 3400 other users — according to the vendor, no funds were withdrawn from those accounts, and names, documents and addresses were not affected. The leaked account information is a ready-made list for targeted phishing posing as support.

On September 10, 2026, attackers exploited a vulnerability in a third-party mailing service, gained access to the Shift Crypto / BitBox account, exported the entire contact list and used the account to send two phishing campaigns. The emails used legitimate mailing infrastructure and passed standard authenticity checks, so they looked like the official newsletter: they falsely claimed there was a vulnerability in BitBox and asked recipients to enter their recovery words on a website. Only the email addresses of subscribers to the newsletter, educational emails and affiliate program were leaked; according to the vendor, order data, internal systems, the app and the devices themselves were unaffected. The risk is direct: an address from a list of hardware wallet owners is a ready target for seed-focused phishing.

On September 6, 2026, an attacker exploited a vulnerability in Elements' rangeproof verification cache: according to Blockstream's report, the attack used Bug B — an error in constructing the cache key when combining fields. This allowed about 4000 LBTC to be issued without backing bitcoin, after which the funds left through the standard peg-out process; Liquid's reserve fell from about 4205 BTC to 197 BTC. The attacker returned 3400 BTC, while about 602 BTC remains unreturned; other Liquid assets (USDt, DePix and others) were not affected, but were unavailable during the network halt. Blockstream stopped the bridge nodes, rolled out an urgent temporary patch and then released the reviewed Elements v23.3.4.

Point release 26.06.8 fixes a set of vulnerabilities reported by external researchers; unlike 26.06.7, there is no embargo period, and the fixes are available immediately. The project has temporarily withheld some tests to make it harder to quickly reconstruct vulnerability details and attack before operators have time to update, so the window before technical details emerge is limited. It also notes that nodes running builds from master cannot downgrade to the 26.06.x branch because of a newer database schema.

Block's engineering team and independent researchers analyzed an RNG integration error in COLDCARD firmware: instead of the STM32 hardware generator, it uses a deterministic MicroPython software fallback initialized from the chip UID and timers. On Mk2/Mk3 (v4), no cryptographic entropy is added to generation at all; on Mk4/Q/Mk5, only a few bytes from the secure element are retained, and reseeding replaces one 32-bit state word. This makes seeds generated on the device recoverable. The investigation was prompted by reports from COLDCARD owners of missing funds; Block writes that exploitation is ongoing and refers to a separate Coinkite analysis.

The SlowMist team reports receiving several complaints from users whose funds were stolen. Its investigation found private key exposure in all these cases, and some of those affected had previously installed and used FomoPeek versions 1.1–1.2. The message names no fix or safe version; the link between the application and the thefts is presented as the result of investigating user reports, rather than a code analysis.

Blink reports that the vulnerability behind the recent incident has been fixed and verified, and services are operational again. Access has been restored for all unaffected accounts, while affected users' accounts remain temporarily locked. According to the vendor, non-custodial balances were not affected. The vendor has not yet disclosed details of the vulnerability or the scale of the incident, and promises a full analysis later.

Blink wallet has reported a security incident. An attacker gained access to a limited number of custodial accounts and withdrew funds from them. According to Blink, most funds are safe and non-custodial wallets are unaffected. Service has been suspended during the investigation. The cause and scale have not yet been disclosed.

A BOLT11 invoice could contain multiple payment hash values, and different libraries selected different ones: some the first, others the last. If a system combined both interpretations, it considered a payout unsuccessful after the payment had actually been made, allowing the balance to be drained through repeated withdrawals. According to the post, this is how a popular Telegram P2P bot was hacked and funds were lost. A specification change has been proposed to reject invoices with more than one payment hash; test vectors have been updated.

Zeus developers report that, because of a bug in a third-party dependency, older versions stored wallet data, including seeds and connection credentials, in the keychain synced through iCloud instead of local device storage. Version v13.2.2 moves this data to local storage and then automatically and permanently deletes the iCloud copies without asking for confirmation. The deletion propagates to all devices with the same Apple ID: any device that has not yet been opened on v13.2.2 will lose its saved wallet configurations, because older versions had no separate local copy. This also affects devices that updated in the background; changing the update order does not avoid the problem. According to the vendor, iCloud Keychain is end-to-end encrypted, the data was accessible only to the user's own trusted devices, and there is no evidence of a user data leak.

The Liquid Federation and Blockstream report that the root cause and exploitation path of the September 6 incident have been identified, and an immediate fix has been released in Elements v23.3.4. Of the approximately 4,000 BTC withdrawn in the attack, 3,400 BTC has been returned to the federation's reserve; around 600 BTC remains unreturned, and efforts to recover it are ongoing. Block production and transfers of Liquid assets, including LBTC, have been operational since September 10, but peg-out operations remain suspended pending confirmation of full 1:1 LBTC backing and completion of updates, testing and independent audits. There is no date for resuming peg-outs; a detailed technical report is promised later.

Bisq has released an urgent 1.10.8 update. It fixes vulnerabilities found in a security audit. The fixes affect refund payouts: these now require verified escrow data and authorization from the claimant or agent. Reuse of refund receipts and cross-network payout reservations are blocked, and refund transactions are checked more thoroughly. Burning Man proposal, BSQ swap signature and fee recipient checks have also been fixed, and Tor has been updated. The vendor does not state that the vulnerabilities were exploited. The refund logic flaws concern funds in trades, and trading is no longer possible without updating.

JAN3, as reported by Bitcoin News, announced a DoS attack on the new Indra swap infrastructure in open beta. The attack prompted the team to temporarily disable forward swaps while investigating the incident. Indra replaces Boltz in the Aqua wallet and moves bitcoin between Lightning and Liquid. Swaps started before the shutdown may be delayed. The report contains no information about lost funds.

Swap service Indra says it is under a DoS attack and has disabled forward swaps while it investigates and mitigates the attack. Swaps already started may take longer than usual. Those using swaps through Aqua or directly are affected: new swaps are currently not going through, and funds in operations already started are stuck for an unspecified period. Further updates have been promised as the situation develops; no restoration timeframe has been given.

Start9 refers to a critical Core Lightning warning and gives StartOS users a specific protective step: disable the experimental “Dual funding and liquidity ads” feature. The message contains no released fix or confirmed exploitation.

Core Lightning reports in its own security advisory that it is investigating reports of a possible issue in experimental features. According to the vendor, it may affect users' funds. The issue concerns nodes with experimental features enabled. The vendor has not yet disclosed technical details, affected versions or signs of exploitation; there is no fix.

The Bisq 2 developers call v2.1.13 an important security update. It updates Tor to the latest security release, version 0.4.9.12. The notes do not disclose details of the Tor vulnerability. Trading cannot continue without the update. Because the Apple Silicon build was renamed, Intel Mac users may receive an incompatible version through the built-in updater.

On its official account, the team behind Bitcoin wallet Liana reported that @LianawalletRH is a fake account impersonating the project. Liana does not have a token and will not have one. Anything promoted by this account, as well as its direct messages, should be treated as fraud. Liana users and anyone following the project on X are at risk: this could lead to losing money on a fake purchase or disclosing wallet data in correspondence.

ACINQ has released Eclair 0.14.3, a patch release with security fixes. Most of the fixes were found through the Loupe project. According to the developers, some of these issues could be exploited by malicious Lightning nodes. The message does not say exactly which bugs were fixed or what their consequences could be. Operators of Eclair nodes running versions before 0.14.3 are affected.

Revolut has confirmed that it disclosed confidential customer data to outsiders. An attacker sent forged requests from a legitimate government agency's email domain. According to the publication's headline, the disclosed information included KYC data and bitcoin transaction data. Revolut called it a “sophisticated external impersonation scheme,” blocked the address and said that its systems and customer funds were unaffected. The report does not specify how many customers were affected. Linking identities to bitcoin activity enables targeted phishing and the selection of targets for physical coercion.

Electrum's developers announced release 4.8.2 on their official account. They call it another security update and thanked the researchers who reported the issues. The announcement does not specify which vulnerabilities were fixed or how serious they are. There is no information about exploitation. Users of the Electrum wallet on versions before 4.8.2 are affected.

RoboSats v0.8.7-alpha fixes XSS in the coordinator information window: the coordinator's message is now displayed as text rather than HTML, closing this path for web, Android and desktop clients. However, a fix for the second issue in the advisory is unconfirmed: when a reward payout times out, the amount may be returned to the robot even though the first Lightning payment may still complete, allowing the reward to be received twice. This affects coordinator operators. Both issues are rated medium in the advisory; no exploitation has been reported.

Blockstream relayed the Liquid Network status as of September 10, 19:55 UTC. The network has moved to the next recovery stage: block production has resumed, functionaries are signing and verifying blocks, and transactions are going through again. Peg-outs remain disabled as a precaution until the final recovery stage is complete. No timeframe has been given for their resumption. Testing, code scanning and network monitoring are ongoing in parallel. The source also reports that scammers are exploiting the situation by sending messages and promoting fake “update” websites.

According to Aqua Wallet, the Liquid network has resumed processing transactions. Liquid→Liquid transfers are confirming, and USDT and DePix are working again. Peg-ins and peg-outs remain suspended while full 1:1 backing of L-BTC is restored. Aqua separately warns against selling L-BTC at a discount in manual P2P swaps, because work to restore the backing is ongoing.

As of September 10, 10:00 UTC, the Liquid network has moved to the next stage of its controlled restart. For now, blocks are being produced without transactions to check stability. Blockstream confirms that updates to functionaries and bridge nodes have been deployed, and functionaries are signing blocks normally. Peg operations, including PAK-authorized peg-outs, remain suspended: the BTC/LBTC reserve is still being restored.

Trezor has disclosed details. Brevo, the vendor's mailing platform, was breached; the incident affected 120 Brevo accounts. The email was sent to about 347,000 addresses in the newsletter database. The email link offered an app download that asked users to enter their wallet backup. Trezor blocked the domain after 20 minutes, but around 2,500 people had opened the link by then. The vendor cannot confirm whether the database was downloaded, so it considers all addresses known to the attacker. They may be used for further phishing campaigns.

Specter reports a compromise of the Brevo mailing service, which is used by several Bitcoin projects, including two companies that make hardware wallets. Phishing emails are already being sent through it — meaning the attackers have customer email lists and can write on behalf of brands familiar to readers. The typical goal of such mailings is to obtain a seed phrase under the guise of “mandatory verification” or an “urgent update,” or to send users to a lookalike website. Specter itself says that its subscribers and its own mailing list are unaffected because it uses a different provider; the message does not name the specific companies affected.

An email provider used by Trezor and BitBox is suspected of being compromised. Malicious emails are being sent in both vendors' names; the full email text is truncated in the input, but the impersonation of official correspondence itself creates a risk that a holder will enter a seed phrase or follow a phishing link, believing the email to be genuine.

Shift Crypto (BitBox02) reports that about an hour ago, subscribers to its newsletter received a phishing email. Preliminary information indicates that a mailing provider shared with several other bitcoin companies was compromised. Some phishing domains have already been blocked, and the investigation continues.

Following the recent incident on the Liquid network, scammers are impersonating Blockstream and Liquid support at scale: sending emails and DMs with a “mandatory security update,” asking users to enter a seed phrase on “migration” websites, transfer funds to a “recovery address,” or install firmware/an application using a link in the message. Blockstream explicitly states that the incident itself does not require users to take any of these actions.

Trezor's third-party email provider was breached, and a fake email with a subject about an STM32 entropy vulnerability is being sent in the brand's name. This is phishing: the email is not from Trezor, and its links may lead to a malicious website. The vendor has already disabled the domain used and is investigating how the attackers gained access to it.

The manufacturer of the BitBox02 hardware wallet reported through its official account that a phishing email disguised as a message from the vendor is currently circulating. The company confirms the issue and is investigating. Such emails aim to induce users to take actions that lead to the loss of funds.

Amid the incident involving the withdrawal of funds from Liquid's federal wallet, scammers impersonating Liquid, Blockstream and their support have become active. Fake websites and mailings ask users to enter a recovery phrase, transfer funds to a “recovery” address, “update their portfolio” or install firmware/an app through an email link. Blockstream officially confirms that the incident itself does not require users to take any such actions.

Blockstream relayed Liquid Network's own announcement of an emergency release of a new version of Elements, the software running the Liquid network. The announcement text is truncated, so the exact reason for the emergency release is not visible in the input, but the “emergency” designation itself indicates that a significant issue in the network node is being addressed.

Aqua Wallet's official account retweeted a warning about emails being sent under the guise of Aqua Wallet or Liquid BTC: exactly which email address lists are being used is unknown, but recipients are asked to install something. The vendor does not know the source of the mailings, and the legitimacy of their content has not been confirmed.

Attackers are sending Liquid_BTC/Aqua Wallet users phishing emails leading to fake update sites. These sites offer an executable file disguised as a wallet update — in fact, malware that could lead to theft of funds.

The official report on the incident involving unauthorized withdrawals from Liquid's federation wallet clarifies the recovery timeline: about 85% of the stolen BTC has already been returned to the federation, an emergency software release is being prepared, and the network itself is currently estimated to resume in 4–5 days. Aqua Wallet users' private keys are not affected, and native bitcoin operations are working normally — only Liquid services have been suspended.

The official report on the incident involving an unauthorized withdrawal from the Liquid Federation wallet (relayed through Aqua Wallet) names the technical cause for the first time: a vulnerability in the Elements protocol's range proof mechanism, rather than only the use of a Peg-out Authorization Key, as previously stated. The Liquid network itself has still not returned to normal operation.

Blockstream developer Excellion has published an official, up-to-date report on the Liquid network compromise. The cause is a vulnerability in the range proofs of the Elements protocol on which Liquid is built. The source text is cut off, so further details (scale and fix status) are not visible in the input.

BTCPay Server has released version 2.4.4 — a security-focused update issued in response to ongoing attempts to attack the project. The vendor recommends on its own account that all server administrators update. Some changes are breaking — read the accompanying article before updating.

Following the incident involving unauthorized withdrawals from Liquid's federation wallet, Blockstream and Liquid Federation members have deployed updated software and are preparing a coordinated network restart to further strengthen security. This is a new step compared with earlier updates: there was no fix then; now the software has been rolled out and preparations for a restart are underway.

On September 6, around 4,000 BTC were withdrawn from the Liquid Federation multisig wallet. According to Aqua Wallet's official account, citing Excellion, about 3,400 BTC have now been returned to the Federation wallet. The causes of the incident and the fate of the remaining amount have not yet been disclosed.

The Liquid Federation has halted the Liquid sidechain after a vulnerability was exploited; the white-hat responsible for the exploit is currently communicating with Blockstream on-chain. Aqua Wallet reports that private keys and on-chain bitcoin transactions in the app are unaffected, but Liquid transactions are currently not being processed.

The wallet-engine-signing package has been identified as malicious: according to the advisory, any computer where the package was installed or run should be considered fully compromised. Removing the package does not guarantee removal of all effects of the infection — the attacker may have gained full control of the machine.

Aqua Wallet confirms a security incident on the Liquid network: presumed white-hat hackers withdrew about 4,000 BTC (~$320 million) from the Federation wallet through a Peg-out Authorization Key used by SideSwap, while the key itself was not compromised. Exchanges have suspended L-BTC deposits and withdrawals, bridge nodes have been temporarily disabled, and the Liquid network has effectively halted until the incident is resolved. Other Liquid assets (USDT, DePix, RWA) are unaffected.

Strike reported through its official account that an email impersonating the company, but not actually sent by it, is currently being circulated. Such emails are used to steal Strike users' credentials and funds.

In previous versions of Specter-DIY firmware, a hardware random number generator failure could be silently accepted as valid entropy, while transaction change was checked using metadata supplied by the computer without verification on the device itself — opening the way for a malicious host to substitute the change address. A warning check for mixing inputs from different wallets in one transaction, which had previously failed to trigger, was also restored. This affects Specter-DIY hardware wallet owners.

Trezor has reported that the data breach at its shipping partner ShipMonk was larger than previously reported: an additional 67,000 US customers who ordered devices from November 2019 to August 2021 were affected. Their names, email addresses, phone numbers, shipping addresses and order numbers were exposed. Trezor's own systems and devices are not compromised, but the exposed personal data creates a risk of targeted phishing and fraud impersonating Trezor.

The @quantixfinance/supabase package masquerades as a Supabase client, but is actually a dummy package: its preinstall script scans environment variables for substrings such as key, secret, token, mnemonic, seed, wallet and private, and sends its findings along with the hostname to a hardcoded attacker server. The package name resembles a specific organization's internal scope — this is a dependency confusion attack intended to trigger automatic installation in someone else's project. If the package ended up in the dependencies, the machine's secrets, including any wallet seed phrases, may already have leaked.

The vendor reports that the 26.06.7 Docker image has been updated and now actually contains the security fix that was previously missing from it. Operators deployed through Docker are affected.

The vendor reports that the release's Docker images, published on August 28, did not actually include the announced security fixes — this became known only now, through a quiet edit to the release page without a separate announcement. This means operators who updated through Docker (including through BTCPay Server) remained all this time…

The Specter Desktop account retweeted a warning that the same phishing infrastructure of fake websites that had already targeted Specter is now targeting users of other Bitcoin wallets — Fold and Phoenix Wallet are named. The provided information contains no confirmation from these vendors themselves.

In addition to the fake website the vendor previously reported, a fake email campaign from the same fraudulent domain has now been recorded. The attack targets Specter Desktop users and may lead them to follow malicious links.

The official Specter Wallet account has reported a fake website impersonating Specter Desktop; an independent researcher reported the fake to the vendor. The risk is downloading a malicious version of the wallet from the fake site, which could compromise keys and cause holders to lose funds.

GitHub Security Advisory reports that the test-in-one package pulls in a local dependency with a postinstall script that runs automatically when the package is installed through npm. The script traverses the home directory, Desktop, Documents, Projects and the current folder, collecting the contents of desktop cryptocurrency wallet directories. Those who installed this package and keep bitcoin wallet files on the same machine are at risk.

BTCPay Server reports that it has updated Core Lightning to v26.06.7 in its Docker deployment, while external CLN access remains disabled as a precaution — it is planned to be enabled within one to two weeks. This affects BTCPay Server operators using Core Lightning in a Docker deployment. It separately notes that ARM32 devices, including some older Raspberry Pi models, may not work — ARM32 binaries were not built for this CLN release.

Blockstream has released Core Lightning 26.06.7, a point release fixing vulnerabilities reported by independent researchers through the responsible disclosure program. The vendor will publish the fix's source code only after two weeks to make it harder to analyze the vulnerabilities before nodes are widely updated; only signed binaries are currently available. The vendor recommends a temporary workaround for those who cannot update immediately.

Ledger reports an ongoing campaign: holders receive physical letters with a QR code leading to a fake website that asks them to enter their 24-word recovery phrase. Entering the phrase gives attackers full access to the wallet and leads to loss of funds. Ledger stresses that the company never contacts users by DM, phone or mail, and never asks for a recovery phrase.

Core Lightning has issued patch release v26.06.7, fixing several vulnerabilities reported by independent researchers. The release's source code is deliberately withheld — a 14-day embargo is intended to make reverse-engineering the fixes harder before the network updates. The maintainers explicitly ask users to update now, without waiting for Docker images.

Ledger Donjon has published three bulletins about hardware wallet firmware: the screen becoming out of sync with the data being signed when commands are interleaved during on-screen verification, a clear-signing bypass through array counter truncation, and accepting a token approval in place of a payment in a swap. Patches are already available.

Core Lightning's official account has addressed node operators: there is no need to stop the node now, but once the upcoming release is out, updating is mandatory and must not be delayed. Those unable to update immediately are advised to run the node with the --offline flag.

Umbrel is releasing an update to its Core Lightning application in response to a discovered security issue. Following the Core Lightning developers' recommendation, the node continues to run and monitor the Bitcoin network but temporarily disconnects from the Lightning network until a separate signed release containing the fix itself becomes available.

BTCPay Server reported on its official account that, following public reports of an issue, it disabled routing through the Lightning implementations Core Lightning and Eclair in the default configuration. BTCPay Server operators using these nodes to accept payments are affected.

Start9's official account reports an issue with Core Lightning on StartOS: the --offline flag is applied automatically when the node starts. The vendor insists on an immediate update to the latest version of Core Lightning.