Here are some security issues, many of them involving the Obj-C runtime’s messaging, dispatch, and introspection mechanisms. Many of these have talks and news article associated with them. I do not have experience working with all of these.

Use-After-Free exploits via Forged Objects

A common attack pattern in historically published iOS exploits is to take a memory corruption bug (like a use-after-free or heap overflow) and leverage Objective-C’s runtime to achieve code execution.

If someone can control memory that a freed Objective-C object used to occupy, they can fake that object’s data to trick the runtime. For example, the Objective-C object’s first field is an isa pointer to its class. By overwriting an object’s memory, an exploit can replace the isa with a pointer to a forged “class” structure that the attacker also controls in memory**. The next time a message is sent to that object, the runtime will follow the isa to what it thinks is a class, then look up the method’s implementation (IMP) in that fake class’s method list. We can set that IMP to point wherever they want (often ROP gadgets or shellcode). Essentially, **Objective-C message dispatch becomes an entry point for arbitrary code execution if an we can subvert the isa pointer.

This technique was documented by security researchers in papers and Phrack articles (e.g., “Abusing the Objective-C Runtime” by nemo in 2009). More recently, a refinement called “Objective-C Counterfeit Object-Oriented Programming (COOP)” or “Subversive-C” was presented in 2016. Microsoft Research and others showed that by manipulating Objective-C metadata, an attacker could chain together method calls (similar to C++ COOP exploits) instead of injecting raw shellcode. They needed a memory corruption and an info leak to set this up, but it worked even with DEP and ASLR, since it was reusing existing code (just calling it in unintended ways). The Subversive-C research (USENIX 2016) demonstrated that an attacker can “carefully arrange the metadata used to dispatch messages in the Objective-C runtime” to execute a sequence of malicious operations. One recommended mitigation was to cryptographically authenticate pointers and metadata so they can’t be tampered with… an idea that foreshadowed Apple’s later pointer authentication implementation.

NSInvocation and Selector Oriented Programming (SLOP)

An exploit technique that came around 2020 is using NSInvocation objects as gadgets. An NSInvocation in Objective-C is an object that encapsulates a method call (target, selector, arguments) which can be invoked later. In a 2020 zero-click iMessage exploit, Google Project Zero researchers described how they created a fake MPMediaPickerController object in memory (after a use-after-free) such that its -dealloc method’s implementation, which calls [someField invoke], would end up calling an attacker-controlled NSInvocation. By crafting the fake object’s fields to point to an NSInvocation, they got the program to call an arbitrary selector on an arbitrary target. In their demo, they invoked the iOS private API to launch the Calculator app: a benign payload just to prove the concept. This was already “game over” (IG as far as general security is concerned) but they went further to chain calls.

They coined the term “SeLector Oriented Programming (SLOP)” for chaining multiple Objective-C method calls using a fake NSArray of NSInvocations. By making an NSArray that supposedly contains several NSInvocation objects (all attacker-crafted), and then calling [NSArray makeObjectsPerformSelector:@selector(invoke)] on it, they could execute a series of invocations in sequence. This allowed logic like “call method X on object Y, then use its return value as parameter to method Z,” effectively scripting within the exploit payload. Such techniques show how the richness of Objective-C’s messaging system can be abused by attackers to orchestrate complex chains once they gain a foothold.

Pointer Authentication (PAC) mitigations

Apple responded to these kinds of attacks with hardware-assisted pointer authentication on ARM64e processors. Starting with the A12 Bionic chip (2018) and used in iOS 14 (2020) onward, Apple began signing important pointers. Crucially, they applied PAC to the ISA pointer of Objective-C objects. The idea is that the isa value now includes a cryptographic signature (PAC) computed from the pointer value and a secret key (embedded in the CPU). When the runtime uses the isa, it can authenticate it, and any tampering (i.e., an attacker forging an isa to point to a fake class) will be detected and the app will crash instead of executing malicious code. According to Project Zero, iOS 14 changed the ARM64e ABI such that the top bits of the isa (which previously stored the inline refcount) are now used to store a pointer signature. For example, on iOS 12/13 on arm64e, the isa wasn’t PAC-protected (making faking possible); by iOS 14, Apple appears to have repurposed ~16 bits for a PAC, reducing the inline refcount size from 19 bits down to 8 bits. In assembly from Apple’s objc4 open source, you can see where they calculate the PAC for an ISA: they use instructions like PACDA X9, X8 (sign X9, the class pointer, using X8 (object address with a constant) as diversification) and then combine it into the isa value. Initially, Apple rolled this out in a debug mode in iOS 14.0-14.4 the isa was signed but not actually checked on use (so as not to break anything unexpectedly). By iOS 14.5, the checks were enforced (PAC failures causing a crash), rendering the classic isa forging techniques invalid. PAC doesn’t make exploitation impossible, but it raises the bar significantly: attackers can no longer easily make arbitrary fake objects. They’ve had to find PAC bypasses or rely on non-ObjC avenues. One advanced bypass was demonstrated by researchers via a technique named “PACMAN” (using speculative execution to brute force PAC codes), but that’s a very high-effort, specialized attack not widely seen in real malware. Overall, PAC on ISA (and also on return addresses and function pointers) is a major security win for Objective-C’s runtime integrity.

COOP and JOP Gadgets in Objective-C

Even with PAC, there are nuances. Attackers have explored non-ISA-based techniques like using existing ObjC objects or methods as Jump-Oriented Programming (JOP) gadgets. For instance, the Subversive-C/COOP attack mentioned above doesn’t necessarily require forging an ISA from thin air;s it might abuse a legitimate object and corrupt internal fields that influence control flow. One example is manipulating an Objective-C container (like an array or dictionary) so that when it is enumerated or sorted, it triggers calls that the attacker can influence. However, these are much more app-specific and not as universally applicable as the old isa-swizzling trick.

Introspection and info leaks

Objective-C’s reflective APIs (like class list enumeration, method copying, NSSelectorFromString, etc.) can sometimes help an attacker gather information once they’ve achieved code execution. For example, malware running in a compromised app might use Objective-C APIs to list all classes and see if certain security-related classes are present (to decide if it’s in a sandboxed environment or being monitored). These are not vulnerabilities per se, but rather facets of the runtime that can be abused post-exploit. An attacker could also swizzle methods via the runtime APIs to hide their tracks (for instance, swizzle network APIs to log passwords or disable certain security checks in an app). Apple’s hardened runtime for third-party apps (when enabled) can mitigate some of this by disallowing library injection or debugging, but if an attacker is already in your process, Objective-C’s openness makes it easier to manipulate behavior.

Deserialization attacks (Objective-C Message Forging)

Another class of issues involves NSCoding / NSKeyedUnarchiver. In the past, deserializing untrusted NSKeyedArchive data could be dangerous, because the archive could specify classes to be unarchived. If a vulnerable app accepts an archive from an attacker, it might be tricked into creating instances of unexpected classes. In some cases, simply unarchiving could invoke methods (if the object implements -initWithCoder: that has side effects, or if certain proxy objects like NSSymbolicSpecifier are archived). This isn’t exactly about message passing exploitation, but it’s related to how dynamic Objective-C objects can be instantiated and execute code during decoding. Apple has put warnings and mitigations (like requiring secureCoding) to address this.

Old vulns in libobjc

In earlier years, there were a few CVEs in the Objective-C runtime library (libobjc). For example, CVE-2008-1590 was a garbage collector memory corruption issue in OS X Leopard’s Obj-C 2.0 (an attacker could exploit the GC’s scanning to execute code). These are mostly historical, as that GC is gone and the runtime is more robust now. Another example: CVE-2017-7087, an InfoLeak, involved Objective-C’s NSUrl class caching; not a runtime bug, but a usage issue. By 2025, no major memory corruption CVE in the core Obj-C runtime has been publicized in recent years (thanks in part to PAC and the relative maturity of the code).

Objective-C and sandboxing

While not a vulnerability, it’s notable that Apple’s sandbox profiles for critical system services now treat the Objective-C runtime with suspicion. For instance, the BlastDoor service introduced in iOS 14 to parse iMessages runs in a sandbox that disallows many dynamic behaviors; e.g., it likely prevents loading new dynamic libraries or using JIT. Additionally, Apple wrote BlastDoor in Swift (memory-safe) to avoid the pitfalls of Objective-C parsing altogether. This trend of moving parsing of untrusted data out of Obj-C and into Swift or into stricter sandbox processes is a security-hardening measure acknowledging that Objective-C’s flexibility can be a double-edged sword.

In summary, recent exploits of Objective-C have centered on leveraging its dynamic message dispatch in clever ways once memory corruption is achieved. The introduction of pointer authentication (ISA signing) is a direct answer to those exploits, making it far harder to hijack Objective-C calls. As of 2025, an attacker targeting an Objective-C-based component must contend with PAC and other mitigations; they can no longer simply write an arbitrary “isa” to an object and expect their fake VTable to be called. Security researchers continue to probe the runtime (for example, looking at whether method caches or metadata can be corrupted), but the barrier is much higher. Objective-C’s design (dynamic dispatch, etc.) once provided a rich playground for attackers, but Apple’s platform security advancements have significantly hardened it.