Dev Breakfast · 2026-09-19
Today's headline: The Internal Repo Earned by a Single HEIC Image: OpenAI Forum's SSO Vulnerability. Plus 4 more: ZCode Silently Uploads 313MB Encrypted Package, Keys Only on the Server; Telstra Outage for a Night: One GPS Receiver Sent the National Network Back to 2006; and more.
A single HEIC image, 72 hours, and it earned PR access to OpenAI's internal monorepo—the entry point was Discourse passing to ImageMagick's libheif 1.19.7, a fix that didn't get a CVE number and was missed by Debian 12. Upstream fixing the code doesn't mean your system is patched; that's the key point to remember from this chain.
The Internal Repo Earned by a Single HEIC Image: OpenAI Forum's SSO Vulnerability
On July 25, 2026, a security team called Hacktron linked two vulnerabilities into a chain, taking over the ChatGPT accounts of several OpenAI employees. They didn't read any internal code; instead, they used the employee's Codex to open a PR in OpenAI's internal monorepo openai/openai, numbered #1186742—using the fact that 'I can submit a PR' itself to prove 'I'm really in.' From initial discovery to gaining repo access, the entire process took less than 72 hours.
The entry point to the chain was absurdly low: OpenAI's own community forum community.openai.com. This forum runs on Discourse, which when processing images, formats like HEIC/HEIF are not handled by FastImage (it doesn't support them), but are passed to ImageMagick's magick command for conversion, with the underlying exposure to the libheif parser. Debian 12 packaged libheif 1.19.7 missed a batch of security backports, leading to a heap buffer overflow during HEIC decoding, providing primitives for out-of-bounds read and write. Upstream had actually fixed this code a year earlier, but that commit wasn't marked as a security fix and didn't get a CVE number—so Debian 12 and 13 both didn't backport it promptly, and Debian 13 was still at 1.19.8. Debian didn't patch it until August 8.
What truly made this chain work was the second link: a configuration flaw in OpenAI's identity infrastructure with SSO. The forum supports 'Sign in with OpenAI', which goes through auth.openai.com. After attackers gained code execution on the forum, they could take over active members' ChatGPT/Codex accounts with no interaction. And Codex and ChatGPT can connect to GitHub, Slack, email, and other connectors—so theoretically, they could access more than just a repository. Hacktron immediately submitted a report after confirming the assumption, then took over an employee's account, submitted that PR, and stopped.
There's an interesting detail on the timeline. On July 24, they used Opus 4.8 to write the exploit, but it only reproduced stably with ASLR disabled. Switching to Discourse's default configuration (ASLR enabled), it wouldn't work at all. That night, Anthropic released Claude Opus 5; they reopened a session, and within 3 hours, first made an ARM64 version on a local Mac, then ported it to the x86-64 + jemalloc environment used by Discourse. By 6 AM on July 25, they confirmed that image upload could trigger local RCE. Then they put Claude into an autonomous /goal loop to attack their own Discourse Cloud instance, specifically proxying through rce.ee/ctf-forum—because Opus refused to write exploits for remote instances, but masquerading as a CTF target made it willing. By 10 AM, they checked again and the agent had achieved RCE and read /etc/hosts.
The outcome was clean: both OpenAI and Discourse cooperated to fix the issue. OpenAI paid a $6500 bounty, Discourse received the report on Saturday, responded on Sunday, and released a fix on Monday, immediately starting to sandbox ImageMagick. Self-hosted Discourse users were explicitly reminded: just clicking 'Update' in the web interface might not replace the underlying image; you need to enter /var/discourse and run git pull then ./launcher rebuild app.
If your service processes user-uploaded .heic/.heif/.avif images, you're likely on the same chain—the problem isn't in Discourse, but in that image parsing library relied upon by countless software without anyone watching it. In this incident, Hacktron expanded the investigation into the 'HEIF Heist,' tracing it all the way to Slack, Meta, GitHub Enterprise, Ruby on Rails, and frameworks like Next.js, Astro, Gatsby. The more troublesome part is the SSO link: 'peripheral systems' like forums, documentation sites, and communities often share the same identity, so entering from the most inconspicuous entry point equates to getting the key to the main system. Compromising one forum could cost an entire organization's connector permissions.
💡 Chef's take: If you self-host Discourse, clicking 'Update' in the web backend may not replace the underlying Docker image; you need to enter
/var/discourseand manuallygit pull+./launcher rebuild app—this is a pitfall many people fall into.
Sources:
ZCode Silently Uploads 313MB Encrypted Package, Keys Only on the Server
A developer named ferstar discovered while cleaning up his disk that ~/.zcode was taking up over 700 MB. He looked inside and found a 313MB .enc file. It came from a 345MB commercial project workspace with 42,411 files, packaged, encrypted, and prepared for upload to Alibaba Cloud OSS, but after 564 failed retries, it was still in the local pending directory waiting for the next round. ZCode is an AI coding desktop application from Z.ai, the company behind the GLM series of models.
The most intriguing part is the encryption method. It uses standard envelope encryption: the content is encrypted with AES-256-CTR, and the symmetric key is wrapped with an RSA-OAEP public key. The issue lies in the source of the public key—it's issued by the server when requesting upload credentials, and the corresponding private key only exists on Z.ai's cloud. ferstar tried all local private keys to decrypt the envelope, all failed. This means that the 313MB ciphertext is on your own hard drive, but neither you nor the ZCode client itself can open it; only the server can read it. If it were truly for cross-device sync or rollback, the key should have stayed local like Git or Time Machine. A key that only the server can use has only one purpose.
The packaging list is stored in plaintext locally, so you can see what's inside: the .git directory accounts for 86.6%, including LFS cache 196.1MB, objects 102.2MB, reflogs 0.6MB, and only 46.2MB for source code and documentation. The git object database isn't a workspace snapshot; it's the complete lineage of the entire repository from day one—including API keys deleted in subsequent commits, branch names that haven't been pushed, and internal GitLab hostnames in .git/config. The two toggles in settings can't block it: 'Optimize Experience' only controls whether data can be used for model training, and 'Repository Snapshot Index' only controls whether the server indexes uploaded snapshots; local packaging and uploads still proceed. The fetching sidecar instantiates unconditionally at startup, running continuously as long as the token is valid; logs show a single session triggered 62 fetches.
Running local models with GLM weights and using Z.ai's client are two different things. Open-source weights don't mean open-source harness; many people confused this. Here's an immediate action: log out of ZCode or uninstall it entirely and switch to an open-source harness; if you've already used it, rotate those keys and tokens in .git that should have expired long ago—they're now under someone else's key protection.
Sources:
Telstra Outage for a Night: One GPS Receiver Sent the National Network Back to 2006
On July 8, 2026, Telstra, Australia's largest mobile operator, experienced a widespread network outage. Voice calls didn't connect, SMS wasn't received, and even emergency calls failed; affected were not just mobile phones but also trains, payment terminals, ticketing systems, and electric vehicle charging stations. There was no attack, no cable cut, and power was normal. The cause was a GPS receiver in a Melbourne cabinet that, after routine maintenance, returned and determined the current year was 2006, and then the entire network was convinced by it.
Afterwards, Telstra commissioned an independent investigation by Technology Audit Partners (TAP), and the report was clear: this timing architecture, designed in 2010, was assessed as 'fit for purpose'—taking time from Australia's National Measurement Institute (NMI), feeding into two stratum 2 servers in Sydney and Melbourne, then down to three stratum 3 servers in Sydney, Melbourne, and Perth, followed by thousands of mobile network nodes. The problem arose in a 2020 upgrade: the newly installed NTP timing cabinets did not allow stratum 2 to feed stratum 3 within the same device; only Sydney's stratum 3 could take time from Melbourne's stratum 2, and Melbourne from Sydney. The result was that each site had only one stratum 2 source, reducing redundancy, and the TAP report explicitly noted this was 'known and accepted.'
NTP originally had two lines of defense: under equal conditions, lower stratum has higher weight, and multi-source comparison, where the source that doesn't match reasonable time is voted out. These defenses hold only if the time sources heard by clients are truly independent. Once the topology is changed to cross-feeding, independence is lost, and one off-track receiver can take the entire layer with it. 5G heavily uses TDD, where every cell must switch transmit-receive directions in sync on the same frequency band; if any clock drifts, it will transmit data into the neighbor's receive window, causing the network to interfere with itself—time precision isn't a luxury here, but a hard constraint at the microsecond level.
For programmers, the lesson from this incident isn't about the operator. Every external time source you depend on, every assumption that 'everyone agrees on what time it is,' deserves a second look: is the source truly independent, is there a second path after degradation, and has someone ever documented 'reduced redundancy' in a change log and signed off on it. The original article didn't specify how long this outage lasted or how it was later restored.
Sources:
100TB of Memory: Gained from a Minor Algorithm Tweak
In Cloudflare's Pingora Backend Router, the consistent hashing library pingora-ketama was consuming far more memory than expected. They didn't replace hardware; just changing an algorithm significantly reduced the per-service usage, reclaiming over 100TB of RAM globally—and just last month, the DNS team had freed up a similar 100TB. Interestingly, the space saved this time came from mathematical re-derivation, not from adding more machines. Those modules in your hands that seem 'already optimized as much as possible' might also hide an uncalculated bill.
Sources:
CrowdSec Source Code Leak: 300 Repositories, Caused by Tanstack Backdoor
On September 16, CrowdSec was externally informed that their GitHub repositories had experienced a source code leak in May this year. The team verified and confirmed. The number of 300 repositories is accurate, but over 130 of them were already public Security Engine; the truly sensitive parts were the SaaS console, some AWS routines, connectors, and automation. The leak entry points to a backdoor implanted in Tanstack components; the attacker used this to obtain an API key that could read private code repositories, a method previously seen in the Mistral AI incident. The official statement said no customer data, account passwords, or PII were leaked, the impact was limited to themselves, and all tokens and credentials have been rotated. What you should care about is not CrowdSec alone: in CI/CD, is that key with code-read permissions too broad, and can it be rotated immediately after an incident? The supply chain link has never been 'I used open source so I'm at risk,' but rather 'if any link in the build chain I trust is tampered with, I won't even know.'
Sources:
Those dependencies in your hands that 'upstream fixed long ago'—dare you check the version numbers now, or trust the distribution packaging first? See you tomorrow at 8 AM.
This issue picked out 5 articles from 62 pieces of information over the past 24 hours on X / Hacker News / GitHub Trending (written hourly throughout the day, fact-checked, and selected in the morning). Content is generated with LLM assistance, each with original source links; for important decisions, please cross-verify.
Like this brief? Get tomorrow's by email
Each morning at 8:00, 5-10 hand-picked AI items in plain language, with full context.
This page is auto-generated by LLM aggregation; please cross-check with original sources.