硬件钱包建立在一个简单的承诺之上：只要把密钥保存在离线环境中，攻击者就无法触及。
Coldcard 遭黑客攻击一事打破了这一假设。
一个缺陷使部分助记词从生成的那一刻起就是可预测的，导致比特币在钱包始终离线、且受到物理保护的情况下仍被盗走。
本周，我们来看看这一事件如何动摇了人们对比特币自托管的信任，并促使部分持有者重新回到交易所。随后，我们将剖析导致密钥可被预测的技术故障，以及为什么更新受影响的钱包无法保护已经生成的密钥。
本期还有：一个可自我传播的 npm 蠕虫、一个 Metabase 零日漏洞、一个 macOS 屏幕共享绕过漏洞、一个遭到利用的 LoadMaster 漏洞、被植入后门的路由器、用于安全测试的 LLVM、一封可疑的 GitHub SSO 续期邮件，以及更多内容。
本期内容
🌡️ 威胁等级：高度警戒
⚡ 新闻：五条值得关注的安全新闻
🔎 深度解析：Coldcard 遭黑客攻击事件如何动摇了人们对比特币自托管的信任
🎣 这是钓鱼吗？
🔬 技术研究：钱包始终离线，攻击者却依然找到了密钥
🛠️ 本周工具：LLVM
👤 本周人物：Andrea Fioraldi
📅 本周活动：Ekoparty Security Conference 2026
📚 本周书籍：Black Hat GraphQL
😅 本周梗图
❓ 离开前的一个问题
让我们开始吧。
在进入本周的新闻之前，先来看看当前的威胁等级。
🌡️威胁等级
⚡ 新闻
400 多个 npm 软件包被变成了一个可自我传播的蠕虫
ChainDrop 利用窃取的发布凭据感染了热门 JavaScript 软件包。该恶意软件在安装过程中运行，在开发者工作站和 CI/CD 系统中搜寻 npm、GitHub、云服务和基础设施的密钥，随后利用窃取的令牌自动感染更多软件包。Microsoft 发现受影响的软件包超过 400 个。Unit 42 发现有 453 个公开的 GitHub 仓库符合该蠕虫的数据窃取特征，并观察到它在十个环境中执行。
窃取的令牌感染开发者系统和 CI 系统。
一个 Metabase 零日漏洞把密码重置变成了管理员权限
Metabase 证实，攻击者利用一个此前未知的 SQL 注入漏洞攻击了其云服务。存在漏洞的密码重置端点使没有凭据的远程攻击者能够获得管理员权限，进而可能泄露所连接数据库的凭据和数据。Metabase 已修补其云平台，并为自托管版本发布了修复程序。Framework、Tally 和 Kilo Code 随后报告了数据暴露，涉及客户联系信息、密码哈希或 Slack 访问令牌。
密码重置绕过导致所连接的数据库暴露。
无需有效密码：Apple 修补 macOS 屏幕共享绕过漏洞
Apple 披露，位于同一网络中的攻击者无需有效凭据即可通过 macOS 屏幕共享的身份验证。该漏洞编号为 CVE-2026-65400，可在身份验证之前利用，影响启用了屏幕共享的系统。Huntress 发现，更改 VNC 密码或限制允许访问的用户都无法阻止漏洞利用。Apple 已于 8 月 6 日在 macOS Tahoe 26.6.1、Sequoia 15.7.9 和 Sonoma 14.8.9 中修复了该漏洞。
本地攻击者绕过屏幕共享身份验证。
CISA 要求各机构在三天内修补一个遭到利用的 LoadMaster 漏洞
CVE-2026-8037 影响 Progress Kemp LoadMaster，这是一款在应用和服务器之间分配流量的产品。该漏洞允许没有凭据的远程攻击者通过向设备发送未经充分校验的输入来运行操作系统命令。Progress 已为受影响的版本发布了修复程序。CISA 于 8 月 7 日将该漏洞列入其已知被利用漏洞目录，并要求联邦机构在 8 月 10 日之前完成修复。
未经身份验证的请求即可利用存在漏洞的负载均衡器。
20 多款路由器型号出厂时默认启用了一个 root 级后门
VulnCheck 发现了一个名为 ENDLESSDOORS 的远程控制植入程序，存在于以 Zbtlink 和 Wiflyer 品牌销售的路由器中。该软件会连接外部基础设施，并且可以在不验证服务器身份的情况下以完整系统权限执行命令。VulnCheck 估计，全球可能部署了至少 100,000 台受影响的路由器。8 月 6 日，Zbtlink 表示该植入程序是一个支持工具，暂停了受影响路由器的销售，下架了相关固件，并开始开发更新。
内置植入程序可远程控制路由器。
🔎 深度解析
Coldcard 遭黑客攻击事件如何动摇了人们对比特币自托管的信任
黑客从 Coldcard 硬件钱包中盗走了价值约 130 million 美元的比特币，使其成为 2026 年第三大加密货币盗窃事件。
硬件钱包建立在一个简单的承诺之上：只要把密钥保存在离线环境中，远程攻击者就无法触及。没有可以攻破的账户，没有保存秘密的服务器，没有助记词或实体设备就无从下手。
Coldcard 失窃事件打破了这一承诺。
钱包始终处于离线状态，比特币却依然被盗。这暴露了人们进行比特币自托管时所依赖的主要工具之一存在的弱点。
自托管是指自己持有比特币的密钥，而不是把这种控制权交给交易所或其他公司。硬件钱包在离线环境中生成并存储这些密钥，按理说，在线攻击者是无法触及它们的。
Coldcard 是一款成熟的、只支持比特币的硬件钱包，在安全方面享有很高的声誉。然而，部分设备在生成助记词的方式上存在缺陷，导致它们的密钥从生成的那一刻起就是可预测的。攻击者无需攻破钱包的物理防护，就能重建这些密钥并动用其中的资金。
所以真正的问题是：
当用来保护自托管的设备本身成为最薄弱的环节时，会发生什么？
自托管去掉的是托管方，而不是信任
人们选择自托管，是为了不必把比特币托付给交易所或金融机构。但掌控私钥也意味着要妥善保护私钥。
在硬件钱包出现之前，这通常需要借助纸钱包或永久离线的计算机。硬件钱包把这些复杂的方案变成了一台专用设备，由它生成密钥并保持离线。
这让自托管变得切实可行，但并没有消除信任，而是把信任从持有比特币的机构转移到了制造钱包的厂商身上。
大多数用户无法验证自己的设备是如何生成密钥的。他们只能相信厂商正确地处理好了最关键的环节。
Coldcard 遭黑客攻击事件让用户开始质疑自托管
Coldcard 是为数不多的成熟的、只支持比特币的硬件钱包之一。对于希望将比特币密钥保存在离线环境中、而不是放在交易所的人来说，它已经成为一个值得信赖的选择。
正是这种声誉让这次攻击事件显得更加严重。
Coldcard 的作用不仅是让密钥保持离线。用户首先信任的是它能够安全地生成这些密钥。如果这一步在持有者毫不知情的情况下出了问题，那么之后的每一层防护都是围绕一个存在漏洞的密钥构建的。
一名受害者向 Galaxy Research 表示，他的 Coldcard 一直存放在银行保险箱里，从未连接过互联网。攻击者仍然在七分钟内盗走了 18.25 BTC。设备本身一直受到物理保护，但它生成的密钥却没有。
风险恰恰来自人们为保护自己而选择的产品。
这一反应在 Reddit 上的比特币社区和 Coldcard 社区中蔓延开来。一位用户称自己在这次漏洞利用中损失了比特币，而另一位用户则表示要弃用 Coldcard。
在另一场讨论中，一位 Ledger 用户对所有硬件钱包公司都提出了质疑，而评论者们则在讨论是否转向 ETF、Fidelity、Binance 或 Coinbase。
这些帖子并不能证明出现了更广泛的转变，但它们表明，重新回到第三方已经成为讨论的一部分。
Coldcard 事件促使部分持有者从自托管回到交易所
漏洞曝光后，担心密钥存在漏洞的持有者必须决定把比特币转移到哪里。他们可以信任另一款硬件钱包，也可以让交易所替他们保护密钥。
链上数据可以部分反映接下来发生的事情。据 CryptoQuant 统计，7 月 31 日，有近百万个比特币地址发送或接收了资金，而前一天这一数字为 645,000 个。这一激增表明人们在争相转移比特币，但并不能说明每一笔转账的原因或资金的去向。
交易所的充值数据提供了更清晰的线索。据 CoinDesk 报道，同一天，人们存入交易所的比特币多于提出的比特币，差额为 11,163 BTC，其中大部分流向了 Binance、River、Kraken 和 OKX。
并非每一笔充值都能与 Coldcard 联系起来。但从时间上看，部分持有者选择了交易所，而不是另一款自托管钱包。
然而，交易所也有其自身的风险。许多比特币持有者之所以选择自托管，正是因为交易所一再遭到黑客攻击或倒闭。例如，2025 年，攻击者从 Bybit 交易所盗走了约 1.5 billion 美元。
对于回到交易所的持有者来说，这一举动消除了围绕 Coldcard 的眼前不确定性，但并没有消除对信任的需要。它只是把信任从钱包厂商又转回到了交易所身上，由交易所负责保护他们的密钥并提供对其比特币的访问。
Coldcard 事件并没有证明自托管已死。它表明，拥有自己的密钥仍然意味着要信任生成这些密钥的工具。
怎样的硬件钱包才算得上安全？
Coldcard 曾享有很高的声誉。但声誉反映的是一款产品过去经受住了什么，并不能说明其安全性中的哪些部分经过了独立测试。
开源、物理隔离（设计为无需直接连接互联网即可工作）和安全元件（专为保护密钥而设计的芯片）等术语，可能会让一款钱包听起来值得信赖。这些都是有用的特性，但它们并不能证明整个产品是安全的。
公开的代码仍然需要审查，而经过认证的芯片也并不意味着负责生成和保护密钥的软件自动合格。
正式的安全资质认定会明确说明所测试的具体产品和软件版本、所涵盖的威胁，以及执行评估的机构。
例如，ANSSI 对 Ledger Nano S Plus 的认证仅适用于经过评估的版本和配置。其安全目标涵盖了可预测的随机数生成和恶意固件更新等威胁。它说明了测试过哪些内容，但并不能保证未来每个版本的安全性。
Coldcard 事件说明了这一点为何重要。它的弱点是通过固件引入的，影响的是助记词的生成方式。仅对硬件进行审查会遗漏这个问题，而在存在漏洞的固件发布之前完成的审查也已经不够了。
因此，有意义的资质认定必须涵盖硬件、固件、密钥生成和更新流程。当某次更新改变了密钥的生成或保护方式时，还必须重新进行认定。
自托管消除了信任交易所的必要，但不应以用户无法验证的说法来取代这种信任。硬件钱包的安全性需要清晰的证据，而且这些证据必须在产品发生变化时及时更新。
🎣 这是钓鱼吗？
您会点击链接来续期您的 GitHub SSO 访问权限吗？
🔬 技术研究
钱包始终离线，攻击者却依然找到了密钥
2026 年 7 月报道的 COLDCARD 失窃事件，暴露了冷存储另一面的失效模式。攻击者不需要攻破设备、拦截交易、诱骗用户批准付款，也不需要从备份中窃取助记词。公开报道将这一事件与受影响固件中薄弱的种子生成联系在一起：钱包是离线的，但可能的种子空间小到足以被穷举搜索。
第一次被广泛记录的盗取行动发生在 7 月 30 日，在 41 分钟内从 1,196 个 Coldcard 钱包中转走了约 1,082.65 BTC，按当时价格计算约合 USD 70 million。随后的分析将报告的总额扩大到大约涉及约 5,000 个钱包的 1,755 BTC，损失接近 USD 116 million，不过随着研究人员将更多交易归入同一组，这一估算仍在不断变化。
设备并没有在生成密钥之后泄露密钥。
密钥似乎从一开始就是可以被猜到的。
攻击者无需侵入钱包。他们在别处搜索缩小了的种子空间，找到持有比特币的地址，然后在自己的机器上重建了密钥。
当随机性成为安全边界
比特币钱包并不存储一堆互不相关的私钥。它从熵开始：熵是被编码为助记词的随机输入。给定相同的助记词和可选的密码短语，BIP-39 总会生成相同的种子，钱包再从种子派生出主密钥、私钥、公钥和地址。
这种可重现性是有意为之的。正因如此，同一组助记词才能在多年后、在另一台兼容设备上重建同一个钱包。
但它也带来了一条硬性规则：任何人只要重建出相同的种子，就能重建出相同的钱包。
通常情况下，这在计算上是不现实的。一个正确生成的 12 词 BIP-39 助记词代表 128 位熵，而 24 词助记词则代表 256 位熵。搜索空间如此之大，以至于尝试每一种可能性并不是一种可行的攻击方式。
但这些单词并不产生随机性，它们只是对随机性进行编码。
如果随机数生成器只能生成可能取值中有限的或可预测的子集，那么一组助记词看起来仍可能完全正常，但其代表的不确定性却远低于其长度所暗示的程度。二十四个拼写正确的单词并不自动等同于 256 位的安全性。它们的强度只取决于挑选它们的过程。
COLDCARD 事件似乎正是突破了这条边界。
本不该存在的回退机制
COLDCARD 公开了其固件仓库并支持可重现构建，因此可以直接检查这条代码路径。
在固件 4.0.0 中，COLDCARD 将新钱包的生成方式从其自有的 ckcc.rng_bytes 硬件随机数路径改为 random.bytes(32)，后者是对新的 libNgU 库的封装。按照设计，libNgU 的实现应当使用 STM32 硬件随机数生成器。
一个构建配置错误让这一设计意图落了空。LibNgU 只检查硬件 RNG 设置是否存在，而 MicroPython 检查的是该设置是否已启用。该设置确实存在，但值被设为 0，于是 libNgU 的检查通过了，而 MicroPython 则把 rng_get() 编译成了其软件回退实现。
该回退实现的种子来自设备特定值和计时值，而不是足够的新鲜秘密熵。因此，看起来正常的种子可能来自一个小得多、可以被穷举的可能性集合。具体影响因设备代际而异；有关受影响的型号和固件范围，Coinkite 的最新安全公告是权威来源。
由此产生的调用链如下：
make_new_wallet()
↓
random.bytes(32)
↓
ngu.random.bytes()
↓
my_random_bytes()
↓
CHIP_TRNG_32()
↓
rng_get() 最后那个函数名，正是实现与假设分道扬镳的地方。
COLDCARD 的板级配置将 MICROPY_HW_ENABLE_RNG 定义为 0，因为该项目包含了自己的硬件 RNG 实现。LibNgU 试图确保 STM32 硬件 RNG 可用，但它的编译期守卫只检查 MICROPY_HW_ENABLE_RNG 是否被定义，而没有检查其值是否表示已启用。
由于该宏存在，libNgU 接受了这次构建，并将 CHIP_TRNG_32() 映射到 MicroPython 的 rng_get()。又由于该宏的值为零，MicroPython 编译了 rng_get() 的另一种实现：Yasmarang 软件 PRNG，它本是为未启用硬件 RNG 的 STM32 目标准备的。
该设置存在，且值为 0。这足以通过 libNgU 的存在性检查，但 MicroPython 的取值检查却编译了软件回退实现，而不是硬件 RNG 实现。
该回退实现用芯片唯一标识符的前 32 位与当前 SysTick 计数器进行异或，再加上两个实时时钟寄存器，来初始化其内部状态。这些输入可能会变化，但它们并不等同于 256 位的新鲜秘密熵。LibNgU 又将该输出与第二个 Yasmarang 流进行异或，而后者的状态从固定常量开始。混入另一个确定性的流会改变输出，但不会增加未知的熵。
这一区别至关重要。
硬件 TRNG 测量的是一个物理过程，旨在提供新鲜、不可预测的熵。软件 PRNG 则是把内部状态扩展为看起来随机的值。如果密码学安全的 PRNG 一开始就拥有足够的秘密熵，并且被正确地重新播种，它就可以是安全的。而一个以设备标识符和计时器状态等值作为种子的小型确定性回退实现，绝不是生成钱包主密钥的可接受替代方案。
危险之处不仅在于存在一个软件生成器，而在于生产路径可能在一项安全关键操作中悄无声息地使用它。
有两项本地检查让输出看起来更安全，却没有弥补熵的损失。种子生成过程会验证生成的 32 个字节中包含四个以上的不同值，这可以发现卡住的生成器，但无法区分可预测的输出与密码学意义上的随机输出。随后，它会用 SHA-256 对这 32 个字节进行哈希以减轻偏差。哈希可以把有偏差的输入均匀地分散到输出中，但无法创造出原始生成器中本就不存在的可能性。如果攻击者能够穷举输入，他们同样可以对每一个候选值进行哈希。
钱包依然显示出有效的助记词，校验和依然有效，地址正常派生，交易正常签名。用户体验中没有任何迹象表明，种子来自一个小得多的搜索空间。
对于每一个由受影响的随机性生成的钱包来说，这次失效都是悄无声息、持续存在且无法逆转的。
离线暴力破解如何变成盗窃
一旦弄清了 RNG 的行为，攻击者就不再需要实体钱包。
攻击者可以重现这个薄弱的生成器，穷举其可能的内部状态，并将每个输出转换为候选助记词。再从每个候选助记词派生出相应的比特币密钥和地址。
区块链提供了验证层。
比特币地址及其余额都是公开的。攻击者无需查询受害者、登录某项服务，也不会触发硬件钱包上的任何警报。他们只需将派生出的地址与区块链历史进行比对，保留能够匹配上的候选值。
当某个候选种子派生出的地址中持有比特币时，搜索就结束了。此时，攻击者拥有与原钱包持有者相同的签名权限。他们可以在自己的系统上重建钱包，并生成一笔比特币网络认为完全有效的交易。
没有可供网络拒绝的伪造签名，没有密码错误，也没有异常的身份验证流程。
攻击者手握密钥。
为什么 41 分钟并不能描述整个攻击过程
报道中最引人注目的数字，是在 41 分钟的时间窗口内转走了一千多枚比特币。
那很可能只是执行阶段，而不是工作的开始。
穷举候选种子、派生其地址、检查其历史记录，以及对有资金的目标进行优先级排序，这些工作都可能在第一笔盗窃交易出现之前就已完成。快速的盗取行动表明，攻击者可能早已准备好一份存在漏洞的钱包和私钥清单，然后以一轮协同的集中行动，依次处理价值最高的目标。
后续的交易让归因变得更加复杂。随着更多批次的交易和地址被关联到这一弱点，公开估算从最初的 594 BTC 增长到超过 1,000 BTC，随后又增至约 1,755 BTC。相似的交易时间或资金流向可以为聚类分析提供支持，但并不能自动证明每一次盗窃都出自同一个操作者。
因此，最稳妥的说法是一个不断变化的链上估算值，而不是最终的受害者数量或经证实的单一攻击者总额。
为什么仅更新设备是不够的
固件更新可以纠正今后创建钱包时所使用的随机性。
但它无法为已经存在的种子增加熵。
从受影响助记词派生出的每一个私钥和地址，都仍然与原始种子绑定在一起。擦除设备后再恢复同一组助记词，什么也改变不了。把这些助记词导入另一款硬件钱包，同样什么也改变不了。新设备只会重新生成攻击者可能早已能够计算出的相同密钥。
真正有意义的修复措施是迁移：
从厂商官方渠道安装经过验证的固件。
使用可信且未受影响的流程生成一个全新的种子。
在离线状态下验证恢复流程和收款地址。
将从旧种子派生出的地址中的全部资金转移到新钱包。
将从旧根密钥派生出的每一个子钱包（包括 BIP-85 子钱包）都视为可能已经暴露。
切勿将助记词输入任何网站、支持表单、“检查工具”或主动找上门的恢复工具。
关于受影响设备和固件的确切范围，用户应以 Coinkite 的最新安全公告为准。公开报道并不总是一致地使用“钱包”“地址”“设备”和“用户”这几个词，而这些术语是不能互换的。
硬件钱包团队应当吸取的教训
这并不是比特币签名算法、BIP-39 词表或区块链共识的失败，而是在生成长期密钥那一刻发生的实现失败。
这让工程上的教训显得格外直接：
密码学 RNG 必须以安全方式失败（fail closed）。如果预期的熵源不可用，种子生成就应当停止，并给出明确可见的错误。
生产代码中不应包含用于密钥生成的、悄无声息的非密码学回退机制。
测试必须覆盖实际交付给用户的、经过签名的固件镜像和硬件路径，而不能只测试源代码层面或模拟器中的行为。
构建期配置应当断言所需的 RNG 实现处于启用状态。
可以组合多个独立的熵源，使得单个组件失效时不至于完全决定种子。
除了统计随机性测试之外，种子生成还需要已知答案测试、故障注入测试和负向路径测试。
可重现构建提高了透明度，但可重现性只能证明二进制文件与源代码一致，并不能证明源代码是安全的。
当密钥是独立生成的，最好是跨不同实现和不同厂商生成时，多重签名托管才最为牢固。如果每个签名方都重复使用同一个薄弱的生成器，它们就仍处于同一个失效域中。
更深层的教训令人不安，因为硬件钱包在完成设置之后似乎每件事都做对了：它让种子保持离线，保护 PIN 码，验证固件，在可信屏幕上显示地址，在专用硬件中完成签名。
而所有这些控制措施都位于种子生成的下游。
如果最初的秘密是可预测的，那么架构的其余部分保护的可能是一个攻击者能够独立重建的密钥。
物理隔离可以防止秘密离开设备。
但它无法保护一个从一开始就不够秘密的秘密。
版本与范围说明：本节内容基于截至 2026 年 8 月 10 日的公开报道。损失总额、交易聚类以及受影响设备的确切范围仍在变化之中。USD 116 million 这一数字为估算值，并非经过审计的最终损失总额。
来源：TRM Labs、CoinDesk、Coinkite 安全公告、COLDCARD 固件仓库、固件 4.0.0 种子生成代码、COLDCARD 板级 RNG 配置、固定版本的 libNgU RNG 实现、固定版本的 MicroPython STM32 RNG 实现、COLDCARD 固件版本历史、BIP-39 规范
🛠️ 本周工具
LLVM
大多数人认为编译器只有一项工作：把源代码变成可以运行的应用。
LLVM 展示了编译过程也可以成为安全测试的一部分。作为 Clang 背后的开源基础设施，它可以在构建软件的同时插入检查，帮助安全团队发现内存错误，并引导模糊测试工具触及普通测试可能永远无法覆盖的代码。
LLVM 如何支持安全测试
Clang 将 C 和 C++ 源代码转换为一种内部格式，LLVM 可以在生成最终应用之前对其进行分析和修改。
在此过程中，AddressSanitizer 等工具可以添加用于检测内存问题的检查，包括试图访问允许区域之外的数据，或在内存释放后再次使用该内存。
LLVM 还包含 libFuzzer。它会反复向程序发送修改过的输入，并跟踪这些输入触及了代码的哪些部分。能够发现新行为的输入会被保留下来并再次修改，从而让模糊测试工具逐步深入地探索应用。
一个简单的例子
设想一家公司维护着一个用于处理图像文件的 C++ 库。
一位安全工程师用 Clang 编译该库并启用 AddressSanitizer。随后，他将 libFuzzer 连接到负责打开图像的函数，并提供几个有效文件作为初始输入。
LibFuzzer 不断修改这些文件，同时监控解析器的哪些部分被触及。最终，一张格式错误的图像激活了一条很少使用的代码路径，并触发了内存错误。
AddressSanitizer 会报告错误发生的位置，为团队提供一个可复现的输入，以及一个明确的调查起点。
它不能替代什么
LLVM 是一个基础设施项目，而不是一个只需指向应用就能使用的安全扫描器。
使用它的安全能力通常需要能够访问源代码和构建流程，并且需要合适的模糊测试目标。它无法自动识别授权缺陷、不安全的业务逻辑，或其测试从未触及的漏洞。
这些额外的检查还会让应用运行得更慢，因此插桩构建版本通常用于测试，而不会发布给用户。
👏 本周人物
Andrea Fioraldi
本周，我们要介绍的是 Andrea Fioraldi，一位专注于模糊测试和自动化漏洞挖掘的安全研究人员。
Andrea 是 AFL++ 的维护者之一。AFL++ 是一款由社区驱动的开源模糊测试工具，它将多年安全研究中发展出来的技术整合到了一个实用的工具中。
他的工作还包括 LibAFL（一个用于构建定制模糊测试工具的框架）和 QASan（可在无法获取源代码时帮助检测已编译软件中的内存错误）。他关于现代模糊测试技术的博士论文获得了GDR Sécurité Informatique 颁发的 2024 年论文奖。
他帮助将模糊测试研究转化为用于发现软件漏洞的实用开源工具，因此，Andrea Fioraldi 当选本周人物。
📅 本周活动
Ekoparty Security Conference 2026
预计将有数千名安全研究人员、从业者和爱好者齐聚布宜诺斯艾利斯，参加第 22 届 Ekoparty，这是拉丁美洲规模最大的黑客大会。
为期三天的活动将技术演讲和工作坊与CTF 比赛、社区专区、现场黑客活动以及实践挑战结合在一起。
其议程涵盖移动端黑客技术、逆向工程、模糊测试、漏洞利用、固件、云安全以及硬件黑客技术。
对于应用安全和攻击性安全团队来说，Ekoparty 在一场活动中汇集了最新的安全研究、实践演示和动手活动。
📍 阿根廷 Centro de Convenciones de Buenos Aires
📅 2026 年 10 月 7–9 日
📚 本周书籍
Black Hat GraphQL
作者：Nick Aleks 和 Dolev Farhi
如何测试一个允许客户端自行决定所需数据的 API？
Black Hat GraphQL 讲解了 GraphQL API 的工作原理，以及安全专业人员如何检查其攻击面。内容涵盖侦察、信息泄露、身份验证与授权绕过、注入、拒绝服务攻击和请求伪造。
通过动手实验和一个故意设计为存在漏洞的 GraphQL 应用，读者将学会如何识别弱点、验证安全控制措施，并将自动化测试纳入开发流水线。
对于希望切实了解 GraphQL API 如何被攻击和防护的渗透测试人员、应用安全工程师、安全分析师和开发人员来说，这是一本很有用的读物。
😅 本周梗图
如果硬件钱包和交易所都需要信任，那么比特币持有者在决定把比特币存放在哪里之前，应当要求看到哪些证据？
The Breach Brief，Ostorlab 团队