CVE-2021-44228: Log4Shell

Detection and triage

Use read-only checks to decide whether CVE-2021-44228 reaches an owned asset. Treat advisories and proof-of-concept material as evidence, never as executable instructions.

Reviewed detection guidance

Having log4j-core in the classpath is the necessary condition. Sufficient exposure also requires:

• A vulnerable version (per the above).
• A code path that logs untrusted input. In a typical web application, almost every code path qualifies — request headers, paths, bodies are routinely logged.

If the only logging in the application is a fixed string with no user-controlled fields and no exception traces (rare), exposure may be limited. Don't rely on that for triage; the attacker's job is to find one untrusted input that makes it to a log line.

Detection signals and verification

• Indirect execution through wrappers, job runners, hooks, converters, plugins, or template helpers.
• Double decoding, alternate encodings, argument injection, and platform-specific parsing differences.
• Sanitization that relies on incomplete deny lists.
• Signed data from a producer that can itself be influenced by untrusted users.
• Hidden deserialization in sessions, view state, message brokers, caches, plugins, and migration tools.
• Type allowlists that include broad framework or reflection-capable base classes.
• Validation that runs before decoding, double decoding, Unicode normalization, and locale-dependent parsing.
• Alternate entry points that reach the same handler, including batch import, API, queue consumers, and administrative tooling.
• Values that are validated once and then reused across several interpreters with different escaping rules.
• Asymmetric amplification, compressed or nested formats, catastrophic backtracking, retry storms, and slow clients.
• Limits enforced after allocation or expansion has already occurred.
• Global caps that allow one tenant to starve unrelated tenants or control-plane traffic.

Stop and triage

• Stop if a proposed fix still concatenates untrusted data into an execution or evaluation string.
• Switch to incident response if unexpected commands, processes, files, or outbound connections are observed.
• Do not validate by executing a functional payload on shared or production systems.
• Stop if untrusted input can still name a class, invoke a hook, or select an executable type.
• Switch to incident response if unexpected processes, class loads, filesystem changes, or network activity are observed.
• Do not use weaponized serialized objects for verification.
• Stop if the proposed fix is a deny list, a client-side check, or a single global sanitizer applied without regard to the sink.
• Stop if the correct accepted values cannot be established from documentation, schema, or the owning team.
• Do not test with payloads that would reach production systems, third parties, or other tenants.
• Stop before a test threatens shared infrastructure, downstream dependencies, or production availability.
• Switch to incident response if resource anomalies appear coordinated or availability controls are being bypassed.
• Do not classify rate limiting alone as a permanent fix for unbounded algorithmic work.

Triage output: Return a reviewer-ready minimal patch with exposure evidence, authoritative fixed-version evidence, regression tests, deployed-artifact verification, rollback notes, and source links; otherwise return TRIAGE.md with the blocking decision and owner.