What causes Shatter?

How Shatter actually works

shatter is a fragmentation weakness, not a single bug class with one fixed pattern. The attacker’s goal is to split a protected object, request, or data structure into pieces that are processed differently than the whole. That can let them slip past access checks, confuse parsing logic, or make the system reconstruct something invalid.

The weakness usually appears when a defender assumes inputs stay contiguous, stable, or complete throughout processing. Once that assumption breaks, the control decision and the data actually acted on can diverge. That is why Shatter often shows up in code paths that reassemble data, compare fragments, or validate content before all pieces have been combined.

Fragmentation can happen at the protocol layer, the application layer, or inside internal parsing and reassembly code. In each case, the core failure is the same: the security decision is made on one view of the resource, while execution uses another. That mismatch is what turns a parsing trick into unauthorized access, data corruption, or service disruption.

Where the security failure comes from

Shatter is usually caused by incomplete mediation. A control checks the first fragment, the first chunk, or one representation of the object, but later fragments are accepted without the same scrutiny. If the system reassembles data after the check, the final object may contain content the control never reviewed.

It also appears when integrity checks are applied too early or too narrowly. If the application validates only the wrapper, length, or metadata, an attacker can alter the internal content through fragmentation and still produce something that looks legitimate at the boundary. In practice, the issue is often a mismatch between validation order and actual processing order.

Good defensive handling means treating reassembly as a security-sensitive step. If the final object is what matters, then the final object must be the thing that is authenticated, authorised, length-checked, and integrity-checked. Anything less creates room for the attacker to exploit differences between fragments and the reconstructed result.

What defenders should verify in code and testing

Security teams should test whether fragmented inputs are handled consistently across every layer that touches them. That includes parsers, middleware, gateways, message brokers, storage handlers, and any custom logic that reassembles data before use. The important question is whether every fragment is subjected to the same trust decision as the completed object.

For a broader weakness model, the CWE Top 25 Guide is a useful way to trace Shatter-like behaviour back to common classes such as improper input validation, buffer handling problems, and missing mediation. That helps teams map a specific fragmentation flaw to a root weakness rather than treating it as an isolated oddity.

Testing should include malformed fragment ordering, duplicate pieces, truncated pieces, and fragments that individually look benign but become dangerous when combined. You also want to confirm that rejected fragments do not leave partial state behind, because partial state can become the next exploitation path.

Risk and Threat Considerations

Shatter matters because it can let an attacker separate the security decision from the thing being protected. Once those two views diverge, access control, parsing, and integrity logic can all be bypassed even when each piece of the implementation appears to work on its own.

Failure mechanism: A control validates or inspects fragments individually, then accepts a reconstructed object whose combined form was never fully checked, allowing altered content or unintended access to pass through.

Impact: The result can be unauthorized access, corrupted data, or disruption of the service path that depends on trustworthy reassembly. In higher-value systems, the same flaw can also undermine downstream auditability because the system cannot reliably prove what was actually processed.

Practitioner Guidance

What to verify: Confirm that the object used for the final security decision is the same object that later reaches execution, storage, or authorization logic. If those differ, the control is already weaker than it looks.

Common mistake: Teams often validate the envelope and assume the contents are safe. With fragmentation issues, that shortcut fails because the attacker is relying on the difference between “what was checked” and “what was assembled.”

Practitioner takeaway: Treat reassembly as part of the trust boundary, not as a harmless internal detail. If the system cannot prove that the fully reconstructed resource is what was validated, it should not be allowed to pass as trusted.

Related resources from NHI Mgmt Group

• Who is accountable when an expired certificate causes a service outage?
• Who should be accountable when an AI agent causes a security incident?
• Who is accountable when an AI agent delegation chain causes an unauthorised action?
• Who is accountable when stale cloud access causes a security or audit failure?