Apache Log4j 2

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Log4j sits in Tier 2, which caps at $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. Memory-safety hardening can carry a 2× or 3× multiplier. Patches must be between one and twelve months old, submissions are rate-limited to three a month, and sanctions and territory exclusions apply. CVE history 3 Last 12 months 11 Lifetime Injection 35 % Denial of service 25 % Code execution 20 % Info disclosure 15 % Latest advisories Loading the feed Overview Log4j 2 is the default logging framework of the Java enterprise world, sitting transitively inside a very large share of Java server applications, middleware and appliances: wherever server-side Java runs. Only eleven advisories have ever been recorded against it, but the severity distribution is extreme. CVE-2021-44228, Log4Shell, is the most consequential open-source vulnerability of the last decade, and it reached millions of systems across every industry at the same moment. Logging sits downstream of every piece of attacker-controlled data an application ever touches, and Log4j's lookup and plugin machinery gives that data somewhere to go. The Apache Software Foundation pays nothing for a vulnerability report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The ASF security team accepts reports on the Log4j 2 codebase through [email protected] , and the project publishes its own out-of-scope list at logging.apache.org/security.html. Everything below sits inside that boundary log4j-core in full, the implementation that carries the interesting machinery Lookups, plugin resolution and the pattern layout engine, the components that give attacker-controlled log data a way to reach code Configuration parsing across XML, JSON, YAML and properties formats, including the external-entity and interpolation surfaces those bring log4j-api and the Kotlin and Scala API bindings that applications actually call Every appender shipped in the main distribution, wherever a log record leaves the process for a file, socket or database Anything else shipped in the 2.x distribution, since the boundary is the release rather than a named list of modules Out of scope Vulnerability reports with no merged patch behind them, which earn nothing on Google's rail Apache Software Foundation infrastructure and mailing lists rather than the library Optional third-party appenders such as Cassandra, CouchDB and Kafka, which the project has historically excluded Log4j 1.x, which is end of life and receives no fixes Anything the project already lists as out of scope at logging.apache.org/security.html Patches outside the one-to-twelve-month age window the program requires Most-valued findings Injection through attacker-controlled data that reaches a lookup, plugin resolution or pattern conversion and escapes the log record. That is the Log4Shell class at 35% of the bug history, and it is the highest-consequence shape this library has Remote code execution via configuration or appender handling, where a JNDI-style outbound resolution or a deserialising sink turns a log line into execution Denial of service that a single crafted log message can cause across a whole fleet, since every server logs and nothing rate-limits its own logger Information disclosure through pattern layouts, thread context or nested lookups that put secrets or internal state into a log destination an attacker can read Configuration parser flaws such as external-entity expansion in the XML path, reachable wherever configuration is loaded from a location the application does not fully control Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. The cash on Google's rail is paid for a merged upstream patch. A vulnerability report on its own earns nothing there Keep the patch merged, without reverts, for one month before claiming, and submit it while it is between one and twelve months old Three Patch Rewards submissions per person per month is the hard cap The $15,000 Patch Rewards headline is the Tier 1 column and is not reachable for Log4j; Tier 2 caps at $5,000 Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the Apache Software Foundation security team through [email protected] , which processes reports and pays nothing for them. The ASF publishes its own advisory with researcher credit once a fixed release is out and states its own exclusions at logging.apache.org/security.html; hold the detail until then. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability