CVE-2026-49844: Log4j MapMessage emits invalid JSON for non-finite values

CVE-2026-49844 is an improper encoding/serialization flaw in Apache Log4j API's MapMessage JSON output. When a MapMessage containing non-finite floating-point values (NaN, Infinity, -Infinity) is serialized to JSON via MapMessage.asJson() or MapMessage.getFormattedMessage(new String[]{"JSON"}), the MapMessageJsonFormatter emits the bare tokens NaN, Infinity, and -Infinity instead of an RFC 8259-compliant representation. These bare tokens are not valid JSON values, so any conformant downstream JSON parser or log-ingestion system will reject or fail to process the affected log records. This is a bypass of the earlier CVE-2026-34481 fix (which addressed JsonTemplateLayout but did not cover the MapMessage.asJson() code path in log4j-api).

• Package/component affected: org.apache.logging.log4j:log4j-api — class org.apache.logging.log4j.message.MapMessageJsonFormatter, reached via MapMessage.asJson(StringBuilder) and MapMessage.getFormattedMessage(String[]) with the "JSON" format.
• Affected versions: log4j-api 2.13.1 through 2.25.4, and 2.26.0. (Also 3.0.0-alpha1+ per the Snyk advisory.)
• Fixed versions: 2.25.5 and 2.26.1.
• Risk level: Medium (CWE-116: Improper Encoding or Escaping of Output).
• Consequences: Malformed JSON in log output. Downstream JSON parsers and log-ingestion/indexing pipelines that enforce RFC 8259 will reject or fail on affected records. An attacker who can influence a floating-point value logged in a MapMessage (e.g., via JsonTemplateLayout's message resolver or any layout relying on MapMessage.asJson()) can inject non-finite values to corrupt log records or disrupt log processing. This is not a remote code execution issue.

Impact Parity

• Disclosed/claimed maximum impact: Improper encoding of non-finite floating-point values during MapMessage JSON serialization producing output that is not valid JSON (serialization/encoding flaw, other). Explicitly stated as not an RCE issue.
• Reproduced impact from this run: All 13 test cases (NaN, +Infinity, -Infinity as scalar Double, double[], scalar Float, float[], plus a combined asJson() direct call) produce bare NaN/Infinity/-Infinity tokens in the vulnerable version. A strict RFC 8259 JSON parser (Gson JsonReader with lenient=false) rejects all 13 outputs. The fixed version quotes all values as JSON strings ("NaN", "Infinity", "-Infinity") and all 13 parse successfully.
• Parity: full — the reproduced behavior exactly matches the disclosed impact (invalid JSON from non-finite values; fix quotes them).
• Not demonstrated: N/A — no code execution was claimed or expected.

Root Cause

In the vulnerable MapMessageJsonFormatter.java (log4j-api ≤ 2.25.4 / 2.26.0), the formatNumber() method handles Double and Float values by directly appending the primitive to the StringBuilder:

// VULNERABLE (rel/2.25.4)
} else if (number instanceof Double) {
    final double doubleNumber = (Double) number;
    sb.append(doubleNumber);          // <-- produces "NaN", "Infinity", "-Infinity"
} else if (number instanceof Float) {
    final float floatNumber = (float) number;
    sb.append(floatNumber);           // <-- produces "NaN", "Infinity", "-Infinity"
}

Java's StringBuilder.append(double) delegates to Double.toString(double), which returns the strings "NaN", "Infinity", and "-Infinity" for non-finite values. These are bare literals in the JSON output — they are not enclosed in quotes and are not valid JSON number syntax per RFC 8259 §6 (which only permits finite numbers). The same issue exists in formatDoubleArray() and formatFloatArray(), which also call sb.append(item) directly for array elements.

The call chain is:

MapMessage.getFormattedMessage(new String[]{"JSON"})
  → MapMessage.format(MapFormat.JSON, sb)
    → MapMessage.asJson(sb)                         [protected]
      → MapMessageJsonFormatter.format(sb, data)
        → formatNumber(sb, number) / formatDoubleArray(...) / formatFloatArray(...)

Fix (PR #4163, merged as commit 19edb23/squash c7103d5 on 2.x; feadf8eb on 2.25.x; 1352b987 on 2.26.x): The fix adds two private helper methods that check Double.isFinite() / Float.isFinite() and, for non-finite values, call formatString() to wrap the value in JSON string quotes:

// FIXED (rel/2.25.5)
private static void formatDouble(StringBuilder sb, double doubleNumber) {
    if (!Double.isFinite(doubleNumber)) {
        formatString(sb, Double.toString(doubleNumber));  // quotes: "NaN", "Infinity", etc.
    } else {
        sb.append(doubleNumber);
    }
}

All sb.append(doubleNumber) / sb.append(floatNumber) / sb.append(item) call sites in formatNumber(), formatDoubleArray(), and formatFloatArray() are replaced with calls to formatDouble() / formatFloat().

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, idempotent).
2. What the script does:
   • Installs OpenJDK 17 if not present.
   • Downloads the official Apache-published log4j-api artifacts from Maven Central: log4j-api-2.25.4.jar (vulnerable, built from tag rel/2.25.4) and log4j-api-2.25.5.jar (fixed, built from tag rel/2.25.5). Also downloads gson-2.11.0.jar for strict JSON validation.
   • Verifies via javap that the vulnerable jar lacks formatDouble()/formatFloat() helper methods and the fixed jar has them.
   • Compiles bundle/repro/NonFiniteJsonTest.java — a Java harness that creates a concrete MapMessage subclass and exercises both getFormattedMessage(new String[]{"JSON"}) (public API) and asJson(StringBuilder) (protected, via subclass) with NaN, +Infinity, -Infinity as scalar double/float and as double[]/float[] array elements (13 total cases).
   • Runs the harness against each jar. The harness detects bare (unquoted) non-finite tokens via a character-level scanner and validates each output with a strict RFC 8259 JSON parser (Gson JsonReader with setLenient(false) + skipValue()).
   • Emits a machine-readable VERDICT|... line and writes bundle/repro/runtime_manifest.json.
3. Expected evidence of reproduction:
   • Vulnerable 2.25.4: bare=13 quoted=0 parseFail=13 — all outputs contain bare NaN/Infinity/-Infinity and fail strict JSON parsing.
   • Fixed 2.25.5: bare=0 quoted=13 parseFail=0 — all outputs quote the values as JSON strings and parse successfully.

Evidence

• Log files:
  • bundle/logs/vulnerable_output.log — full harness output for vulnerable log4j-api 2.25.4
  • bundle/logs/fixed_output.log — full harness output for fixed log4j-api 2.25.5
  • bundle/logs/compile.log — javac compilation output
• Key excerpts (vulnerable 2.25.4):

  JSON output: {"number":NaN}
  >> BARE non-finite token detected (invalid JSON per RFC 8259)
  >> strict JSON parse FAILED (invalid per RFC 8259)
  
  JSON output: {"numbers":[-Infinity]}
  >> BARE non-finite token detected (invalid JSON per RFC 8259)
  >> strict JSON parse FAILED (invalid per RFC 8259)
  
  SUMMARY: bare=13, quoted=0, parseFail=13
  VERDICT|2.25.4-vulnerable|VULNERABLE|bare=13|quoted=0|parseFail=13
  

• Key excerpts (fixed 2.25.5):

  JSON output: {"number":"NaN"}
  >> non-finite value is QUOTED (valid JSON string)
  >> strict JSON parse OK (valid RFC 8259 JSON)
  
  JSON output: {"numbers":["-Infinity"]}
  >> non-finite value is QUOTED (valid JSON string)
  >> strict JSON parse OK (valid RFC 8259 JSON)
  
  SUMMARY: bare=0, quoted=13, parseFail=0
  VERDICT|2.25.5-fixed|FIXED|bare=0|quoted=13|parseFail=0
  

• javap verification:
  • Vulnerable 2.25.4 MapMessageJsonFormatter methods: no formatDouble(, no formatFloat(.
  • Fixed 2.25.5 MapMessageJsonFormatter methods: has formatDouble(StringBuilder, double) and formatFloat(StringBuilder, float).
• Environment: OpenJDK 17.0.19, Gson 2.11.0 (strict JSON validator), official Apache log4j-api jars from Maven Central (verified identical to source-built jar from rel/2.25.4 tag — same file size 351127 bytes).
• Runtime manifest: bundle/repro/runtime_manifest.json

Recommendations / Next Steps

• Upgrade guidance: Upgrade log4j-api to version 2.25.5+ (2.25.x line) or 2.26.1+ (2.26.x line). If on 3.0.0-alpha, monitor for a fix.
• Suggested fix approach: Already implemented in PR #4163 — gate non-finite Double/Float values through formatString() so they are emitted as JSON strings. This mirrors Jackson's JsonWriteFeature#WRITE_NAN_AS_STRINGS behavior.
• Testing recommendations: The fix includes regression tests (MapMessageTest.testJsonFormatterDoubleNonFiniteSupport and testJsonFormatterFloatNonFiniteSupport) that parameterize over NaN, +Infinity, -Infinity for both double and float. Any future changes to MapMessageJsonFormatter should ensure these tests continue to pass. Consider adding strict-JSON-parser validation to CI for all MapMessage JSON output.
• Downstream mitigation: Log-ingestion systems that use lenient JSON parsers (e.g., Gson default mode, some JavaScript engines) may silently accept bare NaN/Infinity, but strict parsers (RFC 8259) will reject them. Validate log JSON output with a strict parser.

Additional Notes

• Idempotency confirmation: The script was run twice consecutively; both runs produced identical results (exit code 0, bare=13 for vulnerable, bare=0 for fixed). The script skips re-downloading jars if they already exist.
• Source build verification: In addition to the Maven Central artifacts, the log4j-api module was built from source at tag rel/2.25.4 using Maven (mvn -pl log4j-api-java9,log4j-api -am install -DskipTests). The source-built jar (log4j-api-2.25.4.jar, 351127 bytes) is byte-size-identical to the Maven Central artifact, confirming the published jar matches the repository source.
• Edge cases covered: The harness tests both scalar and array forms for both Double and Float, covering all code paths in formatNumber(), formatDoubleArray(), and formatFloatArray(). The BigDecimal path is unaffected (it already uses toString() which never produces non-finite tokens).
• Scope: This is a library_api claim (claimed_surface=library_api, required_entrypoint_kind=function_call). The reproduction exercises the real MapMessage.getFormattedMessage(["JSON"]) and MapMessage.asJson() functions from the official Apache log4j-api artifacts. No service/network boundary is involved.