Well, it is probably time to share my impressions of participating in Apple Security Bounty. I reported two vulnerabilities:

• Apple rejected the first vulnerability. I wrote about it on this blog. If you do not have time to read all the technical details, you can just read the timeline. It is basically a little story of its own.

• Apple accepted the second vulnerability (CVE-2026-64725), but assessed it as… mmm… conservatively as possible: as a DoS, even though it involved a fully attacker-controlled OOB write.

Honestly, my experience could have been much better, but it is what it is — in this blog post, I mostly write about the things I did not like. And I compare Apple a little with other players in the vulnerability market.

Disclaimer! All of this is subjective and reflects only my own experience.

What is Apple Security Bounty?

As far as I understand it, the main purpose of Apple Security Bounty is to offer security researchers some kind of alternative to the gray and black vulnerability markets. In theory, a security researcher can receive up to $2M, which is a perfectly competitive amount.

In practice, however, the payouts are usually much more modest, and on average the gray and black markets still win the financial competition for security researchers. So, in addition to what is fairly modest money by industry standards, Apple offers:

• legality (your hat is whiter than snow)
• an opportunity to make the world a better place (your moral right to lecture strangers on the internet becomes indisputable)
• recognition (your name in Apple security releases — what employer could possibly resist?)

And, well, Apple does offer some money too. Moreover, Apple may sometimes pay even for a vulnerability that is very difficult or impossible to exploit, and therefore no one else would pay for it.

How it works

I already wrote a little about Apple Security Bounty in one of my previous posts. Overall, it is quite simple:

1. Log in at https://security.apple.com/reports/ (anyone with an Apple ID can do this). It is Apple’s issue tracker. This is generally logical because, from a development perspective, a vulnerability is an issue that needs to be fixed.

2. Click “New Report”.

   

   This opens a form where you are asked to provide the Report Details, attach a Proof of Concept if you have one, and specify the Credit Information—your moment of fame. I am not including screenshots of the form because everything there is fairly self-explanatory.

3. Once you have completed the form, click “Submit” to create a new issue. Apple recommends creating a separate issue for each vulnerability you report.

That is it. From that point on, you can track the status of your issue and communicate with the Apple Security Team through its comments.

A few words about the Apple Security Bounty issue tracker

There were some things I did not like about the issue tracker:

1. Primitive functionality. It feels as though Apple saved quite a bit of money on developing this issue tracker. It lacks basic features such as a proper status history or the ability to edit comments.

2. Poor optimization. Even over a gigabit connection, it takes a some time to load, never mind LTE or 4G.

3. Minor bugs in the issue tracker. Broken notifications were particularly annoying. In theory, any change—such as your issue moving to another status or receiving a new comment—should trigger an email notification. In practice, I received a couple of notifications, after which they broke and stopped arriving. I mentioned this in the issue comments and was told that it would be fixed. After that, I received one more notification, and then nothing. So I had to log in manually from time to time and check whether anything had changed.

4. Short session lifetime. No more than an hour on a mobile device. This means that if you open the issue tracker once a day to check for updates manually, you have to log in every single time and then wait for the whole thing to load. FaceID authorisation helps a little bit.

5. Some of the things I see in this issue tracker are simply incomprehensible. Both in context and out of context. For example, what on earth does the “In Beta” tag mean on a vulnerability that has already been fixed and shipped to production?

   

   I do not understand. Does it mean that some fix is present in a beta version of macOS or iOS? Apparently not, 26.6 is not a beta. So what exactly is it?

As a result, the whole thing turned into a fairly unpleasant user experience. After reporting two vulnerabilities, I had to log in to the issue tracker every day, wait for it to load, and manually check whether anything had changed in the corresponding issues. I could track comments by their date and time, but issue statuses were much more problematic. As I mentioned above, there is no proper status history, so I could only see the two most recent statuses. How many statuses had actually changed between my logins? What were those statuses? Questions without answers. On top of that, I did not always understand what exactly I was looking at or what any of it meant. In short, the user experience was not particularly impressive.

Communication

I see three problems here:

1. The entire vulnerability assessment process is mostly opaque. What rules does Apple use to assess a vulnerability? Why does it make one decision rather than another? This is very difficult to understand. For example:

   • Why does Apple treat CVE-2026-64725 exclusively as a DoS? My report demonstrated a stable and controllable heap/stack OOB write. Was it not enough? Why?

   • Why did Apple accept CVE-2026-64725 and reject the OOB read with very similar signed/unsigned integer issue?

   No clear answers, just guesses 🤷‍♂️

2. It is even harder to influence Apple Security Team decisions in any meaningful way. The only thing that sort of works is the potential dusclosure. Apple closes the issue without explanation, I write a comment: “Fine, if this is not a vulnerability, I will publish it.” Apple, again without explanation, reopens the issue. It creates this unpleasant feeling that I am trying to blackmail them into doing their job properly.

   I already gave the link to the timeline at the beginning of this blog post; check it if you have not done so yet and read how Apple reopened the issue twice because I wrote that I would publish / had already published a PoC / writeup. In the end, it did not work, but at least they tried and even explained their decision once.

3. Questions in the comments are answered about half the time. Well, they do answer, occasionally.

This experience is very different from negotiating with other players in the market, where you can make your case and bargain. Here, you simply sit and wait for the Apple Security Team to decide. And agree with the desicion, of course, what other options you have?

Is it worth it?

Honestly, I see four main reasons to participate in Apple Security Bounty these days:

1. you want to do some good without expecting anything in return

2. you want to see your name in Apple security releases

3. you want to try it simply because you are curious about how it works

4. you have found a vulnerability that cannot be exploited in the real world, and therefore other players on the market will not buy it from you — you can report it to Apple; maybe they will give you something for it (money, or at least a CVE)

Unfortunately, I do not see any other reasons to report anything to Apple in 2026.

⭐️ 3.5 / 5