{"vulnerability": "cve-2025-68161", "sightings": [{"uuid": "e61aaeee-7f4e-497a-8a35-9e76e50d558d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://mstdn.social/users/jschauma/statuses/115742216551427386", "content": "", "creation_timestamp": "2025-12-18T19:27:49.418640Z"}, {"uuid": "50ef2fde-a7ac-4ac4-86ce-af973652e38f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/jschauma.mstdn.social.ap.brid.gy/post/3mabvuhpdnpf2", "content": "", "creation_timestamp": "2025-12-18T19:28:16.102587Z"}, {"uuid": "92c5d026-3020-4c8d-8253-cc107f05ff8f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/infosec.skyfleet.blue/post/3mabwvsw2vx2z", "content": "", "creation_timestamp": "2025-12-18T19:46:31.251987Z"}, {"uuid": "7f578472-1583-40df-873b-0c8caf2b6fa9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://seclists.org/oss-sec/2025/q4/285", "content": "", "creation_timestamp": "2025-12-18T18:15:51.000000Z"}, {"uuid": "0689298f-af44-469c-9e0c-12903e06450e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://infosec.exchange/users/cR0w/statuses/115742619242747428", "content": "", "creation_timestamp": "2025-12-18T21:10:13.229876Z"}, {"uuid": "7d98bf36-8ca4-4514-9564-ea3771836bdd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/omo.bsky.social/post/3macci35a6c2c", "content": "", "creation_timestamp": "2025-12-18T23:13:38.787714Z"}, {"uuid": "a45efe7f-5868-42e0-936b-d692a3fd229b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://gist.github.com/Darkcrai86/988f738b8355ed1ed79e94a301ce97cf", "content": "", "creation_timestamp": "2025-12-19T08:09:42.000000Z"}, {"uuid": "0900abfa-adc9-40a2-a4a3-8fdcfff37228", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://infosec.exchange/users/AAKL/statuses/116483286321859891", "content": "", "creation_timestamp": "2026-04-28T16:34:48.360707Z"}, {"uuid": "1a7682ff-135b-475c-95f3-56d7301b22ed", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://gist.github.com/aajisaka/4c2f7b9a8360b65fc9612b0a8657c0d0", "content": "", "creation_timestamp": "2026-02-26T04:17:45.000000Z"}, {"uuid": "cbae79b2-4ac4-4374-bcd4-a6411c719ff8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://gist.github.com/Darkcrai86/48e2872e2c3957d1fff1420e9521fe01", "content": "", "creation_timestamp": "2025-12-19T13:29:01.000000Z"}, {"uuid": "438e9802-0ade-4349-985d-9f3d0b68ce29", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://www.acn.gov.it/portale/w/vulnerabilita-in-apache-log4j", "content": "", "creation_timestamp": "2025-12-19T11:53:52.000000Z"}, {"uuid": "a70acd1f-aca7-4433-9846-ad27a58c259a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/gcpweekly.bsky.social/post/3mhegf2lhvs2d", "content": "", "creation_timestamp": "2026-03-18T21:25:08.938836Z"}, {"uuid": "412fa0c4-0634-4dc7-87f5-a2b3a4075678", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/gcpweekly.bsky.social/post/3mhegf6u5mx2q", "content": "", "creation_timestamp": "2026-03-18T21:25:12.800339Z"}, {"uuid": "5b0881de-65e7-4667-94c6-01fd1ed7d0a6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/ferramentaslinux.bsky.social/post/3md3kp34s5c2d", "content": "", "creation_timestamp": "2026-01-23T11:07:46.889965Z"}, {"uuid": "e88d90a7-48a3-419d-961c-047739f0959e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/gcpweekly.bsky.social/post/3mhkt4nxiap2k", "content": "", "creation_timestamp": "2026-03-21T10:29:04.268113Z"}, {"uuid": "0b0118f3-b4ad-4cc1-ab8e-e78d406a77c8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/bbcbc485-b88d-4831-b8e9-6e37e7bd9875", "content": "", "creation_timestamp": "2026-01-21T21:18:16.771453Z"}, {"uuid": "02babfa1-a804-4ae9-ba84-e8e43415f0d0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/euvd-bot.bsky.social/post/3mj5seadsce2p", "content": "", "creation_timestamp": "2026-04-10T17:01:10.921980Z"}, {"uuid": "b8beea29-f0bf-4042-b81b-d1ae86af3bb1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3mk3jwqt6xo2w", "content": "", "creation_timestamp": "2026-04-22T12:50:20.776151Z"}, {"uuid": "8ce19fd0-f96c-48b3-979c-b1adf9a7e605", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/thedailytechfeed.com/post/3magoenmpfr2y", "content": "", "creation_timestamp": "2025-12-20T16:57:09.811043Z"}, {"uuid": "1bf44346-dbfc-44df-80ab-6102153457a5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/gcpweekly.bsky.social/post/3mhkt5kokg225", "content": "", "creation_timestamp": "2026-03-21T10:29:33.973049Z"}, {"uuid": "3f6fcc59-d5e1-42a9-b3f7-5c9f9bc021f5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3mlnybnopq22h", "content": "\ud83d\udd17 CVE : CVE-2025-68161, CVE-2026-0502, CVE-2026-27682, CVE-2026-34258, CVE-2026-34259, CVE-2026-34260, CVE-2026-34263, CVE-2026-40129, CVE-2026-40131, CVE-2026-40132, CVE-2026-40133, CVE-2026-40134, CVE-2026-40135, CVE-2026-40136, CVE-2026-40137", "creation_timestamp": "2026-05-12T14:20:27.563214Z"}, {"uuid": "299ac46c-48e3-41b2-9b2a-39c066a7c3f7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://bsky.app/profile/o2cloud.bsky.social/post/3mlnykldwtg2c", "content": "\ud83d\udd17 CVE : CVE-2025-68161, CVE-2026-0502, CVE-2026-27682, CVE-2026-34258, CVE-2026-34259, CVE-2026-34260, CVE-2026-34263, CVE-2026-40129, CVE-2026-40131, CVE-2026-40132, CVE-2026-40133, CVE-2026-40134, CVE-2026-40135, CVE-2026-40136, CVE-2026-40137", "creation_timestamp": "2026-05-12T14:25:05.310978Z"}, {"uuid": "a63bd401-70f0-450f-82a6-31f1343f4b6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-68161", "type": "seen", "source": "https://gist.github.com/ppkarwasz/53b0a3c07a9e44aa945726138f67d11c", "content": "# Apache Log4j 2 \u2014 Threat Model\n\n## \u00a74.1 Header\n\n- **Project:** Apache Log4j 2 (`apache/logging-log4j2`)\n- **Version pinned:** 2.26.0 (latest GA at time of writing; HEAD = 2.27.0-SNAPSHOT)\n- **Java baseline:** Java 17\n- **Date:** 2026-05-13\n- **Author:** drafted by the `produce-threat-model` skill in interview-first mode with a maintainer in the loop\n- **Status:** draft v1, under maintainer review\n- **Reporting cross-reference:** vulnerabilities go to `security@logging.apache.org` per the [project security page](https://logging.apache.org/security.html); findings closed by this document cite the section here, e.g. \"see Log4j 2 threat model \u00a74.9\".\n\n### Provenance legend\n\n| Tag | Meaning |\n| --- | --- |\n| *(documented)* | Stated in a project artifact: the website's `_threat-model-common.adoc` and `security/faq.html`, the 2.x-specific `security.html`, the `manual/systemproperties.html` manual page, the repo's `SECURITY.adoc`, `AGENTS.md`, or `FUZZING.adoc`. |\n| *(maintainer)* | Stated by a Log4j maintainer in response to this drafting process. Date appended. |\n| *(inferred)* | Reasoned from code structure, absence of a feature, or domain knowledge \u2014 not yet confirmed. Every *(inferred)* tag has a matching open question in \u00a74.14. |\n\n### Draft confidence\n\n| Documented | Maintainer | Inferred |\n| ---------- | ---------- | -------- |\n| 20         | 35         | 17       |\n\n(Counts are literal tag occurrences, including a few in the legend and \u00a74.14 prose. 15 substantive *(inferred)* claims map 1:1 to \u00a74.14 questions; 2 of the occurrences are meta references. Goal: drive *(inferred)* to zero in the next review round.)\n\n### Relationship to the website threat model\n\nApache Logging Services publishes a **cross-project** threat model at\n[`_threat-model-common.adoc`](https://raw.githubusercontent.com/apache/logging-site/refs/heads/main-site-pro/src/site/antora/modules/ROOT/pages/_threat-model-common.adoc),\nshared across Log4cxx, Log4j, and Log4net. This document is the\n**Log4j-2.x-specific** model. It is a **strict superset** of the common doc:\nevery claim in the common doc maps to a section here (see \u00a74.16 back-map),\nnothing is silently dropped or weakened, and where this document adds\nclaims (per-parameter trust table, component-family carving, triage\ndispositions, etc.) they extend the common doc rather than contradict it.\n*(maintainer, 2026-05-13)*\n\n### Purpose, in one paragraph\n\nLog4j 2 is a Java logging API and backend. An application instantiates one\nor more `Logger`s, calls `log.info(...)` / `log.error(...)` / etc., and a\nconfigured set of *appenders* writes formatted records somewhere (a file, a\nsocket, a database, a mail server, a JMS topic). The library is loaded\n**in-process** with the application and configured by **trusted** files,\nsystem properties, and environment variables. It is not a service: it does\nnot listen on any socket, does not start before the JVM, and offers no\nnetwork surface of its own. The threat model below describes what Log4j\ntakes responsibility for in that setting and what it explicitly leaves to\nthe embedding application and operator.\n\n---\n\n## \u00a74.2 Scope and intended use\n\n### Intended use\n\n- **In-process Java logging library**, loaded as Maven/Gradle artifacts\n  under `org.apache.logging.log4j:log4j-*`. *(documented)*\n- Callers are the **application code** (developers) and, via configuration,\n  the **operator** (administrators / deployers). Both are *Trusted Users*\n  in the common threat model. *(documented)*\n- Deployment shapes: standalone JVMs, application servers, Spring Boot\n  apps, containers. The library is the same artifact in all of them; the\n  threat profile is invariant. *(inferred)* \u2192 \u00a74.14 Q1\n\n### Component-family table\n\n| Family | Modules | Touches outside the process? | In model? |\n| ------ | ------- | ---------------------------- | --------- |\n| **A \u2014 Core** | `log4j-api`, `log4j-core`, `log4j-api-java9`, `log4j-core-java9` | No (only via configured appenders) | **Yes** |\n| **B \u2014 Bridges & adapters** | `log4j-1.2-api`, `log4j-jcl`, `log4j-jul`, `log4j-jpl`, `log4j-slf4j-impl`, `log4j-slf4j2-impl`, `log4j-to-jul`, `log4j-to-slf4j`, `log4j-iostreams`, `log4j-jpa`, `log4j-taglib`, `log4j-web`, `log4j-jakarta-web`, `log4j-appserver`, `log4j-spring-boot`, `log4j-spring-cloud-config-client` | No new surface; adapts other APIs to Log4j or vice versa | **Yes**, same trust profile as A |\n| **C \u2014 Optional appenders / integrations** | `log4j-jakarta-jms`, `log4j-jakarta-smtp`, `log4j-jdbc-dbcp2`, `log4j-mongodb`, `log4j-mongodb4`, `log4j-cassandra`, `log4j-couchdb`, `log4j-docker`, `log4j-layout-template-json` | Yes \u2014 outbound to a **trusted operator-supplied endpoint** | **Yes**, with \u00a74.10 obligation that the endpoint is trusted |\n| **D \u2014 Test / build / perf harness** | `log4j-*-fuzz-test`, `log4j-*-test`, `log4j-*-its`, `log4j-perf-test`, `log4j-osgi-test`, `log4j-parent`, `src/site` | n/a | **No** \u2014 not shipped to users (`-test` / `-fuzz-test` / `-its` / `-perf-test`) or build infrastructure |\n\n*(maintainer, 2026-05-13)* for the carving.\n\n---\n\n## \u00a74.3 Out of scope (explicit non-goals)\n\n- **Family D modules** as above: test, fuzz, integration-test, performance,\n  and build modules are not part of the shipped surface. A vulnerability\n  in `log4j-perf-test` is `OUT-OF-MODEL: unsupported-component`.\n  *(maintainer, 2026-05-13)*\n- **Log4j 1.x.** Lives in a separate repository (`apache/logging-log4j`),\n  is EOL, and is not covered here. The `log4j-1.2-api` *bridge* in Log4j 2\n  IS covered (Family B). *(maintainer, 2026-05-13)*\n- **3.x development branch**, until it has a GA release. *(maintainer, 2026-05-13)*\n- **Untrusted configuration.** Configuration files, system properties,\n  and environment variables are trusted resources of the deployer; an\n  attack that requires writing log4j configuration is out of scope. The\n  reclassification of CVE-2018-1285 (Log4net XXE via attacker-controlled\n  config) is the worked example. *(documented)*\n- **Untrusted plugin classpath.** Anyone who can add a class to the\n  classpath has already won; plugin-loading paths are not a security\n  boundary. *(inferred)* \u2192 \u00a74.14 Q2\n- **Side-channel attackers** (timing observers, memory observers,\n  co-tenant observers). Log4j does not provide constant-time anything.\n  *(inferred \u2014 companion to the explicit \"no constant-time guarantees\"\n  in \u00a74.9)* \u2192 \u00a74.14 Q3\n- **Log masking.** Sensitive-data redaction is the application's job\n  before it reaches a `log.*()` call. *(documented)*\n- **Log file access control.** It is the deployer's job to keep written\n  log files away from unauthorized readers. *(documented)*\n- **Log delivery reliability.** The project explicitly does not guarantee\n  delivery of every event. (See \u00a74.9 P6.) *(documented + maintainer,\n  2026-05-13)*\n\n---\n\n## \u00a74.4 Trust boundaries and data flow\n\n### Where the boundary sits\n\nThe **API surface** is the trust boundary on the *input* side. Anything\nthat arrives at a public method of `org.apache.logging.log4j.Logger`,\n`ThreadContext`, etc., is the data we model. Below that, internal\ncollaboration between Log4j classes is *not* a security boundary \u2014\nin-process code is fully trusted.\n\nThe **appender's outbound destination** is the trust boundary on the\n*output* side, but in the opposite direction: Log4j trusts its\noperator-supplied destination (mail server, JMS broker, JDBC database,\netc.). The destination is not an adversary of Log4j; it is an extension\nof the operator. *(maintainer, 2026-05-13)*\n\n### Data flow\n\n```\n[ application code ]\n       |  (1) log.*(message, params, throwable)\n       v\n[ Logger ]----(2) reads ThreadContext (Map + Stack)\n       |\n       v\n[ LogEvent assembly ]\n       |\n       v\n[ Filters ] -- drop or pass\n       |\n       v\n[ Layouts ]  (Pattern | XML | JSON | RFC 5424 | template-json)\n       |\n       v\n[ Appenders ] --> [ operator-trusted destination ]\n                  (file | socket | DB | JMS | SMTP | console | ...)\n```\n\n(1) is the **adversary-controllable** entry path (for message text,\nparameter `toString()`, ThreadContext **values**, ThreadContext stack\nframes, Throwable contents).\n\n(2) is partly adversary-controllable (TC values, stack frames) and\npartly trusted (TC keys, per the wave-1 maintainer decision).\n\n(3) (downstream of the appender) is trusted by virtue of being\noperator-configured.\n\n### Reachability preconditions per component\n\n- **Family A finding** is in-model only if reachable from input that the\n  adversary model marks attacker-controllable (per \u00a74.6) on a default\n  2.x build (per \u00a74.5a). *(inferred)* \u2192 \u00a74.14 Q4\n- **Family B finding** inherits Family A's preconditions.\n- **Family C finding** is in-model only if reachable from in-scope\n  input AND does not require manipulating the trusted destination.\n  A finding that requires a malicious JMS broker to send back a crafted\n  message is out of model. *(maintainer, 2026-05-13)*\n\n---\n\n## \u00a74.5 Assumptions about the environment\n\n- **JVM:** Java 17 or later for the 2.26 line. *(documented \u2014 `.java-version`, `pom.xml`)*\n- **Memory model:** standard JMM; allocator behavior per the platform.\n  *(inferred)* \u2192 \u00a74.14 Q5\n- **Concurrency:** the caller can invoke `Logger` methods from any\n  thread; the library handles synchronization internally. (See \u00a74.8 P4.)\n- **Time / clock:** Log4j reads wall-clock time for timestamps;\n  monotonicity is not required. *(inferred)* \u2192 \u00a74.14 Q6\n- **Filesystem & network:** see negative inventory below.\n\n### Negative inventory \u2014 what Log4j 2 does NOT do to its host\n\nIn a default-configured Log4j 2.x (Family A only loaded, no Family C\nmodules referenced from config): *(maintainer, 2026-05-13)*\n\n- Does **not** open any inbound listener (no TCP/UDP server socket, no\n  HTTP server, no JMS consumer).\n- Does **not** spawn child processes.\n- Does **not** install signal handlers (uses the JVM shutdown hook only,\n  via `ShutdownCallbackRegistry`).\n- Does **not** modify the `SecurityManager` or `Policy`.\n- Does **not** touch the system class loader or boot classpath.\n- Reads environment variables only during configuration resolution and\n  through the `env:` lookup (which is config-resolved, not\n  message-resolved, by default since 2.16).\n- Reads filesystem only at: the configured config file, its\n  `monitorInterval` watcher, and any appender's destination file.\n- Does **not** mutate process-wide state (locale, default `TimeZone`,\n  default charset, FPU state).\n- Does **not** use `java.lang.instrument` or attach an agent.\n- Does **not** use `Unsafe` / `sun.misc` / JNI of its own.\n\nFamily C modules **extend** this set: `log4j-jakarta-jms` opens an\noutbound JMS connection, `log4j-jakarta-smtp` opens an outbound SMTP\nsession, etc. \u2014 all **outbound**. No optional module opens an inbound\nlistener. *(maintainer, 2026-05-13)*\n\n---\n\n## \u00a74.5a Build-time and configuration variants\n\nLog4j 2 has **no compile-time** flags that change the security envelope\n(no `#ifdef`-style switches). The runtime knobs that do are: *(documented\n\u2014 `manual/systemproperties.html`)*\n\n| Property                            | Default | Env. variable                         | Posture                                                                                                       | Maintainer stance |\n| ----------------------------------- | ------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------- |\n| `log4j2.enableJndiLookup`           | `false` | `LOG4J_ENABLE_JNDI_LOOKUP`            | `${jndi:\u2026}` lookup will not resolve unless flipped; even then only the `java:` protocol is permitted.         | Supported off. |\n| `log4j2.enableJndiJms`              | `false` | `LOG4J_ENABLE_JNDI_JMS`               | JMS Appender will not resolve JNDI without it.                                                                | Supported off. |\n| `log4j2.enableJndiJdbc`             | `false` | `LOG4J_ENABLE_JNDI_JDBC`              | JDBC Appender will not resolve a `DataSource` via JNDI without it.                                            | Supported off. |\n| `log4j2.enableJndiContextSelector`  | `false` | `LOG4J_ENABLE_JNDI_CONTEXT_SELECTOR`  | `JndiContextSelector` only enabled when flipped.                                                              | Supported off. |\n| `log4j2.disableJmx`                 | `true` *(since 2.24.0)* | `LOG4J_DISABLE_JMX`     | JMX MBean registration off by default.                                                                        | Supported off. |\n| `log4j2.scriptEnableLanguages`      | *empty* | `LOG4J_SCRIPT_ENABLE_LANGUAGES`       | Scripting is disabled until the operator lists script engines.                                                | Supported off. |\n| `log4j2.sslVerifyHostName`          | `false` | (n/a)                                 | TLS hostname verification **off** by default; mutual TLS not required. *(documented \u2014 manual)* *(maintainer, 2026-05-13)* | **Supported posture, with hardening planned.** A report against this default is `VALID-HARDENING` per \u00a74.13. |\n\n**Insecure-default analysis (\u00a76.8 Q23a).** All JNDI / JMX / scripting\nknobs ship in their safer setting and the operator must explicitly opt\nin. The one remaining insecure default is `log4j2.sslVerifyHostName=false`\nand the absence of mutual-TLS requirements on the Socket appender;\nmaintainers consider this the **currently-supported production posture**\nbut plan to harden in a future version (cf. CVE-2026-34477 and\nCVE-2025-68161). Triage: see \u00a74.13. *(maintainer, 2026-05-13)*\n\n**Properties NOT in this table** that producers commonly mention but\nshould not appear here:\n\n- `log4j2.formatMsgNoLookups` \u2014 irrelevant; lookups in message text were\n  removed in 2.16.\n- `log4j2.enableJndi` \u2014 no such master switch exists.\n- `log4j2.allowedLdapClasses` / `allowedJndiProtocols` /\n  `allowedLdapHosts` \u2014 do not exist; the JNDI restriction to the `java:`\n  protocol is hard-coded.\n- `log4j2.jmxNotifyAsync` \u2014 perf, not security.\n\n---\n\n## \u00a74.6 Assumptions about inputs\n\n### What Log4j accepts\n\nA `Logger` method call carries up to four kinds of data: format-string\n*(trusted)*, parameter values *(untrusted)*, optional `Throwable`\n*(untrusted)*, and implicit context (ThreadContext Map + Stack;\nMarker; logger name). The per-parameter trust table below names each.\n\n### Per-parameter trust table\n\n| Entry point | Parameter | Adversary-controllable? | Caller / operator must enforce |\n| ----------- | --------- | ----------------------- | ------------------------------ |\n| `Logger.info(String fmt, Object... params)` | `fmt` | **No** \u2014 should be a compile-time constant | Never source format strings from input *(documented)* |\n| same | `params[i]` (and their `toString()`) | **Yes** | Mask sensitive data before logging *(documented)* |\n| `Logger.info(String fmt, Throwable t)` | `t` (message + stack trace) | **Yes** | nothing \u2014 Log4j must safely render *(inferred)* \u2192 \u00a74.14 Q7 |\n| `Logger.info(Marker m, ...)` | `m.getName()` | **No** by recommendation; project will not fail if app derives a marker name from user input, but cardinality is the app's problem *(maintainer, 2026-05-13)* | Don't generate unbounded unique markers from user input |\n| `LogManager.getLogger(name)` | `name` | **No** by recommendation; same cardinality caveat as Marker *(maintainer, 2026-05-13)* | Don't generate unbounded unique loggers from user input |\n| `ThreadContext.put(k, v)` | `k` (key) | **No** \u2014 trusted per recent decision *(maintainer, 2026-05-13)*, superseding the common doc | \u2014 |\n| same | `v` (value) | **Yes** *(documented)* | If your layout interpolates TC values, do not put attacker-controlled data into them, especially with `enableJndiLookup=true` |\n| `ThreadContext.push(message)` | stack-frame contents | **Yes** *(documented)* | \u2014 |\n| **RFC 5424 layout fields** | `MSGID`, `SD-ID`, `SD-PARAM-NAME`, `APP-NAME`, `HOSTNAME`, `PROCID` | **No** \u2014 trusted identifiers per maintainer decision *(maintainer, 2026-05-13)*, superseding the common doc | \u2014 |\n| same | `MSG`, `PARAM-VALUE` | **Yes** *(documented)* | \u2014 |\n\n### Size, shape, rate\n\n- No documented hard cap on message length or parameter count; per-call\n  resource use is expected to be linear (\u00a74.8 P3). *(inferred)* \u2192\n  \u00a74.14 Q8\n- Streaming: a single log call is processed in one shot; there is no\n  partial / chunked event API. *(inferred)* \u2192 \u00a74.14 Q9\n- Rate: backpressure is the operator's concern (async appender, log\n  level, rate limit). *(documented)*\n\n---\n\n## \u00a74.7 Adversary model\n\n### In-scope adversary\n\nAnyone whose data flows into a `log.*()` call via the **untrusted**\ncolumns of the \u00a74.6 table. Capabilities the in-scope adversary has:\n\n- Submit arbitrary byte sequences (any encoding, including malformed\n  UTF-8) and control characters (CR, LF, NUL, etc.) via message text,\n  parameter `toString()`, TC values, TC stack frames, RFC 5424\n  `MSG`/`PARAM-VALUE`, or a `Throwable`'s message and stack.\n- Use lookup syntax `${...}` (which since 2.16 does **not** expand in\n  message text by default, but the operator may still expose it via TC\n  value + a layout that interpolates).\n- Submit very long strings (within whatever upstream limits the\n  application enforces).\n- Trigger recursive references in their input.\n\n### Out-of-scope adversaries\n\n- Anyone who can write `log4j2.{xml,properties,yaml,json}` or any other\n  configuration file.\n- Anyone who can set environment variables or system properties on the\n  JVM.\n- Anyone running code in the same JVM (in-process callers, malicious\n  plugins, JVM agents).\n- Anyone who can add a plugin / class to the classpath.\n- Anyone who controls the JVM bytecode itself.\n- Side-channel observers (timing, memory).\n- A malicious **destination** for any appender (a malicious mail\n  server, JMS broker, DB engine, etc.). These are operator-trusted\n  endpoints. A \"the JMS broker sent me a hostile reply\" report is\n  out of model. *(maintainer, 2026-05-13)*\n\nThis adversary model **supersedes** the website common doc on three\nspecific points: (a) ThreadContext Map **keys** are trusted (the common\ndoc says keys+values are untrusted; the recent maintainer decision\nelevates keys), (b) RFC 5424 MSGID and SD-ID are trusted, (c) RFC 5424\nSD-PARAM-NAME, APP-NAME, HOSTNAME, PROCID are trusted. All other points\nremain as the common doc has them. *(maintainer, 2026-05-13)*\n\n---\n\n## \u00a74.8 Security properties the project provides\n\n| ID | Property | Conditions | Violation symptom | Severity tier | Provenance |\n| -- | -------- | ---------- | ----------------- | ------------- | ---------- |\n| **P1** | No RCE from in-scope input. No code outside Log4j and its declared dependencies executes as a consequence of in-scope input alone. | Default 2.x build (per \u00a74.5a). | Arbitrary code executes from log message, parameter, or ThreadContext value. | **SECURITY-CRITICAL** | *(maintainer, 2026-05-13)*; consistent with the post-2.17 reshape after CVE-2021-44228. |\n| **P2** | Structured-layout injection prevention. XML, JSON, and RFC 5424 layouts produce well-formed output that cannot be made to inject extra fields, break framing, or split records by in-scope input. | Layout is one of the structured layouts; output is consumed as that format. CRLF in unstructured layouts is out (\u00a74.9). | Injected field, broken framing, attacker-controlled record boundary. | **SECURITY-CRITICAL** | *(documented \u2014 common threat model)* |\n| **P3** | Bounded resource use per log call. Per-call CPU and memory use is linear (or better) in the size of a single in-scope input; no unbounded recursion reachable from in-scope input. | Configuration is trusted. Input is in-scope. | Hang, OOM, or `StackOverflowError` originating from a Log4j frame during a logger call. | **SECURITY-CRITICAL** if super-linear or unbounded; correctness-only for constant-factor regressions. | *(maintainer, 2026-05-13)* \u2014 explicit threshold not previously written down. |\n| **P4** | Thread safety of the public API. Concurrent `log.*()` calls from any thread on any number of `Logger` instances do not crash, corrupt internal state, or deadlock. | Caller uses the public API. | Crash, internal-state corruption, deadlock originating in a Log4j frame. | CORRECTNESS, unless it enables P1/P2/P3. | *(inferred)* \u2192 \u00a74.14 Q10 |\n| **P5** | No deserialization of in-scope bytes. Log4j Core does not pass bytes obtained from any in-scope source to `ObjectInputStream.readObject()` or equivalent. **No Family C module deserializes its backing transport's bytes** *(maintainer, 2026-05-13)*. | Production code path; default modules. | In-scope bytes reach a deserializer controlled by Log4j. | **SECURITY-CRITICAL** | *(documented \u2014 FAQ; maintainer 2026-05-13 for Family C extension)* |\n| **P6** | Best-effort delivery with documented escape. Events are delivered as configured; when an async queue fills, events are written to the internal **StatusLogger** rather than dropped silently. | Async appender configured; queue full. | Async event vanishes without surfacing on StatusLogger. | CORRECTNESS | *(maintainer, 2026-05-13)* |\n| **P7** | Garbage-free-mode invariance. Enabling garbage-free mode does not weaken P1\u2013P5. | Garbage-free mode is enabled per `log4j2.enable.threadlocals` and related properties. | Any of P1\u2013P5 holds in default mode but not in garbage-free mode. | Same as the underlying property. | *(maintainer, 2026-05-13)* \u2192 \u00a74.14 Q11 (edge probe) |\n| **P8** | Plugin discovery determinism. Plugin discovery is deterministic given a fixed classpath. | Classpath is fixed for the lifetime of the JVM (the trusted-classpath assumption of \u00a74.3). | Two runs with the same classpath produce different plugin resolutions. | CORRECTNESS (supports supply-chain reasoning). | *(maintainer, 2026-05-13)* \u2192 \u00a74.14 Q12 (edge probe) |\n\n---\n\n## \u00a74.9 Security properties the project does NOT provide\n\nThe companion to \u00a74.8. Stated plainly so a downstream integrator does\nnot import an assumption Log4j refuses to make.\n\n- **No log-injection protection in unstructured layouts.** Pattern Layout\n  has no field structure and makes no attempt to neutralize control\n  characters; CRLF in Pattern Layout output is not a vulnerability.\n  *(documented \u2014 security FAQ)*\n- **No CRLF escaping in RFC 5424 `MSG` / `PARAM-VALUE` fields by the\n  layout itself.** RFC 5424 \u00a78.2 delegates control-character handling to\n  the transport binding; Log4j follows the RFC. *(documented \u2014 security FAQ)*\n- **No safety guarantee for deserialization performed by the application.**\n  Log4j Core itself does not deserialize (P5), but if your application\n  serializes Log4j objects and deserializes them from an untrusted\n  source, that is not Log4j's problem. Filtering by package or\n  namespace is not sufficient to make deserialization safe; any\n  hardening utilities Log4j ships are partial and not exhaustive.\n  *(documented \u2014 common threat model + FAQ)*\n- **No log delivery guarantee.** P6 covers the StatusLogger fallback;\n  the project does not promise that every event reaches every\n  appender's destination. *(documented + maintainer, 2026-05-13)*\n- **No ordering guarantee** across threads or across appenders. *(inferred)*\n  \u2192 \u00a74.14 Q13\n- **No constant-time operations.** Log4j does not implement\n  side-channel-resistant primitives. Do not use Log4j to compare\n  secrets, render secrets, or in any code path where timing is a\n  security signal. *(inferred \u2014 companion to \u00a74.3)* \u2192 \u00a74.14 Q3\n- **No confidentiality of log content.** Whatever the application\n  hands to `log.*()` may end up in any appender's destination in plain\n  text; redaction is the application's responsibility (\u00a74.10).\n  *(documented)*\n- **No TLS hostname verification or mutual TLS by default** on the\n  Socket appender (`log4j2.sslVerifyHostName=false`). This is the one\n  remaining insecure default; see \u00a74.5a and \u00a74.13.\n  *(maintainer, 2026-05-13)*\n\n### False friends (features that look like security properties but are not)\n\n- **JSON / XML / RFC 5424 layouts \u2260 a confidentiality boundary.** They\n  prevent *injection* (P2), not exposure. Sensitive data still has to\n  be masked by the application.\n- **The `${jndi:\u2026}` lookup \u2260 a sandboxed retrieval mechanism.** Even\n  with `enableJndiLookup=true` and the `java:`-protocol restriction,\n  this is a designed-for-trusted-input feature, not a defensive layer\n  against untrusted input.\n- **`monitorInterval` config reload \u2260 a hot-patching security\n  mechanism.** It is a developer-convenience reload. It does not gate\n  what the new config can do.\n- **`StatusLogger` \u2260 a structured event channel.** It writes to stderr\n  by design and is for the operator's eyes. *(inferred)* \u2192 \u00a74.14 Q14\n\n### Well-known attack classes the project leaves to the caller\n\n- **Log injection into downstream parsers (CWE-117)** for unstructured\n  layouts (Pattern Layout). Pick a structured layout, or sanitize at the\n  parser side.\n- **Log forging** beyond CRLF: timestamps, level fields, MDC contents in\n  a Pattern Layout can be spoofed by message content.\n- **Compression-oracle-style attacks** against any compressed appender\n  destination. Not modeled.\n- **Decompression bombs** on the *source* of the configuration only \u2014 but\n  configuration is trusted, so this is N/A in practice.\n- **Resource exhaustion via cardinality** (unbounded marker / logger\n  names from user input) \u2014 see \u00a74.10. *(maintainer, 2026-05-13)*\n\n---\n\n## \u00a74.10 Downstream responsibilities\n\nThe contract the embedding application and operator must uphold for\nthe \u00a74.5\u2013\u00a74.7 assumptions to hold:\n\n**Application developer:**\n- Use compile-time-constant format strings; never source them from\n  input. *(documented)*\n- Mask sensitive data **before** the `log.*()` call. *(documented)*\n- Don't put attacker-controlled data into ThreadContext **values** if\n  your layout interpolates them. *(documented)*\n- Don't derive Marker or Logger names from untrusted input; if you do,\n  you own the cardinality / memory cost. *(maintainer, 2026-05-13)*\n- Don't deserialize Log4j-emitted bytes from an untrusted source.\n  *(documented)*\n\n**Operator / deployer:**\n- Keep configuration files, system properties, and environment\n  variables out of attacker reach. *(documented)*\n- Use confidential channels (TLS) for any non-local appender; disable\n  HTTP / JMX on untrusted networks. *(documented)*\n- **Set `log4j2.sslVerifyHostName=true` and configure mutual TLS** on\n  any Socket appender exposed to an untrusted network \u2014 the default\n  is unsafe and will remain so until a future hardening. *(maintainer, 2026-05-13)*\n- Restrict log-file read access to authorized readers. *(documented)*\n- If you flip any \u00a74.5a knob (`enableJndi*`, `disableJmx=false`,\n  `scriptEnableLanguages`), audit the downstream data flow first;\n  having flipped one is sufficient to move a finding from `OUT-OF-MODEL`\n  to operator responsibility. *(maintainer, 2026-05-13)*\n\n**Operator of a Family C destination:**\n- The destination (mail server, JMS broker, DB, Mongo, Cassandra,\n  Couch, Docker daemon) is trusted; do not connect Log4j to one you\n  do not operate. *(maintainer, 2026-05-13)*\n\n---\n\n## \u00a74.11 Known misuse patterns\n\nThe single highest-frequency misuse, per maintainer:\n\n- **Treating Pattern Layout output as machine-parseable.** Pattern Layout\n  is for human readers; it has no escaping rules. Downstream parsers\n  that consume it as structured data and assume sanitization will be\n  surprised. The fix is to switch to a structured layout (JSON, XML,\n  RFC 5424) for the machine-consumed pipeline. *(maintainer, 2026-05-13)*\n\nOther recurring misuses (lower frequency, all *(inferred)* until\nmaintainer ratifies \u2192 \u00a74.14 Q15):\n\n- Putting attacker-controllable data into ThreadContext **values** and\n  using a layout that interpolates them, especially while also flipping\n  `enableJndiLookup=true` \u2014 the Log4Shell-shape misuse.\n- Deriving `Logger` or `Marker` names from request-scoped user data\n  and producing unbounded cardinality.\n- Logging the result of `Throwable.toString()` of an exception whose\n  message field carries user input, then parsing the rendered output.\n- Using `log4j-1.2-api` as if it gave 1.x guarantees; it is a *bridge*,\n  not a re-implementation.\n\n---\n\n## \u00a74.11a Known non-findings (recurring false positives)\n\nTool, fuzzer, AI, and human reports that match these patterns are\n**not** bugs under this model. Cite the row when closing.\n\n| Pattern | Why it's not a finding | Suppression cite |\n| ------- | ---------------------- | ---------------- |\n| CRLF (or any control char) appears in Pattern Layout output | Pattern Layout is unstructured by design; \u00a74.9 disclaims log-injection protection there. | \u00a74.9, security/faq.html#crlf-injection-cwe-93 |\n| CRLF (or any control char) appears in RFC 5424 `MSG` or `PARAM-VALUE` | RFC 5424 \u00a78.2 delegates this to the transport binding; Log4j follows the RFC. | \u00a74.9, security/faq.html#crlf-injection-cwe-93 |\n| Path-traversal-ish characters in a config file path | Config files are trusted; \u00a74.3. | \u00a74.3, security/faq.html#path-traversal-cwe-35 |\n| Static analyzer flags `ObjectInputStream.readObject()` somewhere in a Log4j module | Log4j Core does not deserialize bytes from any in-scope source on the production path (P5); the call site reachable only from trusted sources (config) is not a finding. | \u00a74.8 P5, security/faq.html#deserialization-of-untrusted-data-cwe-502 |\n| Anything in `log4j-*-test`, `-fuzz-test`, `-its`, `-perf-test`, `-osgi-test` | Out of scope per \u00a74.3. | \u00a74.3 |\n| \"Lookups in message text are an RCE\" | Removed in 2.16; reporter is reading pre-2.16 behavior. | \u00a74.5a (formatMsgNoLookups note) |\n\nA \u00a74.14 question asks whether further patterns belong here.\n\n---\n\n## \u00a74.12 Conditions that would change this model\n\nA revision is required when any of these is true:\n\n- A new public API surface is added (e.g. a new entry point that\n  accepts data of a kind not yet in the \u00a74.6 table).\n- An existing entry point begins to accept input from a new source.\n- A \u00a74.5a default changes (especially `sslVerifyHostName` when it is\n  hardened) or a knob is added/removed.\n- Log4j gains a network listener (it currently has none).\n- A Family-C module begins to read inbound bytes from its backing\n  transport (would require P5 to be re-examined).\n- A bridge module (Family B) develops a trust profile distinct from\n  Family A's.\n- The 3.x branch reaches GA.\n- A vulnerability report cannot be cleanly routed to any \u00a74.13\n  disposition. (See \u00a74.13 `MODEL-GAP`.)\n\nInternal refactors that do not change any of the above do **not**\nrequire revision.\n\n---\n\n## \u00a74.13 Triage dispositions\n\nThe closed set of outcomes for a vulnerability report, tool finding,\nor AI analysis judged against this model.\n\n| Disposition | Meaning | Licensed by |\n| ----------- | ------- | ----------- |\n| **`VALID`** | Violates a \u00a74.8 property via an in-scope adversary (\u00a74.7) and an attacker-controllable input (\u00a74.6) on a default 2.x build (\u00a74.5a). | \u00a74.6, \u00a74.7, \u00a74.8 |\n| **`VALID-HARDENING`** | No \u00a74.8 property is violated, but the API or default makes a \u00a74.11 misuse easy enough that the project elects to harden. Reported privately; fixed at maintainer discretion; typically no CVE. **The `sslVerifyHostName=false` default is currently in this category.** *(maintainer, 2026-05-13)* | \u00a74.5a, \u00a74.11 |\n| **`OUT-OF-MODEL: trusted-input`** | Requires attacker control of a parameter the \u00a74.6 table marks **No** (e.g. format string, TC key, logger name, RFC 5424 identifier fields). | \u00a74.6 |\n| **`OUT-OF-MODEL: adversary-not-in-scope`** | Requires a capability outside \u00a74.7 (in-JVM execution, classpath control, side-channel observation, malicious appender destination). | \u00a74.7 |\n| **`OUT-OF-MODEL: unsupported-component`** | Lands in Family D (test/fuzz/perf harness) or in code shipped from a different repo (Log4j 1.x, 3.x pre-GA). | \u00a74.3 |\n| **`OUT-OF-MODEL: non-default-build`** | Manifests only under a \u00a74.5a knob the operator flipped from its safe default (`enableJndi*`, `scriptEnableLanguages`, `disableJmx=false`). | \u00a74.5a |\n| **`BY-DESIGN: property-disclaimed`** | Concerns a property \u00a74.9 explicitly does not provide (CRLF in unstructured layouts, ordering, constant-time, deserialization-by-the-app). | \u00a74.9 |\n| **`KNOWN-NON-FINDING`** | Matches a \u00a74.11a row. | \u00a74.11a |\n| **`MODEL-GAP`** | Cannot be cleanly routed to any of the above; triggers a \u00a74.12 revision rather than an ad-hoc call. | \u00a74.12 |\n\n---\n\n## \u00a74.14 Open questions for the maintainers\n\nWave-4 questions, prioritized. Every *(inferred)* tag in the body\nabove maps to one of these.\n\n### Q1 \u2014 Are application-server / container deployment shapes invariant?\n\n\u00a74.2 claims the threat profile is the same in standalone JVM, app\nserver, Spring Boot, and container. **Proposed answer:** yes, because\nin all cases Log4j runs in-process with the application and the\nclasspath is operator-trusted. Confirm or carve out any exception\n(e.g. shared-classloader app servers where another tenant's code is in\nthe same JVM).\n\n### Q2 \u2014 Trusted-classpath is the right framing for plugin loading?\n\n\u00a74.3 places \"anyone who can add a class to the classpath\" out of\nscope. **Proposed answer:** yes, plugin loading uses standard\nclasspath discovery; classpath is part of the deployment, which is\noperator-trusted. Confirm.\n\n### Q3 \u2014 Are side-channel adversaries fully out of scope, or only most of them?\n\n\u00a74.3 + \u00a74.9. **Proposed answer:** fully out of scope; Log4j makes no\nconstant-time / side-channel-resistance claim. Confirm there is no\nappender or layout where you *do* claim some side-channel resistance.\n\n### Q4 \u2014 Reachability precondition wording for Family A.\n\n\u00a74.4. **Proposed answer:** \"A Family A finding is in-model only if\nreachable from an attacker-controllable input on a default 2.x\nbuild.\" Is this the wording you want, or do you want to add \"and\nthrough a public entry point\" (i.e. excluding findings in internal\ncollaborator classes reached only by reflection)?\n\n### Q5 \u2014 Memory-model assumption explicitness.\n\n\u00a74.5. **Proposed answer:** Log4j assumes the standard Java Memory\nModel; no other claim. Confirm.\n\n### Q6 \u2014 Clock assumption.\n\n\u00a74.5. **Proposed answer:** wall-clock used for timestamps;\nmonotonicity is not assumed; clock skew between hosts is the\noperator's problem. Confirm.\n\n### Q7 \u2014 Throwable's message + stack trace as untrusted.\n\n\u00a74.6 row. **Proposed answer:** yes \u2014 a `Throwable` whose message\nfield carries user input is in-scope adversary-controllable; Log4j\nmust render it safely (P1, P2 inside structured layouts). Confirm.\n\n### Q8 \u2014 Documented input size caps.\n\n\u00a74.6. **Proposed answer:** no hard caps; resource use is bounded per\nP3. Confirm there is no documented per-call message length, parameter\ncount, or TC entry limit.\n\n### Q9 \u2014 Partial / chunked log events.\n\n\u00a74.6. **Proposed answer:** no streaming-event API; each `log.*()`\ncall is a single event. Confirm.\n\n### Q10 \u2014 P4 thread safety blanket.\n\n\u00a74.8. **Proposed answer:** blanket thread safety of the public API;\nnon-public `*Impl` types are not part of the claim. Wave-2 answer\nsuggested the only carve-out is the async-full \u2192 StatusLogger\nfallback, which is a P6 concern, not a P4 one. Confirm P4 stands.\n\n### Q11 \u2014 P7 garbage-free invariance \u2014 edge probe.\n\n\u00a74.8. **Proposed answer:** P1\u2013P5 hold identically in garbage-free\nmode. Any known case where garbage-free mode weakens a guarantee\n(e.g. a layout that falls back to a less-safe path under GC pressure)?\n\n### Q12 \u2014 P8 plugin discovery determinism \u2014 edge probe.\n\n\u00a74.8. **Proposed answer:** deterministic given a fixed classpath. Any\nknown nondeterminism (e.g. file-system enumeration order on certain\nclass loaders) that should be carved out?\n\n### Q13 \u2014 Ordering guarantee absence.\n\n\u00a74.9. **Proposed answer:** no ordering guarantee across threads or\nacross appenders. Confirm.\n\n### Q14 \u2014 StatusLogger as not-a-structured-channel.\n\n\u00a74.9 false-friends row. **Proposed answer:** StatusLogger writes to\nstderr by design; reports about its destination or format are not\nfindings. Confirm; should this also be a \u00a74.11a row?\n\n### Q15 \u2014 Misuse-pattern ratification.\n\n\u00a74.11. The top misuse is \"treat Pattern Layout output as\nmachine-parseable\" *(maintainer, 2026-05-13)*. The four secondary\npatterns (TC-value-into-interpolating-layout, unbounded\nmarker/logger cardinality, Throwable message echo, log4j-1.2-api\nexpectations) are *(inferred)*. Confirm or strike each.\n\n### Q16 \u2014 Further known non-findings (\u00a74.11a).\n\nWave-3 answer said \"none of these options have been reported lately.\"\nBut the current \u00a74.11a has only six rows (four from the FAQ, two\nfrom this drafting). Are there others scanners or researchers\nrecurrently submit that should be on the list \u2014 e.g. specific CodeQL\nqueries, specific FindSecBugs rules, specific OSS-Fuzz signal types?\nWithout a list, triagers will keep re-deriving the calls.\n\n### Q17 \u2014 Coexistence publication plan.\n\n\u00a74.1 says this doc is the canonical Log4j-2 model and the website's\ncommon doc remains the cross-project parent. Do you want this file\nchecked into `apache/logging-log4j2` (and published as part of the\nLog4j 2 docs site, replacing the brief link in `SECURITY.adoc`), or\nchecked into `apache/logging-site` next to `_threat-model-common.adoc`?\nAffects where the back-map (\u00a74.16) lives.\n\n---\n\n## \u00a74.15 Machine-readable companion (sketch)\n\nA sidecar `log4j-threat-model.yaml` should expose, at minimum:\n\n```yaml\nfamilies:\n  A: { modules: [log4j-api, log4j-core, ...], in_model: true }\n  B: { modules: [log4j-1.2-api, ...], in_model: true }\n  C: { modules: [log4j-jakarta-jms, ...], in_model: true, endpoint_trusted: true }\n  D: { modules: [\"log4j-*-test\", ...], in_model: false }\nflags:\n  log4j2.enableJndiLookup: { default: false, security_relevant: true, posture: supported_off }\n  log4j2.sslVerifyHostName: { default: false, security_relevant: true, posture: supported_with_hardening }\n  ...\ntrust_table:\n  - { entry: \"Logger.info\", param: \"fmt\",      attacker_controllable: false }\n  - { entry: \"Logger.info\", param: \"params[i]\", attacker_controllable: true  }\n  ...\nproperties:\n  P1: { severity: critical, symptom: \"RCE from in-scope input\" }\n  P2: { severity: critical, symptom: \"structured layout injection\" }\n  P3: { severity: critical, symptom: \"super-linear or unbounded resource use per call\" }\n  ...\ndisclaimed: [crlf_unstructured, crlf_rfc5424, deserialization_by_app, log_delivery, ordering, constant_time, confidentiality, tls_hostname_default]\nnon_findings: [crlf_pattern, crlf_rfc5424_msg, config_path_traversal, readobject_in_core, family_d_modules, pre_216_lookups]\ndispositions: [VALID, VALID-HARDENING, OUT-OF-MODEL/trusted-input, OUT-OF-MODEL/adversary-not-in-scope, OUT-OF-MODEL/unsupported-component, OUT-OF-MODEL/non-default-build, BY-DESIGN/property-disclaimed, KNOWN-NON-FINDING, MODEL-GAP]\n```\n\nRegenerate whenever this prose document changes.\n\n---\n\n## \u00a74.16 Back-map to the website security artifacts\n\nProof of the strict-superset property required by skill \u00a73.1a. Every\nstatement in the website's `_threat-model-common.adoc` and\n`security/faq.html` is reflected here:\n\n| Website statement | This document |\n| ----------------- | ------------- |\n| Trusted Users: developers + administrators with unrestricted access | \u00a74.2 |\n| Untrusted Users: all other parties | \u00a74.7 |\n| Trusted sources: env vars, config properties, config files | \u00a74.3, \u00a74.5a |\n| Trusted: log-statement objects (safely convertible to strings) | \u00a74.6 (`params[i].toString()` row \u2014 though Log4j must safely render the result) |\n| Trusted: format strings in parameterized logging | \u00a74.6 (first row), \u00a74.10 (developer responsibility) |\n| Untrusted: log messages, parameter string repr | \u00a74.6 |\n| Untrusted: thread context keys and values | \u00a74.6 \u2014 **superseded for keys** *(maintainer, 2026-05-13)* |\n| Deployer responsibility: prevent untrusted write access to config | \u00a74.10 |\n| Deployer responsibility: confidential channels; disable HTTP/JMX | \u00a74.10 (JMX is now off-by-default per \u00a74.5a) |\n| Deployer responsibility: trusted data only with interpolation | \u00a74.10 |\n| Log injection (CWE-117): unstructured layouts NOT protected; structured MUST be | \u00a74.8 P2, \u00a74.9 |\n| Supply chain (CWE-1357): deps verified, releases signed | (out of scope per skill \u00a71 / \u00a75; documented in `SECURITY.adoc` and ASF release procedures) |\n| Information disclosure (CWE-200): deployer + developer responsibility | \u00a74.10 |\n| Log Reliability: events delivered by design; use reliable transports | \u00a74.8 P6, \u00a74.10 |\n| DoS (CWE-779): configure levels and appenders | \u00a74.10 (operator); \u00a74.8 P3 adds maintainer-stated threshold |\n| Deserialization (CWE-502): no guarantee | \u00a74.8 P5, \u00a74.9 |\n| CVE-2018-1285 reclassified as non-vuln (config is trusted) | \u00a74.3, \u00a74.13 (`OUT-OF-MODEL: trusted-input`) |\n| CRLF in Pattern Layout: not a vuln (unstructured by design) | \u00a74.9, \u00a74.11a |\n| CRLF in RFC 5424: transport-binding's responsibility per RFC \u00a78.2 | \u00a74.9, \u00a74.11a |\n| Path traversal in config: config is trusted | \u00a74.3, \u00a74.11a |\n| Deserialization FAQ: Log4j Core does not deserialize on its own | \u00a74.8 P5, \u00a74.11a |\n\nNothing in the common doc has been silently weakened or dropped. The\nthree points where this document goes further than the common doc are\nclearly tagged *(maintainer, 2026-05-13)* and listed in \u00a74.7.\n\nDrop this appendix from the published version only when the maintainer\nagrees the Log4j-2 doc has become canonical for these statements (per\n\u00a74.14 Q17).", "creation_timestamp": "2026-05-13T16:36:23.000000Z"}]}