Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential Use-After-Free exists in V8 Inspector’s console message handling when DevTools is open. An attacker could bypass the hasConsoleMessageStorage liveness guard by using a debugger; statement in a custom object getter to trigger a nested message loop. During this pause, an attacker-initiated navigation can destroy the original V8ConsoleMessageStorage and recreate a new one, leading to UAF read/write operations when the getter returns.

Affected files:

• v8/src/inspector/v8-console-message.cc
• v8/src/inspector/v8-runtime-agent-impl.cc
• v8/src/inspector/v8-inspector-impl.cc

Estimated timestamp from git blame: 2026-02-24

Summary

A potential Use-After-Free (UAF) vulnerability has been identified in the V8 Inspector component. The issue stems from the hasConsoleMessageStorage guard, which is used to verify the liveness of a V8ConsoleMessageStorage instance after a JavaScript callout. This guard only checks for the presence of a context group ID in a map, failing to verify the identity of the specific storage object itself. If the storage is destroyed and then re-created for the same context group ID during a callout, the guard will return a false positive, leading to subsequent operations on a freed object.

Technical Details

There are two identified vectors for this vulnerability: a UAF write in V8ConsoleMessageStorage::addMessage and a UAF read in V8RuntimeAgentImpl::enable.

Vector 1: UAF Write in V8ConsoleMessageStorage::addMessage

1. V8ConsoleMessageStorage::addMessage logs a console message and calls m_inspector->forEachSession. This triggers V8RuntimeAgentImpl::reportMessage.
2. reportMessage calls ValueMirror::create (via wrapArguments or wrapException) to wrap the object. For an Error object, ValueMirror::create attempts to access the properties name, message, and stack via getErrorProperty.
3. While getErrorProperty avoids direct user-defined getters, it falls back to object->Get(...) if the property is not an ‘own’ property. This allows an attacker to execute custom JavaScript synchronously by placing a Proxy with a get trap on the object’s prototype chain.
4. The attacker places a debugger; statement inside this get trap. This forces a synchronous pause, spinning up a nested message loop in V8.
5. During this nested loop, the renderer continues to process high-priority IPCs. The attacker arranges for a navigation or frame detachment IPC to arrive at this moment. This triggers V8InspectorImpl::resetContextGroup, which erases the V8ConsoleMessageStorage object (this) from m_consoleStorageMap, freeing it.
6. Still within the nested loop (e.g., via DevTools evaluation), the attacker logs a new message to the identical context group. This invokes V8InspectorImpl::ensureConsoleMessageStorage, which allocates a new storage object and inserts it into m_consoleStorageMap using the same contextGroupId.
7. The attacker resumes execution, unwinding the stack back to V8ConsoleMessageStorage::addMessage.
8. addMessage executes its liveness guard: if (!inspector->hasConsoleMessageStorage(contextGroupId)) return;. Because a new object was created in Step 6, the ID exists in the map, and the guard incorrectly returns true.
9. addMessage proceeds to call m_messages.push_back(...) on the freed this pointer, resulting in a UAF write.

Vector 2: UAF Read in V8RuntimeAgentImpl::enable

1. V8RuntimeAgentImpl::enable caches a pointer to the storage and a reference to its message deque: const auto& messages = storage->messages();.
2. It iterates over this deque, calling reportMessage.
3. If reportMessage triggers the same debugger; nested loop sequence described above, the original storage and its deque are freed, and a new storage is created.
4. The hasConsoleMessageStorage guard at the end of reportMessage falsely returns true.
5. The loop continues to the next iteration, accessing messages.size() and messages[i] using the dangling reference, leading to a UAF read.

Impact

This vulnerability could lead to memory corruption within the renderer process. An attacker could leverage the UAF write to corrupt the heap, potentially achieving Remote Code Execution (RCE) within the renderer sandbox. Exploitation requires DevTools to be open and the user to visit a malicious site.

(Note: These are suggested steps based on static analysis; our tooling agent cannot execute code to verify the exploit.)

Suggested Fix

To prevent this vulnerability, the liveness checks must verify the identity of the storage object, not just the existence of the group ID.

1. For V8ConsoleMessageStorage::addMessage: Instead of relying on hasConsoleMessageStorage(contextGroupId), capture a base::WeakPtr (or equivalent weak reference mechanism available in V8) to this before the forEachSession call. Check if the weak pointer is still valid after the call returns.
2. For V8RuntimeAgentImpl::enable: Do not cache raw references or pointers across calls that can execute JavaScript. Instead, maintain an index and fetch the storage and message at that index dynamically on each iteration, verifying the storage object hasn’t been unexpectedly swapped out or deleted.

Evaluated with Chrome root at commit: eca8648a4e1cdfdda68c495a6003059fed641955

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.