Recurring SIGSEGV crashes on Brave 149.1.91.180 (macOS 26.5.2) — Use-After-Free (0xefefefefefefefef)

Summary

Brave has been crashing repeatedly with EXC_BAD_ACCESS (SIGSEGV) on the main thread. A total of 7 crashes have occurred over the past 10 days, with 2 crashes happening today (June 30, 2026). The timing coincides with recent macOS and Chromium 149 security updates.

Environment

  • Brave Version: 149.1.91.180 (191.180)
  • OS: macOS 26.5.2 (build 25F84), macOS Tahoe
  • Hardware: Mac16,12 (Apple Silicon, ARM-64)
  • System Integrity Protection: Enabled
  • Crash Frequency: 7 crashes over the last 10 days, 2 of which occurred today

Crash Details

Process:             Brave Browser [971]
Identifier:          com.brave.Browser
Version:             149.1.91.180 (191.180)
Code Type:           ARM-64 (Native)
Triggered by Thread: 0  CrBrowserMain, Dispatch Queue: com.apple.main-thread

Exception Type:    EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0xefefefefefefefef
Exception Codes:   0x0000000000000001, 0xefefefefefefefef
Termination Reason: Namespace SIGNAL, Code 11, Segmentation fault: 11

VM Region Info: 0xffffefefefefefef is not in any region.

Analysis

The crash address 0xefefefefefefefef is a PartitionAlloc freed-memory poison pattern used by Chromium’s memory allocator. When memory is freed, the allocator fills it with 0xEF bytes to aid in detecting use-after-free bugs. The crash indicates that:

  1. An object was allocated and subsequently freed (filled with 0xEF).
  2. A dangling pointer to the freed object was dereferenced.
  3. The poisoned pointer value (0xefefefefefefefef) was treated as a memory address.
  4. The address is unmapped, triggering a SIGSEGV on the main thread (CrBrowserMain).

This is consistent with a use-after-free vulnerability in the Chromium 149 codebase.

Potential Connection to Chrome 149 Security Patches

Google released a Chrome 149 security update around June 25–26, 2026, patching 18 vulnerabilities — including 10 use-after-free flaws (reported by Forbes and SecurityWeek). If Brave 149.1.91.180 does not yet incorporate these upstream patches, the same use-after-free bugs would still be present.

The most recent macOS 26.5.2 update (released June 29) included security fixes, some WebKit-related. While Brave uses Chromium’s Blink engine (not WebKit), system-level changes can alter memory allocation timing and behavior, potentially affecting how often an existing use-after-free bug triggers.

Steps Already Taken

  • Updated macOS to 26.5.2 (issue persists)
  • No new extensions installed recently
  • No changes to browsing habits

Questions for the Team

  1. Does Brave 149.1.91.180 include the Chromium 149 security patches from late June 2026?
  2. Is there a newer Brave build available or upcoming that merges these fixes?
  3. Are there any known workarounds (e.g., disabling hardware acceleration) to reduce crash frequency in the interim?
  4. Is additional crash log information needed? I can provide full crash reports via brave://crashes.

Full Crash Report

Available upon request. Key fields included above; happy to share the complete .crash file if helpful.

@kailey

Sounds like an upstream Chromium bug.


https://github.com/brave/brave-browser/wiki/Brave-Release-Schedule

https://versions.brave.com/

Slight delay for Brave Browser stable release v1.92.13n

" Rescheduled. Originally scheduled to release on June 30, 2026."


How do I manually submit crash reports?

NOTE: In a Brave Browser New Window, go to: brave://settings/privacy and ENABLE Automatically send diagnostic reports

READ the guidance:

https://support.brave.com/hc/en-us/articles/22281484910221-How-do-I-manually-submit-crash-reports

After you click the “Send Now” button, return to brave://crashes and gather up the Crash Report ID numbers that end with a string of zeros. Post the numbers, here, in a new reply. Example of a Crash Report ID number: