GitHub Security Lab Finds Same-Second Race Condition in JupyterLab CI Action That Enables Code Execution
A TOCTOU race in JupyterLab's update-snapshots-checkout GitHub Action let a same-second commit push bypass its authorization check and reach attacker-controlled code execution, GitHub Security Lab found.
Overview
GitHub Security Lab has disclosed a time-of-check-to-time-of-use (TOCTOU) vulnerability in a GitHub Action used by JupyterLab projects to update Playwright test snapshots, a flaw that let an attacker win a same-second race to substitute a malicious commit for the one a maintainer had authorized. Versions of the jupyterlab/maintainer-tools update-snapshots-checkout action before 1.0.0 contained the bug, tracked as CVE-2026-84973, according to GitHub Security Lab.
What We Know
The update-snapshots-checkout composite action is intended for workflows that update Playwright snapshots in response to a pull request comment, and it first checks the commenter’s author_association, rejecting anyone who is not an OWNER, COLLABORATOR, or MEMBER, according to GitHub Security Lab. That check confirms who is allowed to trigger the workflow, but the action separately has to confirm that the commit it checks out afterward is the one that person meant to approve — and that second check is where the bug lived.
To detect whether the pull request changed after the authorizing comment, the action compared the pull request head repository’s pushed_at timestamp against the comment’s created_at timestamp, both of which carry only one-second precision, and rejected the update only “if the timestamp is strictly greater than” the comment time, according to the GitHub Security Advisory published by the project itself. Because the comparison used strict greater-than rather than rejecting equality, “a push made in the same second as the comment compares equal and passes,” according to the advisory. GitHub Security Lab described the same mechanism: “a malicious push made in the same second as the authorized comment therefore compares equal and is accepted, allowing the action to check out a different, attacker-controlled commit from the one the maintainer intended to authorize,” according to GitHub Security Lab.
GitHub Security Lab said the jupyter/notebook repository’s “Update Playwright Snapshots” workflow was directly affected. That workflow triggers on issue comments containing the phrase “please update snapshots” and runs with a job token granted contents: write and pull-requests: write permissions, according to GitHub Security Lab. After the vulnerable action checks out the pull request head, the workflow loads a local composite action from that same checked-out tree; because that action definition file “comes from the pull request head, the pull request author can modify that action to run arbitrary commands,” per GitHub Security Lab. Researchers said they verified successful proof-of-concept runs of the same-second race using an optimized script, while cautioning that the race “remains unreliable because of the one-second timestamp granularity,” according to GitHub Security Lab. In the demonstrated jupyter/notebook scenario, the exposure was scoped to the token’s contents- and pull-request-write permissions rather than to arbitrary repository secrets, and the proof of concept “did not rely on unrelated repository secrets or the ability to modify a protected branch,” GitHub Security Lab noted.
The issue was found and reported by GHSL team member Jaroslav Lobačevski, credited on both advisories under the handle JarLob, according to GitHub Security Lab and the project’s advisory, which also credits krassowski as coordinator, Carreau as remediation reviewer, and Yann-P as remediation developer. GitHub Security Lab’s disclosure timeline states a private vulnerability report was created in the jupyter/notebook repository on August 27, 2026, acknowledged on August 31, then transferred to the jupyterlab/maintainer-tools repository on September 3, 2026 — the same day the action was fixed in version 1.0.0 and advisory GHSA-wwhg-p79f-vfvm was published, according to GitHub Security Lab. The project’s own release notes list v1.0.0 as published September 3 at 09:42, targeting commit 21b1cac, and list under “Bugs fixed”: “Fix same-second timing vulnerability in update-snapshot-checkout,” crediting Yann-P, Carreau, and krassowski — the same three names credited as remediation developer, remediation reviewer, and coordinator on the GitHub Security Advisory. The GitHub Security Advisory rates the flaw High severity, classifies it under CWE-367 (time-of-check time-of-use race condition) and CWE-829 (inclusion of functionality from untrusted control sphere), and recommends that any dependent repository still on an affected version “temporarily disable workflows that use maintainer-tools/update-snapshots-checkout” until it upgrades.
What We Don’t Know
Neither advisory publishes a CVSS numeric score or vector string alongside the CVE — only the qualitative “High” severity rating appears in the project’s advisory, and CVE-2026-84973 had not yet been indexed in the National Vulnerability Database as of this reporting. Neither source says how many other repositories beyond jupyter/notebook used the vulnerable action in a way that made them exploitable, nor whether the same-second race was ever attempted against a real pull request outside the researchers’ own proof-of-concept testing.