Listen to this Post
Introduction:
The relationship between security researchers and technology giants has always been a delicate dance—researchers hunt for vulnerabilities to strengthen ecosystems, while vendors weigh risk, resources, and reputation. A recent exchange between researcher Maher Azzouzi and Apple’s Product Security team has reignited a long-simmering controversy: when is a bug truly a duplicate, and why do researchers increasingly feel their work is being dismissed, delayed, and devalued? Azzouzi’s saga—reporting a stable out-of-bounds (OOB) read/write vulnerability, only to be told it was a duplicate of his own previously reported use-after-free (UAF) CVE, then closed as “not reproducible,” and finally acknowledged months later for a Summer 2026 patch—exposes systemic fractures in Apple’s bug bounty program that threaten to chill the very research the industry depends on.
Learning Objectives:
- Understand the technical distinctions between use-after-free (UAF) and out-of-bounds (OOB) read/write vulnerabilities in iOS kernel contexts.
- Analyze the structural and procedural failures in Apple’s bug bounty triage and duplicate classification system.
- Learn practical command-line and debugging techniques to identify, reproduce, and document memory corruption vulnerabilities across Linux, macOS, and iOS environments.
You Should Know:
- UAF vs. OOB: Same Exploit Chain, Different Root Causes
Use-after-free and out-of-bounds read/write are both memory corruption classes, but they stem from fundamentally different programming errors—and Apple’s tendency to conflate them in triage is a recurring point of friction.
A use-after-free (UAF) occurs when a program continues to use a memory pointer after the memory it points to has been freed. The classic iOS 26.2 XNU AIO kevent UAF (patched in iOS 26.3) demonstrates this perfectly: `filt_aioattach()` stored an AIO entry pointer in a knote hook without calling aio_entry_ref(), leaving a dangling pointer. When the I/O completed and the entry was freed, subsequent `kevent64` calls would read from reclaimed memory, leading to kernel panic or double-free conditions.
An out-of-bounds (OOB) read/write, by contrast, involves accessing memory outside the bounds of an allocated buffer. CVE-2026-43655, fixed in iOS 26.5, is an OOB read where improved bounds checking was added to prevent an app from reading kernel memory or causing system termination. CVE-2026-28972 represents an OOB write with a CVSS score of 7.8, fixed across iOS 26.5, macOS Tahoe 26.5, and other platforms.
The critical distinction: UAF is a lifetime issue (the object exists but shouldn’t be used); OOB is a boundary issue (the object is valid but accessed outside its range). Conflating them as “duplicates” is not just procedurally sloppy—it’s technically incorrect and can delay proper mitigation.
Linux/macOS Debugging Commands for Memory Corruption:
Enable kernel memory debugging on Linux sudo echo 1 > /proc/sys/kernel/panic_on_oops sudo echo 1 > /proc/sys/kernel/panic_on_unrecovered_opt Use Valgrind to detect UAF and OOB in user-space applications valgrind --tool=memcheck --leak-check=full ./vulnerable_app On macOS, use the built-in malloc debugging export MallocStackLogging=1 export MallocScribble=1 ./vulnerable_app AddressSanitizer (Clang) - compile with detection clang -fsanitize=address -g -o app app.c
iOS Kernel Debugging (for researchers with dev-provisioned devices):
Enable kernel panic logging via USB sudo log collect --device --start --output /path/to/panic.log Use lldb to attach to iOS processes (requires developer disk image) lldb -p <PID> (lldb) memory read --force --outfile /tmp/memdump.bin < address> <size>
2. The “Not Reproducible” Excuse: A Moving Target
Azzouzi’s experience—reliably reproducing the OOB vulnerability on the latest public iOS 26.5 beta with a video PoC, only to be told it wasn’t reproducible on Apple’s “latest branch”—highlights a dangerous disconnect. Apple’s internal branches often lag behind public betas, meaning researchers may be testing on more current code than Apple’s own triage team.
Step‑by‑step: How to Document and Submit a Reproducible PoC
- Record device details: Capture iOS version, build number, and device model (e.g., iPhone 15 Pro, iOS 26.5 beta 23C55).
- Create a minimal crash PoC: Strip all non-essential code. For kernel bugs, use the `report_crash` API or syslog.
- Record video proof: Use Apple’s built-in screen recording, ensuring the crash log and panic string are visible.
- Provide sysdiagnose: On the device, press Volume Up + Volume Down + Power, then select “sysdiagnose” to capture comprehensive logs.
- Include reproduction steps: Write a clear, numbered sequence. For race conditions, specify timing and CPU affinity settings used.
Example: Reproducing a UAF Race Condition (Linux)
// Simplified UAF trigger pattern
pthread_t thread1, thread2;
struct obj ptr = malloc(sizeof(struct obj));
// Thread 1: use after free
void use_after_free(void arg) {
sleep(1);
printf("Value: %d\n", ptr->data); // UAF if freed
}
// Thread 2: free the object
void free_obj(void arg) {
sleep(0);
free(ptr);
ptr = NULL;
}
Windows Equivalent (using WinDbg):
!analyze -v !address < address> !heap -p -a < address>
3. Triage Silos: Why Duplicate Classification Fails
Security researcher Mihalis H. succinctly captured the sentiment: “if u ever find target flag they gona say duplicate and pay you zero”. This cynicism is rooted in structural issues. Apple operates in silos: the bug bounty triage team may not have access to kernel source code, making it nearly impossible to accurately assess whether a reported bug is truly novel.
When Azzouzi reported two distinct bugs—a UAF and an OOB read/write—with different root causes and vulnerability classes, Apple’s triage system flagged them as duplicates simply because they shared a CVE prefix or affected similar components. This pattern is not isolated. Mysk’s complaint over CVE-2026-28910 revealed that after five months of discussion, Apple declared their report a duplicate and paid no bounty. Researcher Denis Kanonik observed: “From my experience of reporting bugs to Apple — they never admit that you were the first, it’s always duplicate”.
How to Challenge a Duplicate Ruling:
- Provide patch diffs: If you can show that the fix for your bug differs from the fix for the alleged duplicate, you have strong evidence.
- Cite CWE IDs: Use Common Weakness Enumeration (CWE) identifiers to formally distinguish vulnerability classes (e.g., CWE-416 for UAF vs. CWE-125 for OOB read).
- Escalate via Apple’s Product Security: Request a technical review by an engineer familiar with the affected component, not just the triage team.
- Public disclosure (as last resort): If Apple refuses to engage, responsible disclosure timelines and coordinated public release can force action—though this may burn bridges.
- The Summer 2026 Patch: What’s Actually Being Fixed?
Apple’s acknowledgment that Azzouzi’s OOB read/write would be addressed in Summer 2026 aligns with the iOS 26.5 release cycle. iOS 26.5, released in May 2026, patched dozens of CVEs, including:
- CVE-2026-43655: OOB read fixed with improved bounds checking.
- CVE-2026-28972: OOB write fixed with improved input validation.
- CVE-2026-28994: UAF fixed with improved memory management.
- CVE-2026-28953: WebKit vulnerability credited to Maher Azzouzi.
Verification Commands (iOS/macOS):
Check iOS version settings -> General -> About -> iOS Version On macOS, verify patch status for a specific CVE system_profiler SPSoftwareDataType | grep "iOS" Check if a specific dylib is patched (example for WebKit) otool -L /System/Library/Frameworks/WebKit.framework/WebKit | grep version
Windows Patch Verification:
Get-HotFix | Where-Object {$_.HotFixID -like "CVE-2026"}
wmic qfe list brief /format:texttable
- The Bounty Paradox: $2 Million for Lockdown Mode, $0 for Everything Else
Apple doubled its top-tier bug bounty to $2 million for critical flaws in Lockdown Mode, yet researchers routinely report receiving nothing for non-Lockdown kernel vulnerabilities—even when those bugs enable sandbox escapes or kernel memory corruption. The disparity creates a perverse incentive: researchers may withhold less “sexy” bugs or sell them to brokers like Zerodium, which temporarily stopped accepting Apple submissions due to overflow.
Recommended Security Hardening (Linux/macOS/Windows):
- Linux: Enable Kernel Address Space Layout Randomization (KASLR) and use `grsecurity` or `PaX` patches where possible.
- macOS: Enable System Integrity Protection (SIP) and notarize all applications.
- Windows: Enable Control Flow Guard (CFG) and Arbitrary Code Guard (ACG) via Exploit Protection.
API Security Hardening (REST/GraphQL):
Validate all inputs with strict schema checking (Node.js example)
const Joi = require('joi');
const schema = Joi.object({
id: Joi.string().alphanum().length(24).required(),
data: Joi.binary().max(1024)
});
Cloud Hardening (AWS/Azure):
AWS: Enable VPC Flow Logs and GuardDuty aws guardduty create-detector --enable Azure: Enable Advanced Threat Protection az security atp storage update --enable
- Practical Guide: Building a Memory Corruption Detection Lab
For researchers aiming to find and prove UAF/OOB vulnerabilities, a controlled lab environment is essential.
Step 1: Set up a macOS/iOS testing environment
- Use a Mac with Xcode and the iOS 26.5 beta simulator.
- For physical devices, enroll in the Apple Developer Program ($99/year) to get provisioning profiles.
Step 2: Instrument with sanitizers
- Compile target code with AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan).
- For kernel-level testing, use the `kasan` (Kernel Address Sanitizer) build of XNU.
Step 3: Fuzz with AFL++ or libFuzzer
AFL++ on Linux afl-fuzz -i input_dir -o findings_dir ./target_binary @@ libFuzzer on macOS clang -fsanitize=fuzzer,address -o fuzz_target fuzz_target.c ./fuzz_target corpus/
Step 4: Capture and analyze crashes
- On iOS, use `panic.log` and
sysdiagnose. - On Linux, enable core dumps:
ulimit -c unlimited. - On Windows, use WinDbg or the Windows Error Reporting (WER) framework.
Step 5: Build a proof-of-concept
- Minimize the crash trigger to the smallest possible code.
- Document every step, including environment variables, CPU affinity, and timing.
What Undercode Say:
- Key Takeaway 1: Apple’s duplicate classification system is broken—not because of malice, but because of organizational silos that prevent triage teams from accessing the source code and engineering context needed to accurately assess vulnerability uniqueness. Researchers are increasingly viewing the bug bounty program as a “black hole” where reports vanish for months, only to emerge as duplicates with zero compensation.
-
Key Takeaway 2: The distinction between UAF and OOB is not academic—it’s the difference between a lifetime management flaw and a boundary validation flaw. Conflating them in CVE assignment or duplicate rulings undermines the integrity of the entire vulnerability disclosure ecosystem. Apple’s own security advisories distinguish these classes clearly, yet their triage process does not.
Analysis:
The Azzouzi incident is not an outlier; it’s a symptom of a systemic failure. When a researcher can reliably reproduce a vulnerability on the latest public beta, provide video PoC, and still be dismissed as “not reproducible” on an internal branch, the trust contract between researcher and vendor is broken. Apple’s Summer 2026 acknowledgment—months after the initial report—validates the bug but does nothing to restore faith in the process. The broader security community is watching: if Apple cannot fix its triage pipeline, researchers will increasingly take their findings to zero-day brokers or public disclosure platforms, where they are at least compensated or credited. The $2 million Lockdown Mode bounty is a headline-grabber, but it’s the $0 duplicate rulings that will define Apple’s security culture for years to come.
Prediction:
- +1 Apple will be forced to overhaul its bug bounty triage process by Q1 2027, potentially spinning off a dedicated, engineer-led security response team with full source access, reducing duplicate misclassifications by 40–50%.
-
-1 The current friction will drive a wave of researchers away from Apple’s program toward brokers like Zerodium, increasing the number of unpatched zero-days in the wild and raising the cost of iOS security for enterprise and government customers.
-
+1 Community-driven initiatives like the “Duplicate Disclosure Database”—where researchers share duplicate rulings and CVE mappings—will emerge as a crowdsourced check on vendor triage quality, similar to how CVE.org tracks assignments.
-
-1 If Apple continues to treat researchers as adversaries rather than partners, we may see a “security winter” for iOS, where critical vulnerabilities remain undisclosed for longer, and the average time-to-patch for kernel bugs extends beyond six months.
-
+1 The pressure from high-profile researchers like Maher Azzouzi and Mysk will catalyze legislative action, with policymakers introducing “researcher protection” clauses in upcoming cyber resilience acts, mandating transparent duplicate adjudication and minimum bounty floors for confirmed CVEs.
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Maher Azzouzi – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
