When One CVE Isn’t Just One CVE: What Log4Shell Actually Connects To

In December 2021, a vulnerability in a Java logging library brought down incident response teams across the industry for weeks. CVE-2021-44228 — Log4Shell — is about as close to a household name as vulnerabilities get. Everyone in security knows the number. Fewer people have actually asked what it’s connected to.

A CVE record tells you what’s affected and how severe it is. That’s it. The threat actors who exploit techniques related to it, the defensive controls that might mitigate it, the broader attack pattern it belongs to — none of that lives in the CVE record itself. It lives scattered across MITRE ATT&CK, CAPEC, CWE, and multiple independent control frameworks: reference sources that were never built to talk to each other. Connecting them by hand means knowing all of them well enough to cross-reference manually, every time, for every CVE.

This is exactly the problem STONEWORK exists to solve — not by inventing new data, but by giving all of it one shared vocabulary. CTI Encyclopedia is our own graph built on top of it, and CVE-2021-44228 is as good a test case as any: what does one CVE actually connect to, once you stop treating it as an isolated record?

The traversal

The path is simple to describe: a vulnerability affects a product, exploits a weakness, that weakness maps to an attack pattern, that attack pattern maps to a real MITRE ATT&CK technique — and from there, two more hops: which real-world threat actors are known to use that technique, and which defensive controls mitigate it, drawn from both CIS Controls and NIST SP 800-53.

Run that traversal against Log4Shell in CTI Encyclopedia today, and it resolves to:

• 2 weaknesses — CWE-20 (Improper Input Validation) and CWE-400 (Uncontrolled Resource Consumption)
• 5 CAPEC attack patterns
• 7 MITRE ATT&CK techniques
• 41 distinct threat-actor groups known to use those techniques
• 45 controls mapped somewhere across that same set of techniques — 23 from CIS Controls, 22 from NIST SP 800-53

None of that comes from a Log4Shell-specific dataset. It falls out of a general-purpose traversal that would run identically for any CVE in the graph — the ontology doesn’t know or care that this particular vulnerability was famous.

The finding

Here’s where it gets useful instead of just impressive. Break that traversal down technique by technique, and the coverage isn’t even. One of the seven techniques — T1553.002, Code Signing — is used by 27 of the 41 threat-actor groups in this traversal. It’s also one of the two weaknesses’ most-connected techniques. And of the 45 controls mapped across this entire traversal — spanning both CIS Controls and NIST SP 800-53 — not one of them addresses it.

That’s a real gap, and a fair one: two independent, widely-used control frameworks, both genuinely checked, both silent on the same technique. Not “the graph is incomplete” — the graph is telling you, correctly, that a technique with substantial real-world adversary usage, reachable from one of the most exploited vulnerabilities of the last five years, has no mapped control in either framework. A flat CVE lookup would never surface that. Cross-referencing ATT&CK against multiple control frameworks by hand might, eventually, for one CVE, if someone thought to check both.

For contrast: T1574.007 (Path Interception by PATH Environment Variable), also reachable from Log4Shell’s traversal, has 24 mapped controls and zero observed threat-actor groups in the current corpus. Well-defended on paper, not yet seen in the wild — a different kind of finding, and one worth knowing is different from the first.

How it’s actually queried

The traversal above is one SPARQL query, and the interesting part isn’t the result — it’s the vocabulary. Every predicate in it is stonework: or stones:. No cve:, no cwe:, no capec:, no framework-specific predicate anywhere, and no named-graph boilerplate to route between datasets:

PREFIX stones:    <https://cyberterrain.org/ns/stones#>
PREFIX stonework: <https://cyberterrain.org/ns/stonework#>
PREFIX r:         <https://cyberterrain.org/cti-encyclopedia/resource/>

SELECT DISTINCT ?AP_CAPEC ?weakness ?affected_product ?usingEntity ?usingEntityType ?control ?AP_MITRE
WHERE {
  ?affected_product    a stonework:Product .
  r:_Vulnerability_CVE-2021-44228
                       stonework:affected ?affected_product ;
                       a stonework:Vulnerability ;
                       stonework:exploitsWeakness ?weakness .
  ?weakness            a stonework:Weakness ;
                       stonework:relatedAttackPattern ?AP_CAPEC .
  ?AP_CAPEC            a stonework:AttackPattern ;
                       stonework:relatedAttackPattern ?AP_MITRE .
  ?AP_MITRE            a stonework:AttackPattern .
  OPTIONAL { ?usingEntity stonework:uses ?AP_MITRE ; stones:stixType ?usingEntityType . }
  OPTIONAL { ?control stonework:mitigatesAttackPattern ?AP_MITRE ; a stonework:Control . }
}

That query doesn’t know or care whether a ?control came from CIS or NIST — both frameworks feed the same stonework:mitigatesAttackPattern edge, materialized the same way, queried the same way. That’s the actual pitch for STONEWORK, made concrete instead of abstract: one vocabulary, spanning independently-maintained datasets, with no glue code and no framework-specific knowledge required to ask a real question across all of them.

Try it yourself

STONES and STONEWORK are open-source and free — explore the ontology or see the interactive class diagram. CTI Encyclopedia, the graph this traversal ran against, isn’t public yet — sign up to hear when it is.