Real-World Case Studies

Conceptual models become useful when they survive contact with reality.

By the end of Module 5, you have a workable loop: propose routes, inspect constraints, validate what matters, and keep what survives. Module 6 tests whether that loop and the surrounding vocabulary still hold when you leave the tidy teaching examples and look at real public incidents.

That is why grounded cases matter. They force the model to prove that it is not only a clean internal language. It has to help you read very different incidents through one stable structural lens.

The claim is not that public cases invented the framework. The claim is that public cases make the framework legible and test whether it actually transfers.

This module is testing one thing above all: transfer.

If the framework is useful, it should help you compare cases that look different on the surface:

• traversal versus execution influence
• routing and trust-boundary movement versus timing-sensitive state abuse
• modest-looking footholds versus stronger final outcomes

The point is not to flatten those differences. The point is to show that the same analytical model can still ask the right questions:

• what capability appears?
• what role does it serve in the route?
• what outcome becomes reachable?
• what conditions decide whether the route survives?
• what has been validated versus merely proposed?

This module uses four grounded public cases already present in the site reference surface:

• Apache HTTP Server
• Apache APISIX
• Dirty COW
• Apache Struts

They matter together because they stress different parts of the model.

Apache HTTP Server shows how a route that begins as disclosure can survive toward execution under the right conditions.

Apache APISIX shows trust-boundary movement through routing logic rather than filesystem traversal or overt exploit chains.

Dirty COW shows that exploit paths can hinge on sequencing and narrow state windows, not only on what resource becomes reachable directly.

Apache Struts shows a cleaner input-to-execution route where execution influence is visible without needing a traversal-style bridge first.

Taken together, these cases make the framework work harder, which is exactly what this module needs.

Even though these cases look different, several structural patterns repeat:

• each case starts from a visible flaw but becomes more useful once translated into capability language
• each case depends on route function, not just raw weakness labels
• each case has a strongest reachable outcome that only becomes credible after conditions are examined
• each case benefits from separating candidate paths from validated ones

That repetition is the point.

The framework is not valuable because it makes every case look identical. It is valuable because it gives you a consistent way to describe what changes, what repeats, and what matters most to outcome.

The differences are just as important as the similarities.

Apache HTTP Server is strongest as a reference-control and environment-sensitive route.

Apache APISIX is strongest as a route-space and sphere-crossing case.

Dirty COW is strongest as a sequencing-manipulation and state-window case.

Apache Struts is strongest as an execution-influence case.

Those differences matter because they show the framework is not only a prettier way to rename everything as "an exploit chain." It can hold materially different route shapes without collapsing them into one generic story.

This is also where learner discipline matters. If you blur primitive family, path role, and outcome class together, the cases start to look falsely similar. The framework becomes most useful when it preserves those distinctions while still letting you compare the routes.

A useful compact comparison template is:

• weakness
• primitive family
• path role
• strongest outcome class
• key environmental qualifier
• current validation state

That template is small enough to reuse and strong enough to reveal meaningful differences.

For example:

• Apache HTTP Server: reference control, leverage gain and boundary crossing, disclosure or execution depending on CGI exposure
• Apache APISIX: reference control and authorization bypass, sphere crossing into protected route space
• Dirty COW: sequencing manipulation, state-window abuse, privilege gain under timing-sensitive conditions
• Apache Struts: execution influence, attacker input becoming execution-relevant behavior, direct remote code execution

This is the habit the module is trying to build. Do not just read cases as memorable incidents. Read them as structured routes with reusable differences.

Choose any two grounded public cases from the reference surface and compare them using one stable structure.

Use this sequence:

1. identify the weakness or visible flaw in each case
2. assign the strongest primitive family
3. identify the key path role or roles
4. identify the strongest reachable outcome class
5. note the critical environmental qualifier
6. mark what is clearly validated versus still environment-dependent
7. explain what repeats across the two cases and what changes

The goal is not to produce full case pages from scratch. The goal is to prove that you can carry one analytical model across different incidents without flattening them.

Suggested deliverable shape:

• Case A
• Case B
• Primitive comparison
• Role comparison
• Outcome comparison
• Constraint comparison
• Validation comparison
• What the framework makes clearer

If you need full case detail before comparing, start from the grounded cases index.

Double check that you can now:

• explain why grounded public cases matter to the framework
• compare multiple cases without reducing them to incident trivia
• identify what repeats structurally across different routes
• identify what changes across primitive families, roles, outcomes, and conditions
• use one stable analysis template across very different cases
• document why the framework is still useful even when the cases do not look alike

If those moves still feel weak, reread Module 5 and then work through one case in depth before trying to compare two at once.

Module 7 asks what parts of this workflow can be accelerated by AI without turning the whole story into model mystique.

That matters because once the framework survives cross-case comparison, the next question is how much of this work can be operationalized safely and usefully.

Continue to Module 7 when you are ready.

This module uses grounded public cases as transfer tests for the framework and leans on primary case sources more than on abstract prior work.

• Apache HTTP Server vulnerabilities 2.4
• Apache APISIX advisory blog
• CVE record for CVE-2016-5195
• Apache Struts S2-045 bulletin