Only one story this week. Three researchers went from a HEIC upload to getting Write access to OpenAI's internal monorepo in under 72 hours. What was not a surprise to me: every link in that chain was something we already know how to prevent.

On July 25, Hacktron researchers uploaded a malformed HEIC image to community.openai.com, the Discourse-hosted help forum, and got remote code execution on it. A separate flaw in OpenAI's SSO turned that forum foothold into takeover of ChatGPT and Codex accounts belonging to employees and some unaffiliated users. Those accounts had connectors attached, so the team used one employee's Codex to open a harmless pull request in OpenAI's internal monorepo, then stopped testing and reported it. First bug to internal repo access: under 72 hours. OpenAI shipped a fix about 14 hours after the report.

The interesting part is that the path ran through the single system nobody threat models. Action item: go find whatever you have classified as low risk that happens to share an identity provider with production.

🔗 Hacktron: Hacking OpenAI

Discourse's fast-path image checks did not support HEIF, so those uploads got handed to ImageMagick, which fed attacker-controlled files straight into libheif. The heap overflow the researchers used had already been fixed upstream a year earlier, but the commit was never documented as security-relevant and never got a CVE, so the backport never made it into the Debian package in the Discourse Docker image. Discourse had a patch two days after the report, added sandboxing for image processing as defense in depth, and published GHSA-vhm9-85gw-x335 tracking CVE-2026-32882 at 8.8. Your SCA tooling was watching the CVE feed the whole time. The fix was not in it.

The interesting data point: One unlabeled upstream commit defeated the patching pipeline of every downstream consumer of that package. That is the gap between patching as a concept and patching as an operation.

🔗 Discourse advisory GHSA-vhm9-85gw-x335

OpenAI drew a clear line between the two bugs when it talked to SecurityWeek: the image-parsing flaw lived in third-party Discourse, and the account takeover was a separate issue on OpenAI's side. Specifically, the sign-in tokens minted for the community forum carried excessive permissions and granted full API access to the associated ChatGPT and Codex accounts. That is the entire escalation, in one design decision. Hacktron makes the same point from the other end: any first-party or third-party service sitting on that SSO would have produced the same access, and the forum was just the door they happened to prove it with. OpenAI narrowed the permissions on those tokens and revoked affected tokens and sessions.

Practical takeaway: Pull up the scopes your SSO hands to your least important integration this afternoon. Nobody writes "grant full API access to the help forum" in a design doc, and yet.

🔗 SecurityWeek

Chris Hughes ran the numbers on this last week and they are worth quoting to anyone who thinks the fix side is solved: Project Glasswing has 26,153 findings with 202 verified fixed, and Patch the Planet, a program where Trail of Bits engineers write the patches for maintainers, has 215 of 1,646 findings merged. Bob Lord has been arguing the language side of the same problem, proposing we retire "zero-day" in favor of two states that actually assign ownership: an unfixed software vulnerability is the manufacturer's problem, an undeployed fix is the operator's problem. The libheif bug was neither, which is the uncomfortable part. It was fixed and unlabeled, so no operator on earth had a reason to deploy anything. Bob's related piece on retiring "sophisticated" threat actors lands here too, since the word mostly works to make a preventable failure sound inevitable.

Action items: Both are worth reading in full this week. Then ask your team the honest version of the question: how would we find out about a fix that never became a CVE?

🔗 Resilient Cyber:

Here is the claim: look at Hacktron's own chain diagram and count how much of it is exploitation. One box. Every other box is an architecture decision made months or years earlier by someone who was not thinking about attackers at the time. Route HEIF to ImageMagick because the fast path does not support it. Put the help forum on the same SSO as the product. Mint one token class and use it everywhere. Let a coding agent hold a live GitHub connection. Each of those was reasonable in isolation. Assembled, they were the attack.

The fix side does not bail you out of bad design: OpenAI closed its side in 14 hours, which is genuinely fast, and it still took 14 hours during which the researchers already had employee accounts. Speed is not a substitute for reach.

So the order of operations is the one I keep landing on. Fix the architecture first, because it removes steps from the chain rather than shortening the window on one of them. Then patch, and patch faster, because unfixed things still get exploited and nothing here argues otherwise. Then contain, on the assumption that both of the first two will fail somewhere, which is the argument I made back in Vol 20 and this incident is a cleaner example of it than anything I had then. The concrete version for most teams: draw the trust boundary between your low-value systems and your identity provider, scope tokens to what the integration actually needs, stop decoding image formats you do not need (Hacktron's own defense-in-depth note points at ImageMagick's security policy for exactly this) and sandbox the ones you do, and treat connector permissions on an AI account as production access, because that is what they are.

If you have a working answer for catching upstream security fixes that never get labeled as such, I want to hear it, because I do not have a good one. Hit reply.

The commit that fixed this bug upstream is titled "simplify overlay overlap area computation." A maintainer wrote that. Not their fault at all. It is just a reminder of how much of our security posture is riding on the wording of commit messages.

What am I getting wrong here? Tell me.

Amir

Thanks for reading The AppSec Signal, DevArmor’s newsletter for security professionals.
Have feedback or ideas for what we should cover next?
Feel free to reach out - [email protected]