Intermittent EXC_BAD_ACCESS in VulcanMsgRecv thread (dynamic_cast on freed object) on quit — InDesign 2026 (21.5.1.73), C++ SDK plugin

We're seeing an intermittent crash when quitting InDesign 2026 (v21.5.1.73, macOS 26.5.2, Apple Silicon) while our C++ SDK plugin is loaded. The crash occurs on the VulcanMsgRecv thread, inside a dynamic_cast in VulcanMessage5.dylib, apparently operating on a freed/invalid object (KERN_INVALID_ADDRESS, guard-pattern address).

Two independent crash reports, captured on different days, show byte-identical offsets into VulcanMessage5.dylib (only the ASLR base differs), indicating this is a single deterministic code path rather than a generic timing race:

Crash 1 (2026-08-11): base 0x1028cc000

Crash 2 (2026-08-10): base 0x107784000

Both crashes, same relative offsets:

0 libc++abi.dylib __cxxabiv1::...dyn_cast_get_derived_info + 8
1 libc++abi.dylib __dynamic_cast + 56
2 VulcanMessage5.dylib +101896
3 VulcanMessage5.dylib +100392
4 VulcanMessage5.dylib +101640
5 VulcanMessage5.dylib +100344
6 VulcanMessage5.dylib +105948
7 VulcanMessage5.dylib +104900
8 VulcanMessage5.dylib +104728
9 VulcanMessage5.dylib +68136
10 VulcanMessage5.dylib +65580
11 VulcanMessage5.dylib +114372
12 VulcanMessage5.dylib +245924

Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS, triggered on thread VulcanMsgRecv.

What we've ruled out on our side (plugin does not directly use Vulcan):

• Plugin source contains no references to VulcanMessage, VulcanScriptProvider, or ExtendScript (confirmed via source grep).
• Plugin's shutdown boss (IStartupShutdownService::Shutdown()) properly joins all background worker threads (via std::thread::join()) before releasing plugin state; worker threads never call InDesign SDK functions directly.
• Plugin's IObserver-derived doc observer is properly detached (AutoDetach/base class handling) — not left dangling.
• Reproduced quitting under multiple conditions: no dialogs opened, only our custom Preferences (selectable/switcher-based) dialog opened and closed, only our modal dialogs opened and closed, and with documents that had links placed/relinked — none of these targeted tests reproduced the crash on demand, consistent with it being rare/intermittent rather than tied to one obvious user action.
• VulcanMessage5.dylib in the shipped app bundle is stripped, so we're unable to symbolicate the offsets ourselves (atos returns only the same numeric offsets).

Since we don't use Vulcan APIs directly, we suspect this is either (a) an internal Adobe subsystem (Links panel status broadcast, CC Libraries, font sync, or similar) racing with app-quit teardown, possibly triggered indirectly by plugin-driven document/link activity, or (b) a shutdown-ordering regression in VulcanMessage5.dylib itself. Given the matching offsets across sessions, this looks like a specific, fixable code path rather than a diffuse timing issue. Could someone with symbols for VulcanMessage5.dylib map these offsets to source, or advise whether this matches a known internal bug?

I attached the full crash reports (*.ips) renamed to *.txt.

Best regards

Gunter