From Regression Test to PoC: The Abraxas Labs Case on Chrome V8 Maglev

Abraxas Labs published an incomplete proof-of-concept for CVE-2026-126910 built partly from Google's own regression tests shipped with the November 12 patch, demonstrating how official patch tests can accelerate vulnerability reconstruction.

At 02:23 UTC on November 15, 2026, a GitHub account named Abraxas Labs uploaded the repository abraxas/chrome-v8-maglev-literal-stale, a proof-of-concept for CVE-2026-126910. The vulnerability is a type confusion in Chrome V8's Maglev JIT compiler, with a CVSS 3.1 score of 8.8 (High). The code derives in part from the regression tests that Google engineers included in the patch released on November 12, 2026, three days earlier.

Key Takeaways

An incomplete proof-of-concept for CVE-2026-126910 was published on GitHub on November 15, 2026 by Abraxas Labs.
The code is built in part from the official Google regression tests included in the November 12, 2026 patch.
The author explicitly states the PoC does not achieve code execution: "This pack is the stale load, not a shell."
The vulnerability carries CVSS 3.1 8.8 (High); the Chromium bug report 574059463 was closed to the public at the time of publication.
Chrome 157.0.8103.78 fixes the flaw; Electron applications remain vulnerable until independently updated.

The Bug Mechanics: Stale Load in Maglev

The core of the vulnerability lies in the Maglev JIT compiler, V8's intermediate tier that Chrome activates before the more aggressive TurboFan. According to analysis by Homeland411 — the sole source with direct access to the repository — the bug manifests when a value loaded from Object.prototype is not invalidated after the creation of an object or array that modifies the prototype. The result is a "stale load": the compiler continues to treat the value as one type, while the runtime has already changed its nature.

The CVE description indicates this condition allows an attacker to "execute arbitrary code inside the sandbox" by inducing a victim to visit a specially crafted HTML page. The vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Severity is High, not Critical. The patch, credited to V8 engineer Marja Hölttä with review by Darius Mercadier, arrived in Chrome 157.0.8103.78.

The same release fixed 83 vulnerabilities overall, including 5 rated Critical by CybersecurityNews. CVE-2026-126910 is not in that group; it is classified High.

From Regression Test to GitHub Repository

What distinguishes this case is the provenance of the code. Abraxas Labs explicitly stated in the README that the PoC is "built in part from a regression test that Google's own engineers shipped with the fix." Regression tests exist to ensure a fix does not introduce new bugs: they execute the vulnerable code, verify it now fails, and remain in the source tree as guardrails.

When the test includes an input that triggers the bug condition — the sequence of prototype manipulation that produces the stale load — it becomes technically useful material for reconstructing the flaw. The difference from an exploit lies in completion: the test stops at behavior verification; an exploit would proceed to memory corruption and payload execution. Abraxas Labs did not attempt this step.

The Abraxas Labs account published six other repositories for CVEs patched in the same Chrome release. The identity of the account — individual or organized group — is unknown. The original Chromium bug report, issue 574059463, was closed to the public at the time of the PoC publication.

"This pack is the stale load, not a shell" — Abraxas Labs, GitHub repository README

Confirmed PoC Limitations

The README contains a statement rare for its clarity: "no attempt had been made to turn the flaw into code execution." The PoC requires developer flags to activate the debugging command that forces Maglev tier-up. The README adds: "a real page would wait for Maglev's normal tier-up," meaning the JIT compilation that occurs naturally after repeated executions.

The value of the proof-of-concept, even incomplete, lies in demonstrating the vulnerability is reproducible. The gap to achieve code execution, if bridgeable, is technical in nature: it requires additional engineering not present in the repository. The "sandbox" attribute in the CVE description is crucial: arbitrary code execution occurs inside Chrome's renderer sandbox. For a real compromise, a second vulnerability — a sandbox escape — would be required, which is not currently public nor indexed in Metasploit or Exploit-DB as of November 14, 2026.

No evidence of in-the-wild exploitation or inclusion in the CISA KEV has emerged. EPSS estimates a 0.31-0.34% probability of exploitation over the next 30 days.

What to Do Now

Chrome 157.0.8103.78 (Linux) and 157.0.8103.78/.79 (Windows/Mac) fix the vulnerability. Users should verify they have updated the browser to the patched version.

Electron applications — including Slack, Visual Studio Code, and other programs that embed V8 — manage independent releases with their own patching cycles. According to Homeland411, the Chrome fix does not automatically propagate to these applications; users must wait for specific updates from their respective developers.

Editorial Analysis: Regression Tests as Reconstruction Material

The following section contains editorial analysis based on verified facts.

The CVE-2026-126910 case illustrates a structural tension in open-source patch publication. Regression tests, necessary for software quality, by definition contain inputs that trigger the fixed bug. When the bug report is closed to the public, as with Chromium issue 574059463, these tests become the only accessible technical source for reconstructing the vulnerability.

Abraxas Labs' pattern — seven repositories in a single session — suggests a systematic operation of collecting and reworking official tests. The source does not specify the account's intentions. Repository analysis relies exclusively on Homeland411; we have not independently verified the code.

The incomplete PoC does not constitute a working exploit, but demonstrates the bug condition is reproducible. For the technical reader, the distinction matters: between the CVE description (theoretical RCE in the sandbox), PoC capability (triggering the condition, no code execution), and realistic scenario (requires a second bug for sandbox escape).

Sources

Sources and references

Get DeafLetter