Capturing an Apple Target Flag in XNU - Part 2: Internal Duplicate
Previous in this series: Capturing an Apple Target Flag in XNU - Part 1: Fixed in Beta
Bug bounty programs give independent researchers a way to report vulnerabilities privately and receive a reward for eligible work. That gives a vendor time to fix a bug before its details or a working exploit spread. Exploit brokers and surveillance vendors also pay for bugs used in attack chains.
Amnesty’s Pegasus Project reported evidence that family members of Saudi journalist Jamal Khashoggi were targeted before and after his 2018 murder.
When Apple redesigned its bounty program in 2025, it framed the changes around the same threat:
“Mercenary spyware attacks typically chain many vulnerabilities together, cross different security boundaries, and incrementally escalate privileges.”
What Is a Target Flag?
Each supported Apple device generates test values called Target Flags, and capturing one through a real vulnerability helps prove that the bug is exploitable and could be combined with other bugs in an attack chain. I explained this in a little more detail in Part 1.
Apple raised its top reward to $2 million, with bonuses that can push the maximum beyond $5 million, and introduced Target Flags as objective proof for faster award decisions.
I later captured another kernel Target Flag with an APFS bug that was assigned CVE-2026-84523. This time I followed Apple’s advice: I tested the newest beta and submitted the complete report with the flag.
Apple gave no indication of a duplicate before the September 14 updates.
Apple’s public advisory credits me and an anonymous researcher.
Apple later marked it as a duplicate of an issue it had found “internally”.
What Apple Published
As of this post, Apple’s public bounty guidelines say:
“Only the first complete and actionable report we receive for an issue is eligible for a reward.”
Apple’s Target Flags page says:
“the specific flag that you capture confirms the level of exploitability you achieved”
This is the part I think is unfair: I could not find anything in Apple’s published guidelines or terms saying that an internal finding can close an outside report as a duplicate. I had not seen this reported publicly before similar notices appeared across many accounts on September 15, 2026.
My mDNSResponder Reports
The same batch affected my two mDNSResponder reports. They shared one root cause but had different effects. Apple fixed and credited both under CVE-2026-43806, as described in an earlier post.
The portal first marked the read report as bounty-awarded, then changed it to a duplicate before I received payment. The write report is marked resolved and lists me as the first reporter. Since both came from the same root cause, I hope Apple will review this decision.
Researchers Losing Trust
Some researchers said they were done reporting to Apple. @frostcrunch18 said the same treatment had affected many reports and that pending bounties and credits had been reversed.
Post by @frostcrunch18 about leaving Apple's program
Post by Gergely Kalman (@gergely_kalman)
Post by @frappehv about a report reclassified as an internal duplicate
Post by @thedawgyg about an internal duplicate decision
Post by @avokadopwn about the incentive this creates
Final Note
Duplicates happen in every program, but leaving reports open for months or years before marking them as “internal duplicates” is not sustainable; I hope Apple hears the researchers speaking out on X and acts before more leave the program.
I will not publish technical details unless someone else has already made them public or users have had enough time to update.