Do the research on macOS for around 1 year, share some of my experience in Apple Security Bug Program.

  1. Overall, the experience is positive, score: 85/100.

  2. Apple does pay big bounties. For macOS vulnerabilities, the bounty amount is less than iOS’s and smaller than what’s listed on their official website. However, even so, the bug bounty for macOS vulnerabilities is significantly higher than that of other OEMs, sometimes more than 10 times higher. I think only Web3 can pay more than Apple. For most local vulnerabilities, the bounty Apple paid is comparable to black market. I didn’t find any RCE, so I’m not sure about that. On the other hand, if you receive many bounties from Apple, you might not research other platforms because the bounty gap is so large. Finding one Apple bug is equivalent to finding 7 or more bugs on other platforms. I didn’t research iOS, but after talking with friends, I can confirm that iOS bounties are real, as listed on their website. They pay based on the impact rather than the CVE. Sometimes, even if a vulnerability is low or medium in severity, as long as user information is leaked or damaged, Apple will pay bounties. The minimum bug bounty is 5k, meaning that a low-severity vulnerability in Apple products may earn more than a high-severity vulnerability on other platforms.

    Checking the category on their website, if a vulnerability exists but is not in the listed category, Apple may not pay the bounty.

  3. The bug bounty confirmation process is unclear. Sometimes it’s very fast, with confirmation on the same day the CVE is published. Other times, even after the CVE is published, I’ve had to wait months, not weeks, for the bounty. I don’t know why. If researchers have questions about the bounty, Apple will recheck it, which can take months. The payment process is fast and finishes within a month.

  4. The patching process is quite lengthy. The fastest patched vulnerability of mine was CVE-2023-42850, which was my first confirmed vulnerability. I submitted it on 2023.08.09, Apple patched it on 2023.10.25, and I received the bounty a month later. When I first ventured into the Apple research field, I had heard that the processes were generally very long. However, since I received the bounty in just a few months, I initially thought, “Wow, Apple has made some changes! The process is so fast.” The fact is, I was wrong :)

    Another vulnerability I submitted on 2023.07.20, a general TCC bypass, received a response saying Apple would refactor the function, requiring more time on patching. To date, the patch schedule isn’t ready. I estimate it might be addressed in Fall 2025. In other words, Apple might take over two years to address a general TCC bypass vulnerability, which has never happened with other platforms. I discussed this issue with Apple, and the keyword in their response was “regression”. If a vulnerability is exploited in the wild or is an RCE, they patch it ASAP. For other vulnerabilities, “regression” is their main concern. Sometimes Apple uses the same code across multiple platforms, so this situation is understandable, of course, the main reason is that they pay big bounties :) Money makes the mare go.

    • Actually, sometimes this is a good thing because we, researchers, can have a longer time to update the information. For example, if I submit a vulnerability on 2024.01.01 and Apple patches it quickly, within three months, on 2024.04.01, we would only get 5k. However, since Apple might take more than a year to address this vulnerability, for instance until 2025.01.01, we then have more time to supplement details. This means that during the prolonged fixing process, we can refine our findings or discover additional useful information to increase the impact, which might result in a higher reward. This has happened to me multiple times because modern operating systems are complex, and deeper research often reveals new tricks, turning what initially seemed like a low-value “trash” vulnerability into a “goldmine”.

    • Of course, this also has downsides. I currently have around 20 unsubmitted vulnerabilities because they are related to previously submitted ones. When Apple patches those submitted vulnerabilities, their fixes might block these unsubmitted ones. Conversely, if Apple chooses the wrong way to patch the submitted vulnerabilities, the unsubmitted ones might become exploitable. This is why I don’t submit these vulnerbailities. I don’t think this benefits Apple because it increases the risk of exploitation.

  5. The report status is unreliable. Apple can modify it at any time. For example, if Apple tags a report as “Spring 2025,” it doesn’t guarantee they’ll patch the vulnerability in Spring 2025. New problems might lead to a status change.

  6. Most vulnerability assessments are accurate, with only a few incorrect evaluations. Sometimes, mistakes occur because they don’t fully understand the vulnerability. I think this is understandable because everyone will make mistakes, as long as they are open to negotiation.

  7. I had two bad experiences too:
    1. Last year, I found a vulnerability allowing attackers to inject a persistent payload into a SIP-protected area. EDR/XProtect or users, even with root and FDA access, couldn’t delete the malware unless they knew how it was injected. Apple was hesitant about this case, changing the report status multiple times before closing it, reasoning that EDRs could delete the malware the same way it was injected. I accepted this. However, two months later, I discovered I could use the feature to achieve a general TCC bypass. When I tested it on macOS 15.0 preview before submitting it, I found Apple had silently patched the vulnerability without giving me credit or a bounty. Apple provided no explanation.
    2. I reported a general TCC bypass vulnerability that could be weaponized and worked across many macOS versions. Apple acknowledged its validity and thanked me for the report, but they decided to close it, because fix it would take too much time. What?? This does confused me. I plan to disclose this vulnerability next year, 1 year later after I submitted the vulerability. Apple still has half a year to decide patch it silently or not. However Apple finally handle this vulnerability, I believe I have been more than ethical. If any user damaged, I won’t treat it as my problem because I’ve shared the risks with Apple half a year ago.

  8. When you find multiple vulnerabilities in a single attack surface, submit them one by one rather than all at once. For example, suppose you find three vulnerabilities: A, B, and C. Submit A first. After Apple patches A, submit B, and after B is patched, submit C. If you submit all three together, Apple may refactor the relevant code or function, applying a single patch to fix all three vulnerabilities. By submitting them one at a time, you ensure that each vulnerability is addressed separately, resulting in three credits and bounties rather than just one.

    Actually I believe this is a bad practice. Apple establishes the ASB program because Apple wanna protect users, so Apple should encourage researchers to submit their findings ASAP to speed up the resolution process and provide protection for users in few months. If researchers delay and submit vulnerabilities one at a time, addressing all the issues could take over years, leaving users exposed for a longer period.

    Some OEMs adopt better practices, offering higher bounties, sometimes double, for SDK vulnerabilities or cases where a single patch addresses multiple distinct vulnerabilities. This incentivizes researchers to submit findings more promptly. Unfortunately, Apple does not currently follow this approach.

  9. Now, I haven’t been fully focused on Apple bug hunting for a few months because there are too many unpatched vulnerabilities. I’m not even sure which attack surface I should target anymore. As I mentioned during Blackhat 2025, the main reason I started researching macOS was to adopt my simulation and fuzzing system for Android Trusted Applications to Apple’s ecosystem. However, after some research, I realized that memory corruption vulnerabilities are not an effective way to exploit macOS or iOS due to their extensive security protections against memory corruption exploitation. For example, if I find a UAF on Android or other products, I can often complete the entire exploit with just this one vulnerability. On some IoT devices, a single heap overflow might be sufficient to exploit without requiring any additional information leakage vulnerabilities, as ASLR is disabled.

    As an independent security researcher, hunting for memory corruption bugs on macOS and iOS feels like gambling. A full exploit chain typically requires 3–5 vulnerabilities. If I were part of a team where each member focused on a different target, this approach would work well. But as a solo researcher, I would need to exploit each vulnerability in the chain one by one. While I’m confident in my ability to analyze or fuzz the target, this process is obviously very time-consuming. Completing a full exploit chain alone would take months or even longer. Successfully finding a single vulnerability that doesn’t get collided within a year is possible. However, finding 3–5 unique vulnerabilities for a full chain, all of which remain uncollided for an entire year, seems highly unlikely. This creates a significant risk of falling into an endless cycle of discovering a vulnerability, having it collided, and then needing to discover another, repeating this process without ever completing the chain.

    If I find an arbitrary address read or write vulnerability, it might be good but ultimately useless for me because I cannot exploit it directly, there still exists a long way we need to go. It cannot be used in competitions like Pwn2Own or TianfuCup, the only option is submitting them to Apple. On the other hand, finding a logic bug usually means finding a directly exploitable vulnerability, which is much more efficient.

    • This perspective has shifted somewhat now due to the backlog of unpatched vulnerabilities :) Building a fuzzing system is currently a productive way to pass the time.
    • At the moment, I’ve started researching Web3 as well. Exploring a new field may bring fresh opportunities to discover bugs :)