Four Windows 11 zero-days on one desk

Opening Position

Four Windows 11 vulnerabilities have been released by a single non-coordinated source. Two are new. yellowkey targets BitLocker, the at-rest disk encryption boundary. greenplasma is a local privilege escalation, the boundary between a logged-in user context and SYSTEM. Both are public. Both are zero-day, which by definition means no vendor patch existed at the moment of disclosure.

This is the same source that previously released bluehammer and redsun. Whether those have since been patched is not confirmed. What is confirmed is that one actor now controls the disclosure cadence, the ordering, and the technical depth of four separate Windows 11 weaknesses. The vendor is reactive in this sequence. Defenders inherit whatever exposure window the source decides to create.

The operator position is straightforward. When a single researcher dictates timing across multiple unpatched issues on a platform that runs on the majority of managed endpoints, the disclosure pipeline itself is part of the threat model. Treat this as an exposure condition, not a news item.

What Actually Failed

What is externally observable is the release event. Two new Windows 11 vulnerabilities exist in the public domain prior to confirmed vendor remediation. One is identified as a BitLocker bypass. One is identified as a local privilege escalation. The mechanism of each, the preconditions for exploitation, and the affected build range are not confirmed in the inputs available.

The vendor did not contain the disclosure. The source published. Whether private coordination was attempted, refused, or never initiated is not confirmed. Whether the release included proof-of-concept code, technical writeups, or codename only is not confirmed. What is confirmed is that the same source had already published bluehammer and redsun, and that pattern did not produce a containment outcome before yellowkey and greenplasma followed.

Two distinct trust boundaries are named in the disclosures. yellowkey is described as a BitLocker bypass. The BitLocker boundary protects data when the operating system is not adjudicating access, including offline disk scenarios and device loss. greenplasma is described as an LPE. The LPE boundary protects SYSTEM-level execution from non-privileged user context inside a running session. These boundaries protect different conditions. Both being publicly weakened at the same time is the observable failure state.

Why It Failed

The stated driver is that the researcher is disgruntled. That is the only motivation provided. Whether the researcher attempted coordinated disclosure, was refused a bounty, or had an unrelated grievance is not confirmed. Treat the motive as an input, not an explanation. The relevant fact is that the source has now released four times. The behaviour is repeated, not isolated.

The naming convention is observable. bluehammer, redsun, yellowkey, greenplasma. Colour-prefixed codenames across four releases by one source. That is a continuity signal from the author. Whether further releases are queued is not confirmed. The defender should not assume the sequence has stopped at four. The pattern supports the inference that the source is operating to a release schedule of their own choosing.

Why the vendor pipeline did not absorb this researcher before the second pair of drops is not stated. What is observable is that the same author cycled from initial disclosures (bluehammer, redsun) to a second pair (yellowkey, greenplasma) without that cycle being interrupted by a public coordination outcome. Whether the prior two were patched between releases is not confirmed. Whether the new two share components, code paths, or affected builds with the prior two is not confirmed. Until the vendor confirms otherwise, treat them as four independent exposures on the same platform from the same source.

Mechanism of Failure or Drift

The mechanism is identity-of-source as the sole input to release timing. One author selects what releases, when, and in what order. The vendor containment loop is not synchronised with that selection in the observable record. The result is a disclosure pipeline where one external party holds the schedule and the defender absorbs whatever gap that schedule produces. The failure is not located in a single product surface. It is located in the asymmetry between who controls publication and who controls remediation.

For yellowkey, the named boundary is BitLocker. BitLocker is the at-rest control. It is the boundary that holds when the operating system is not adjudicating access, including offline disk handling and post-loss device states. A claimed bypass on that boundary changes what physical possession of a powered-off device means. The exploit preconditions are not confirmed. The affected build range is not confirmed. What is confirmed is that the public claim asserts the boundary can be crossed, and that the assertion exists in the public domain prior to vendor confirmation of a fix.

For greenplasma, the named boundary is the user-to-SYSTEM transition inside a live session. LPE collapses the privilege gradient that separates a logged-in account from the trusted execution context of the operating system. The exploit chain is not confirmed. The required user state is not confirmed. What is confirmed is that the claim asserts the gradient can be bridged from inside an authenticated session. Two distinct enforcement points on the same platform, claimed weakened, published by the same author, in the same release window. The mechanism is one party, one platform, one cadence, multiple boundaries.

Expansion into Parallel Pattern

The pattern is single-actor release cadence against a single vendor surface. Four named releases. Two boundaries explicitly targeted in the new pair. One naming convention spanning the full sequence. The pattern is not the technical content of any individual vulnerability. The pattern is the continuity of release under one author with no observable interruption between drops. Treat the author as a node in the threat model with a known emission rate and an unknown stop condition.

The parallel that illustrates the same mechanism is any disclosure stream where the publisher schedule, not the vendor pipeline, sets the exposure window. The window opens at publication. It closes only when the vendor confirms remediation across affected builds. If the same author publishes again before that confirmation, the window does not close. It widens. The number of simultaneously open boundaries increases with each release the vendor has not caught up to. Whether bluehammer and redsun are still inside that open state is not confirmed. Until confirmed, plan as if they are.

The inference the pattern supports is operational. Planning must assume the sequence continues. Whether further releases are queued is not confirmed. Whether yellowkey, greenplasma, bluehammer, and redsun share components, code paths, or affected builds is not confirmed. The posture is to expect further drops from the same author on the same platform until that author stops, is removed from the release loop, or is absorbed into a coordinated channel. None of those three outcomes are confirmed. Plan for absence of all three.

Hard Closing Truth

Four Windows 11 weaknesses are public. Two are confirmed new in this release. One targets at-rest disk encryption. One targets in-session privilege boundaries. The vendor patch state across the four is not confirmed in the inputs available. The release cadence is held by one external party. The defender does not control any variable in that cadence.

What must now be true. Windows 11 estates must operate as if the BitLocker boundary and the in-session privilege boundary are both untrusted on the platform until vendor confirmation states otherwise per build. Physical device loss must be treated as data exposure for the duration of the unpatched window on yellowkey. Local authenticated user execution must be treated as eligible for SYSTEM for the duration of the unpatched window on greenplasma. The status of bluehammer and redsun must be confirmed against current builds rather than assumed remediated.

Controls that depend on an unpatched boundary are not controls during this window. State that without softening. The disclosure pipeline is part of the threat model and the author behind it is the scheduling variable. Plan for the next release in the sequence. If it does not arrive, the planning cost is low. If it does, the position is already taken. Identity is the boundary. The identity controlling this release stream is external, repeating, and uncoordinated. Treat the platform accordingly until that condition changes.