[Sentry: APP-2SC] iOS EXC_BAD_ACCESS in WebKit WebBackForwardList IPC decoding

[mountiny]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

SENTRY EVENT

Version Number: 9.4.67 / 9.4.68 / 9.4.69
Reproducible in staging?: Needs to be confirmed
Reproducible in production?: Yes — crash is live in production
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A — found via Sentry production crash scan
Email or phone of affected tester (no customers): N/A
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause / Sentry production crash scan
Slack conversation (hyperlinked to channel name): N/A

Action Performed:

1. Open the Expensify app on iOS (HybridApp build).
2. Use the app until a screen backed by a WKWebView loads, then navigate back and forward between web-backed screens.
3. Keep the session going for a few minutes.

Expected Result:

Navigation works and the app stays up.

Actual Result:

The app crashes on the main thread with EXC_BAD_ACCESS / KERN_INVALID_ADDRESS at 0x100000001.

The crashing thread is inside WebKit IPC: WebKit::WebProcessProxy::didReceiveMessage → WebKit::WebBackForwardList::didReceiveMessage → IPC::Decoder::decode → WTF::AtomStringImpl::addSlowCase / WTF::StringImpl::hashSlowCase. The web process sends a back/forward list update and decoding it dereferences a bad string pointer.

Workaround:

Unknown. The app must be relaunched.

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Sentry details

Sentry issue: https://expensify.sentry.io/issues/APP-2SC

Impact (snapshot at filing, 2026-09-03):

• Users (total since first seen): 44
• Events (total): 176
• Users in scanned releases (9.4.67–9.4.69): 1
• First seen: 2025-12-11
• Last seen: ongoing
• Platform: iOS native (HybridApp, com.expensify.expensifylite), iOS 26.x
• Mechanism: mach, level fatal
• Seer actionability: medium

Stack trace (crashing thread, top frames):

main
UIApplicationMain
-[UIApplication _run]
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
IPC::Connection::dispatchIncomingMessages
IPC::Connection::dispatchMessage
WebKit::WebProcessProxy::didReceiveMessage
WebKit::WebBackForwardList::didReceiveMessage
IPC::Decoder::decode<T>
WTF::AtomStringImpl::addSlowCase
WTF::StringImpl::hashSlowCase

Suspected cause: the crash is in WebKit's back/forward list IPC decoding, with no Expensify frames on the crashing thread. Likely a WKWebView that is used or released across threads, or a web view kept alive past its owning controller. Symbolicated Expensify frames are missing, so the first step is finding which web-backed screen is on top when it fires.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @jmusial

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abdulrahuman5196 (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[MelvinBot]

⚠️ Preliminary analysis (low confidence) — treat as a starting point, not a conclusion.

My read: this is very likely an Apple WebKit bug on iOS 26, not an App-repo bug — and the impact doesn't justify External triage.

The crashing thread is 100% Apple WebKit UI-process IPC code with zero Expensify frames. WTF::StringImpl::hashSlowCase faulting inside IPC::Decoder::decode means the UI process is hashing a StringImpl whose buffer pointer is garbage, while decoding a message the WebContent process sent. App JS cannot reach that memory. Combined with iOS 26.x only and 1 affected user across 9.4.67–9.4.69 (44 users / 176 events over ~9 months), this looks like an OS-level defect an external contributor cannot reproduce or fix.

That said, there are three things in this repo that make our process an unusually hostile host for WKWebView, and any of them could be amplifying an OS bug. All three are worth fixing on their own merits.

Investigation details — the three real findings

1. A third-party SDK swizzles and proxies every WKWebView in the process (strongest lead)

The Group-IB fraud SDK is initialized unconditionally at startup (src/setup/fraudProtection.ts:3, no beta gate), and on iOS we enable both Capability.WebView and Capability.Swizzle:

src/libs/FraudProtection/GroupIBSdkBridge/enableCapabilities/index.ios.ts:20-25

The vendor's own header (modules/group-ib-fp/ios/Frameworks/GIBMobileSdk.xcframework/.../GIBMobileSDK-Swift.h:449) describes what that does:

The module tracks all WKWebView objects in the application … If the WKWebView object was subscribed to a navigationDelegate, the WebViewCapability module proxies the delegate … For the WebViewCapability module to work, you must enable the SwizzleCapability module.

Because WKWebView.navigationDelegate is weak, the SDK has to hold its GIBWebViewNavigationDelegate proxy strongly — and "tracks all WKWebView objects" implies it retains the web views too. A retained-but-orphaned WKWebView keeps a live WebPageProxy and back/forward list on the shared content-process connection, which is exactly the object WebProcessProxy::didReceiveMessage services.

This is not a new failure class for us — patches/@fullstory/react-native/details.md documents the same thing (a native SDK outliving RN teardown in HybridApp and holding a dangling pointer).

Caveat: this is inferred from vendor docs for a closed-source binary. I could not read the SDK's implementation, so I cannot prove retention.

2. Every WebView shares one WKProcessPool, and incognito does not isolate it

useSharedProcessPool defaults to true (node_modules/react-native-webview/src/WebView.ios.tsx:57, apple/RNCWebViewImpl.m:181) and no App call site overrides it. incognito swaps the data store, not the process pool. So all ~11 WebView surfaces (wallet statements, bank OAuth, QBO/Xero/NetSuite setup, TravelDot, Test Drive, HR/Merge Link) share one long-lived web content process — one orphan can affect the whole pool.

3. ConnectToHRFlow deliberately orphans a hidden, still-navigating WebView

src/components/ConnectToHRFlow/index.native.tsx:79-87 keeps the OAuth popup WebView mounted after the user backs out, so in-flight redirects can finish. That popup (:141-146) is non-incognito, inside a native <Modal> (separate presented view controller), and can spawn further popups via onOpenWindow. It is the single most likely place in the app to have a WKWebView receiving back/forward-list IPC with no visible owner.

Secondary: react-native-webview 13.16.0 teardown is incomplete

destroyWebView (apple/RNCWebViewImpl.m:620-652) removes the estimatedProgress KVO observer and both script message handlers, but it is only reached via Fabric's prepareForRecycle. dealloc (:320-326) removes neither, and neither path nils navigationDelegate/UIDelegate. There is also an unsynchronized NSMutableDictionary + non-atomic counter in apple/RNCWebViewDecisionManager.m:19-35 mutated from both the main thread and the TurboModule queue — a real heap-corruption source in the same process, though not a direct explanation for this stack.

Also worth a look, unrelated to the above

patches/react-native-webview/react-native-webview+13.16.0+002+certificate-pinning.patch injects TrustKit into didReceiveAuthenticationChallenge and is active in release builds (#if RNC_TRUSTKIT_AVAILABLE && !DEBUG). It is the only Expensify-authored change to the iOS WebKit code path, and details.md records no upstream PR, no E/App issue, and no introducing PR. Worth attributing regardless of this crash.

What I could not check

The crashing bundle com.expensify.expensifylite is the HybridApp/OldDot build, whose native iOS layer lives outside this repository and was not available to me. If the offending WKWebView is created there, none of the above is the cause.

What I'd do

1. Get the active route from Sentry breadcrumbs for APP-2SC. Every WebView surface is a distinct named screen, so one field collapses this from ~11 candidates to one — or shows no WebView screen was open, which would kill every hypothesis above.
2. Confirm the iOS-version distribution. If it is 100% iOS 26.x with no 18.x tail, treat it as an Apple bug, file a Feedback Assistant report, and stop.
3. Cheap empirical test: ship a build with Capability.WebView and Capability.Swizzle disabled (disableCapability already exists at modules/group-ib-fp/src/index.tsx:117) and watch the rate. That isolates finding Some initial fixes and code style updates #1 in one release.
4. Re-triage the label. With 1 user in the last three releases and a zero-Expensify-frame native stack, I'd remove External and either park this under the Sentry tracking issue or close it as an OS bug.

I did not attempt a repro. This is iOS-native and cannot be exercised from the web build.

Possibly related: #100268 (Sentry: APP-8WS, iOS webkit messageHandlers bridge — same Sentry scan batch, different mechanism) and #91302 (top Sentry crashes tracking issue).

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

---

view run

[melvin-bot]

@abdulrahuman5196 Eep! 4 days overdue now. Issues have feelings too...

[mukhrr]

cannot reproduce

[jmusial]

I'm from SWM and I'll take a look @ this

[melvin-bot]

@abdulrahuman5196 Still overdue 6 days?! Let's take care of this!