简介
2026 年 7 月 25 日，我们串联了两个严重漏洞，攻破了多名 OpenAI 员工的 ChatGPT 账户。借助这些账户，我们随后得以访问 OpenAI 内部代码仓库，并有可能访问许多其他连接器。
为了证明我们确实获得了自认为已获取的访问权限，同时又不让自己接触到任何敏感信息，我们使用该员工的 Codex 在 OpenAI 内部 monorepo 中提交了一个 PR #1186742 openai/openai。
- libheif图像解码器
- Debian缺失安全回溯补丁
- ImageMagick使用 libheif
- Discourse图片上传
- OpenAI 论坛community.openai.com
- OpenAI SSO身份验证缺陷
- ChatGPT / Codex账户访问
- GitHub已连接的集成
- 内部仓库OpenAI
直到两个月前，任何登录 OpenAI 自家帮助论坛（community.openai.com）的用户或 OpenAI 员工，其 ChatGPT 和 Codex 账户都可能被接管。由于人们可以将各种服务连接到 Codex 和 ChatGPT，我们理论上能够访问的范围极其庞大，包括 GitHub、Slack 和电子邮件。
从最初发现到获得 OpenAI 仓库访问权限的整个时间线，前后不到 72 小时。
我们立即向 OpenAI 和 Discourse 报告了最初的漏洞，并与他们协作协调补丁。我们感谢他们对细节的关注以及对此问题的快速解决。OpenAI 还向我们支付了 $6,500 的赏金。
我们在此提供了披露过程的完整时间线。本文其余部分详细介绍了我们如何发现这两个漏洞、我们如何使用 claude 模型，以及我们从中获得的经验教训。
- 2026 年 7 月 25 日 05:00–06:00 UTC
初步发现
HacktronAI 团队获得了对托管于
community.openai.com的 Discourse 环境的远程代码执行（RCE）和管理员访问权限。 - 2026 年 7 月 25 日 08:00–10:00 UTC
Bugcrowd 提交
在确认了跨产品影响后，团队内部就负责任披露流程进行了协调，并通过 Bugcrowd 上的 OpenAI Bug Bounty Program 提交了一份报告。
- 2026 年 7 月 25 日 13:30–15:30 UTC
OpenAI 员工账户访问权限与概念验证
为了演示该漏洞的实际影响，我们在 OpenAI 的内部 monorepo 中创建了一个无害的概念验证 pull request（应 OpenAI 要求，链接已隐去）。我们用这些发现更新了现有的 Bugcrowd 提交，通过 Twitter/X 联系了 OpenAI 的朋友以直接通知他们，并在大约 15:30 UTC 停止了所有进一步测试。
- 2026 年 7 月 25 日 22:49:45 UTC
OpenAI 方面修复已确认
OpenAI 回复了报告，确认该问题已修复，此时距最初提交大约 14 小时。
- 2026 年 7 月 25 日
通过 HackerOne 报告 Discourse
我们通过 Discourse 的 HackerOne 项目向其提交了一份报告。
- 2026 年 7 月 26 日
Discourse 已回应
Discourse 于周日回复了该报告。
- 2026 年 7 月 27 日
Discourse 修复方案就绪
Discourse 在周一之前就已备好修复方案，并新增了图像处理沙箱作为纵深防御措施。
- 2026 年 7 月 28 日
Discourse 发布安全公告
Discourse 发布了 GHSA-vhm9-85gw-x335，其中包含补丁和重建指南。
- 2026 年 9 月 1 日
OpenAI 发放 6,500 美元赏金并标记为已解决
OpenAI 评论——为澄清该奖励的范围：针对 Discourse 托管的 community.openai.com 的测试已被明确排除在我们的漏洞赏金计划之外。该奖励认可的是 OpenAI 一侧的发现，而非针对 Discourse 的行为。
背景
几个月前，我们 Hacktron 的团队在 Harsh Jaiswal 的带领下，与 Mohan Pedhapati 和 Rahul Maini 一起，开始对前沿 AI 公司进行研究，以寻找安全漏洞。这使我们发现了 OpenAI 身份基础设施中的一处 SSO 配置错误，以及 OpenAI 所使用的社区论坛中的一处 libheif RCE。
此后，我们将研究扩展为 HEIF Heist，这是一项历时数月的调查，追踪 libheif 在 Slack、Meta、GitHub Enterprise、Ruby on Rails 以及 Next.js、Astro 和 Gatsby 等 Node.js 框架中的情况。数量多得惊人的广泛使用的软件都依赖于这一个图像处理库。
如果你的应用程序处理用户可控的图像，并接受 .heic/.heif/.avif 图像，那么它极有可能受到影响。如果你需要任何形式的帮助，请通过 hello@hacktron.ai 联系我们。
入侵 community.openai.com
警告
补丁通知：如果你自行托管 Discourse，请立即重建你的安装。较旧的 Docker 镜像可能包含一个存在漏洞的libheif依赖项，该依赖项允许通过图片上传执行代码。请运行git pull随后运行./launcher rebuild app来自/var/discourse；仅更新 Web 界面可能不会替换底层镜像。Discourse 托管客户已完成修补。请参阅安全公告.
OpenAI 的论坛使用 Discourse，并允许通过 auth.openai.com 实现“使用 OpenAI 登录”。在充分了解 OpenAI 的服务和基础设施之后，我们有理由相信，攻陷该论坛可能通过这一身份认证流程开辟一条通往 OpenAI 更广泛服务的路径。为了验证这一假设，我们首先需要在 OpenAI 的某个服务（比如 Discourse 社区论坛）上实现远程代码执行。
虽然 Discourse 应用本身其实并不是一个容易攻击的目标（我们过去曾研究过它），但我们认为可以转而攻击它的某个依赖项。
libheif 中的堆缓冲区溢出
7 月 23 日，我们开始审查 Discourse 的图片上传流水线，发现 HEIC 和 HEIF 文件走了一条不寻常的路径。Discourse 通常使用 FastImage 进行图片检查，但由于 FastImage 不支持 HEIF，它将这些文件传给 ImageMagick 的 magick 命令进行转换。2这就将底层的 libheif 解析器直接暴露给了攻击者可控的文件。
我们启动了一个 Opus 4.8 会话，加载 Discourse Docker 镜像，让它检查已安装的 libheif 包是否存在安全问题。过了一会儿，它发现某些特定的安全修复并未被回溯移植到 libheif 包中。这使得在 HEIC 解码过程中出现堆缓冲区溢出，进而导致 OOB 读/写原语。
有趣的是，这段存在漏洞的代码在前一年就已在上游被修改，但该提交并未被记录为安全修复，也没有获得 CVE 编号。3 这可能是 Debian 12 和 13 未能及时收到相关安全向后移植的原因之一。由于 Discourse 的 Docker 镜像基于 Debian 12，它安装的是存在漏洞的 libheif 1.19.7 版本。当时即便是 Debian 13 也仍然搭载着存在漏洞的 1.19.8 版本。此后，Debian 已于 2026 年 8 月 8 日发布了针对 Debian 13 的安全更新。4
7 月 24 日，我们使用 Opus 4.8 开发出了一个可用的 ImageMagick/libheif 代码执行漏洞利用程序，当时禁用了 ASLR。随后我们启动了多个独立会话，试图让它在 Discourse 默认配置（启用 ASLR）下也能稳定生效，但未能成功。
Opus 5 发布
当晚，Anthropic 发布了 Claude Opus 5。5我们启动了一个新会话，它在 3 小时内首先产出了一个可在本地 Mac 上运行的 ARM64 漏洞利用程序。随后我们要求它将该漏洞利用程序移植到 x86-64 环境以及 Discourse 所使用的 jemalloc 配置上。
7 月 25 日凌晨 6:00，我们已通过图片上传确认了本地 RCE。随后，我们将 Claude 置于一个自主 /goal 循环中，针对我们自己的 Discourse Cloud 实例发起攻击，并通过 rce.ee/ctf-forum 代理，使其看起来像一个 CTF 靶标，因为 Opus 拒绝为远程实例编写漏洞利用程序。
当我们在上午 10:00 再次检查时，该智能体已在 Discourse Cloud 上实现了 RCE，并通过读取 /etc/hosts 证明了访问权限。利用生成的漏洞利用脚本，我们成功在 OpenAI 的实例上实现了 RCE。
在我们确认了论坛活跃成员的 ChatGPT/Codex 账户可在无交互情况下被接管的假设后，我们立即将报告发送给了 OpenAI。随后我们接管了一名 OpenAI 员工的账户，其 Codex 已连接到 OpenAI 的 Github 组织。
为了在不实际访问任何内部代码的情况下证明影响，我们向该员工的 Codex 账户发送了一条提示词，要求其在 OpenAI 的内部 monorepo 中为我们打开一个 PR。之后我们停止了任何进一步测试。
我们用影响证明更新了 BugCrowd 提交，并通知了 OpenAI 安全团队。我们还为 Discourse 准备了一份报告，并提交至其 HackerOne 项目。Discourse 在周六收到了报告，周日回复，并在周一之前完成了修复（速度值得称赞）。他们还立即开始对 ImageMagick 进行沙箱化。
我们要强调，这种可升级的漏洞并非 Discourse 独有。这是一个 OpenAI SSO 的问题，正是它把论坛被入侵变成了对 ChatGPT 和 Codex 的访问权限。任何使用 OpenAI SSO 的 OpenAI 一方或第三方服务一旦被攻破，都会导致同样的访问权限——Discourse 只不过是证明这一点的一种途径而已。
发现这些漏洞的成本
Discourse 和 OpenAI 的入侵对一个智能体来说只花了几天的工夫，人类投入的时间只有几个小时。整个 HEIF Heist 研究项目针对 Slack、Zoom、Meta 等更多目标，耗时两个月，token 总成本不到 $3,000，由三名研究人员开展。将漏洞利用适配到每一家新公司通常只需要一两天。
我们观察到，每一个新模型的能力都在不断增强，本报告中展示的 Discourse 漏洞利用就是明证。Opus 4.8 在启用 ASLR 的情况下，历经多个会话仍难以产出可用的漏洞利用。Opus 5 发布后数小时内，我们把同样的问题交给它，它就成功了。在更广泛的行动中，我们还看到从 Opus 5 到 GPT-5.6 Sol 的又一次明显跃升——当时我们必须在除了知道目标系统存在漏洞之外对其一无所知的情况下完成漏洞利用。
对于每一个目标，测试都从上传一张图片开始。从那里起，我们把内存破坏转化为可靠的 memory leak 或 shell，通常并不需要知道确切的 libheif 版本、libc 版本或部署环境。AI 几乎是在一无所知的情况下起步，并在一两天内为每家公司调整出可用的 exploit。据我们所知，除了 Shopify，没有任何一家公司检测到了这一活动，即便在发送了数千张图片、其图像处理器反复崩溃之后也是如此。
当代码执行落入沙箱或受限环境时，这些模型还帮助进行权限提升、横向移动以及绕过现有防御。这并非完全自主的黑客攻击，熟练的人类指导仍然很重要，但一个小团队所能完成的工作量急剧增加。
尾声
长期以来，软件一直受益于一种通过复杂性实现的安全。代码乃至漏洞本身都可以是公开的，但要把一个 bug 变成可靠的 exploit，仍然需要稀缺的专业知识、大量时间以及对目标环境的了解。已知的内存破坏漏洞要投入实战代价高昂，而 zero-day 大多留给价值最高的目标。
这从来都不是真正的安全边界，但在实践中，它保护了普通公司免受软件漏洞的侵害。AI 正在移除这层保护，因为它把更多这种稀缺的专业知识转化为算力。曾经需要一个资源充足的团队和数月努力才能完成的工作，如今可以被压缩到几天之内。
安全假设必须跟上攻击者的能力。一个现实的威胁模型应当考虑当今漏洞利用的经济成本，而不是依赖关于谁能实施复杂攻击的过时假设6。
Hacktron 的使命是在恶意行为者之前，发现并消除被广泛信任的软件中的漏洞，从而帮助保障互联网安全。我们正在前沿实验室以及其他对互联网至关重要的系统上持续推进这项研究。如果你负责其中某个系统的安全，我们希望与你合作。
受影响的版本与补丁
HEIF Heist并不局限于某一个版本。它针对的是横跨多个发布系列（例如 1.19.x、1.20.x、1.22.x、1.23.x）的整个漏洞生态。任何未安装最新上游安全补丁的部署都可能存在漏洞。
- 更新上游。通过你的发行版安全通道或上游发布，安装最新的已打安全补丁的
libheif和libde265软件包。截至 2026 年 9 月 14 日，最新的上游libheif安全版本为 v1.23.4；v1.23.2 已被后续的安全修复所取代。发行版软件包可能会以较旧的上游版本号携带向后移植的修复，因此也请查看软件包的安全公告。7 4 - 纵深防御。 鉴于 ISO 基础媒体文件格式的复杂性以及解码器更新的节奏，未来很可能还会出现内存安全漏洞。生产架构应在不需要的地方禁用不受信任的 HEIF/AVIF 解码，或将图像处理流水线隔离在加固的、临时的沙箱中。ImageMagick 的安全策略支持限制可接受的格式和资源使用。8
致谢
我们感谢 Sudanshu Rajhbhar 提供的技术协助，以及 Zayne Zhang、Fabian Faessler、Robert Chen 和 Jessica Ruan 的校对、审阅草稿和反馈，这些改进完善了本文。
参考文献
[1] xkcd #2347：依赖 ↩
[3] libheif：简化叠加层重叠区域计算 ↩
[4] Debian DSA-6417-1：libheif 安全更新 ↩1 ↩2
[5] Anthropic：推出 Claude Opus 5 ↩
[8] ImageMagick 安全策略 ↩
与这项研究背后的团队合作。
Hacktron 汇聚了顶尖的 CTF 研究人员、经验丰富的红队成员以及攻防安全研究人员。我们利用 AI 加速安全研究，在恶意行为者之前发现并消除广受信任的软件中的漏洞。我们正在持续推进针对前沿实验室及其他互联网关键系统的研究。如果你负责其中某个系统的安全，我们希望能与你合作。
Intro
On July 25, 2026, we chained two critical vulnerabilities to compromise multiple OpenAI employees’ ChatGPT accounts. With these accounts, we could then access internal OpenAI repositories, and potentially many other connectors.
To prove we had in fact gained the access we believed without allowing ourselves to learn any sensitive information, we used the employee’s Codex to open a PR #1186742 in OpenAI’s internal monorepo openai/openai.
- libheifImage decoder
- DebianMissing security backport
- ImageMagickUses libheif
- DiscourseImage uploads
- OpenAI forumcommunity.openai.com
- OpenAI SSO Identity flaw
- ChatGPT / CodexAccount access
- GitHubConnected integration
- Internal reposOpenAI
Until two months ago, any user or OpenAI employee logging into OpenAI’s own help forum (community.openai.com) could have had their ChatGPT and Codex accounts taken over. Since people can connect various services to Codex and ChatGPT, the scope of what we could theoretically access was huge, including GitHub, Slack and emails.
The entire timeline from initial discovery to access to OpenAI repo access took place in less than 72 hours.
We immediately reported the initial vulnerability to OpenAI and Discourse and worked with them to coordinate the patch. We appreciate their attention to detail and fast resolution of this issue. OpenAI also paid us a $6,500 bounty.
We provide a full timeline of the disclosure process here. The rest of the post details how we discovered the two vulnerabilities, how we used claude models, as well as our takeaways from this experience.
- 25 July 202605:00–06:00 UTC
Initial Finding
HacktronAI team obtained remote code execution (RCE) and administrative access to the Discourse environment hosted at
community.openai.com. - 25 July 202608:00–10:00 UTC
Bugcrowd Submission
After confirming the cross-product impact, the team coordinated internally on the responsible disclosure process and submitted a report through OpenAI’s Bug Bounty Program on Bugcrowd.
- 25 July 202613:30–15:30 UTC
OpenAI Employee Account Access & Proof of Concept
To demonstrate the practical impact of the vulnerability, we created a harmless proof-of-concept pull request in OpenAI’s internal monorepo (link redacted at OpenAI’s request). We updated the existing Bugcrowd submission with these findings, reached out to friends at OpenAI on Twitter/X to notify them directly, and ceased all further testing at approximately 15:30 UTC.
- 25 July 202622:49:45 UTC
OpenAI-Side Fix Confirmed
OpenAI replied to the report confirming the issue had been fixed, roughly 14 hours after the initial submission.
- 25 July 2026
Discourse Reported via HackerOne
We submitted a report to Discourse through its HackerOne program.
- 26 July 2026
Discourse Responded
Discourse replied to the report on Sunday.
- 27 July 2026
Discourse Fix Ready
Discourse had a fix ready by Monday and added image-processing sandboxing as defense in depth.
- 28 July 2026
Discourse Advisory Published
Discourse published GHSA-vhm9-85gw-x335 with patch and rebuild guidance.
- 01 Sep 2026
OpenAI Rewarded $6,500 Bounty and Marked Resolved
OpenAI comment — To clarify the scope of that award: testing against the Discourse-hosted community.openai.com was explicitly excluded from our bug bounty program. The award recognizes the OpenAI-side finding, not the actions against Discourse.
Background
A few months ago, our team at Hacktron, led by Harsh Jaiswal alongside Mohan Pedhapati and Rahul Maini, began researching frontier AI companies to find security vulnerabilities. This led us to discover an SSO misconfiguration in OpenAI’s identity infrastructure and a libheif RCE in the community forum used by OpenAI.
We’ve since expanded the research into HEIF Heist, a multi-month investigation tracing libheif across Slack, Meta, GitHub Enterprise, Ruby on Rails, and Node.js frameworks such as Next.js, Astro, and Gatsby. A surprising amount of widely-used software depends on this one image-processing library.
If your application processes user-controlled images and accepts .heic/.heif/.avif images, it is highly likely it is affected. Please reach out to us at hello@hacktron.ai if you need any kind of assistance.
Hacking community.openai.com
Warning
Patch notice: If you self-host Discourse, rebuild your installation now. Older Docker images may contain a vulnerable libheif dependency that permits code execution through an image upload. Run git pull followed by ./launcher rebuild app from /var/discourse; a web-interface update alone may not replace the underlying image. Discourse-hosted customers have already been patched. See the security advisory.
OpenAI uses Discourse for their forum and allows “Sign in with OpenAI” through auth.openai.com. After getting a good understanding of OpenAI’s services and infrastructure, we had reason to believe that compromising the forum could create a path into broader OpenAI services through this identity flow. To test that hypothesis, we first needed remote code execution on an OpenAI service like the Discourse community forum.
While the Discourse app itself is actually not an easy target (we have looked into it in the past), we thought we could go after a dependency.
Heap buffer overflow in libheif
On July 23, we started reviewing Discourse’s image-upload pipeline, and we found that HEIC and HEIF files followed an unusual path. Discourse normally used FastImage for image checks, but because FastImage did not support HEIF, it passed those files to ImageMagick’s magick command for conversion.2 That exposed the underlying libheif parser directly to attacker-controlled files.
We started an Opus 4.8 session with the Discourse Docker image and asked it to inspect the installed libheif package for security issues. After a while, it found that some particular security fixes were not back-ported to the libheif package. This allowed an heap buffer overflow leading to OOB R/W primitives during HEIC decoding.
Interestingly, the vulnerable code had been changed upstream the previous year, but the commit was not documented as a security fix and received no CVE.3 This might be a reason why Debian 12 and 13 have not received the security relevant backports in time. Because Discourse’s Docker image was based on Debian 12, it installed the vulnerable libheif version 1.19.7. Even Debian 13 still shipped the vulnerable version 1.19.8 at the time. Since then, Debian has published its security update for Debian 13 on August 8, 2026. 4
On July 24, we used Opus 4.8 to develop a working ImageMagick/libheif code-execution exploit with ASLR disabled. We then launched several separate sessions to make it reliable against Discourse’s default configuration with ASLR enabled, which wasn’t fruitful.
Opus 5 Released
That evening, Anthropic released Claude Opus 5.5We started a new session, which first produced a working ARM64 exploit for a local Mac within 3 hours. We then asked it to port the exploit to the x86-64 environment and jemalloc configuration used by Discourse.
By 6:00 a.m. on July 25, we had confirmed local RCE through an image upload. We then placed Claude in an autonomous /goal loop against our own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a CTF target as Opus refused write exploit for remote instances.
When we checked again at 10:00 a.m., the agent had achieved RCE on Discourse Cloud and demonstrated access by reading /etc/hosts. Using the generated exploit script, we managed to get RCE on OpenAI’s instance.
After we had confirmed our hypothesis of no interaction account takeover of ChatGPT/Codex accounts from active members of the forum, we immediately sent our report to OpenAI. We then took over an OpenAI employee’s account, whose Codex was connected to OpenAI’s Github organization. To demonstrate impact without actually accessing any internal code, we sent a prompt to this employee’s Codex account to open a PR for us in OpenAI’s internal monorepo. Then we stopped any further testing.
We updated the BugCrowd submission with the impact proof and alerted OpenAI security. We also prepared a report for Discourse and reported it to their HackerOne program. Discourse received the report on a Saturday, replied on Sunday, and had a fix by Monday (kudos for speed). They also immediately started sandboxing ImageMagick.
We want to emphasize that the vulnerability to escalate is not Discourse-specific. It is an OpenAI SSO issue that turned the forum compromise into access to ChatGPT and Codex. If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to same access - Discourse was merely one way of proofing it.
Costs of finding these vulnerabilities
The Discourse and OpenAI hack took a few days for an agent, and just a few hours of human time. The whole HEIF Heist research project going after Slack, Zoom, Meta, adn more took two-months, cost less than $3,000 in tokens in total, and was conducted by three researchers. Adapting the exploit to each new company usually took only one or two days.
We observed that every new model is getting increasingly capable, as evident by the Discourse exploit presented in this report. Opus 4.8 struggled across several sessions to produce a working exploit with ASLR enabled. Within hours of Opus 5’s release, we gave it the same problem and it succeeded. Across the broader campaign, we saw another clear jump from Opus 5 to GPT-5.6 Sol, when we had to exploit the vulnerability without knowing anything about the target system besides that it’s vulnerable.
For each target, testing began with an image upload. From there, we turned memory corruption into a reliable memory leak or shell, usually without knowing the exact libheif version, libc version, or deployment environment. The AI started almost blind and adapted the exploit for each company within one or two days. We are not aware of any company that detected the activity except Shopify, even after thousands of images were sent and their image processors repeatedly crashed.
When code execution landed inside a sandbox or restricted environment, the models also helped with privilege escalation, lateral movement, and bypassing existing defenses. This was not completly autonomous hacking, and skilled human guidance remained important, but the amount of work a small team could perform increased dramatically.
Epilogue
Software has long benefited from a kind of security through complexity. The code and even the vulnerability could be public, but turning a bug into a reliable exploit still required rare expertise, significant time, and knowledge of the target environment. Known memory corruption vulnerabilities were expensive to operationalize, while zero-days were mostly reserved for the highest-value targets.
This was never a real security boundary, but it protected ordinary companies in practice from software vulnerabilities. AI is removing that protection by turning more of this scarce expertise into compute. Work that once required a well-resourced team and months of effort can now be compressed into days.
Security assumptions must catch up with attacker capabilities. A realistic threat model should take into account the economics of exploitation today, instead of relying on outdated assumptions 6 about who can carry out sophisticated attacks.
Hacktron’s mission is to help secure the internet by finding and eliminating vulnerabilities in widely trusted software before malicious actors do. We are continuing this research across frontier labs and other internet-critical systems. If you are responsible for securing one of them, we would like to work with you.
Versions affected and patches
HEIF Heist is not tied to a single version. It targets an entire ecosystem of vulnerabilities across multiple release families (e.g. 1.19.x, 1.20.x, 1.22.x, 1.23.x). Any deployment lacking the latest upstream security patches is potentially vulnerable.
- Update upstream. Install the latest security-patched
libheifandlibde265packages through your distribution’s security channel or an upstream release. As of September 14, 2026, the latest upstreamlibheifsecurity release is v1.23.4; v1.23.2 has been superseded by further security fixes. Distribution packages may carry backported fixes under an older upstream version number, so check the package security advisory as well.7 4 - Defense in depth. Given the complexity of the ISO base media file format and the pace of decoder updates, future memory-safety flaws are likely. Production architectures should disable untrusted HEIF/AVIF decoding where it is not needed, or isolate image-processing pipelines inside hardened, ephemeral sandboxes. ImageMagick’s security policy supports restricting accepted formats and resource usage. 8
Acknowledgements
We thank Sudanshu Rajhbhar for technical assistance, and Zayne Zhang, Fabian Faessler, Robert Chen, and Jessica Ruan for proofreading, reviewing drafts, and providing feedback that improved this post.
References
[2] Discourse: Support for HEIC images ↩
[3] libheif: simplify overlay overlap area computation ↩
[4] Debian DSA-6417-1: libheif security update ↩1 ↩2
[5] Anthropic: Introducing Claude Opus 5 ↩
[6] RAND: A Playbook for Securing AI Model Weights ↩
[7] libheif v1.23.4 security maintenance release ↩
[8] ImageMagick Security Policy ↩
Work with the team behind this research.
Hacktron brings together top CTF researchers, experienced red teamers, and offensive security researchers. We use AI to accelerate security research, finding and eliminating vulnerabilities in widely trusted software before malicious actors do. We’re continuing our research across frontier labs and other internet-critical systems. If you’re responsible for securing one of them, we’d like to work with you.