How CodeQL and LGTM Uncovered a Log4j2 0‑Day: Inside the CWE‑074 Rule

Introduction

The author examined the official CodeQL rules and discovered a 2020 rule that appears to have been generated by CodeQL itself, showing that modern vulnerability discovery no longer relies on manually reading every line of code.

LGTM and CodeQL

LGTM (https://lgtm.com/) offers an online CodeQL scanner for GitHub projects. By opening a specific Log4j2 project page, the author observed a scan result (commit 50979af) that identified a 0‑day vulnerability using the rule located in CodeQL’s security directory, identified as CWE‑074.

CWE‑074 Rule Details

The CWE‑074 rule, previously experimental (CWE‑117) and now official, defines two data‑flow paths. The first source is RemoteFlowSource, which is well‑maintained by security engineers. Simple type filters remove primitive Java types, and the sink lists many potential injection points similar to JDBC execution in SQL injection.

The rule’s internal representation resembles bytecode or an intermediate representation generated by CodeQL, with numerous lookups added to the sink. The second data‑flow path is omitted as it is not relevant to the current discussion.

Conclusion

The open‑source nature of both the scanning tool and the rule makes such vulnerabilities easy to discover when one knows how to compile a native JDK into a CodeQL database, write QL queries, and handle data‑flow breaks.

Step‑by‑Step Guide

Paste the Git URL of the open‑source project into the LGTM website.

Wait for the scan to complete.

Review the reported vulnerabilities.

Use the discovered 0‑day responsibly: report it, or submit it to platforms like HackerOne.

In practice, mastering CodeQL involves deeper knowledge of compilation, custom framework modeling, and QL query authoring.

Off‑Topic Discussion

Fortify can perform similar scans, but its rule authoring is less user‑friendly. Learning CodeQL is best done through official documentation and community resources.