Why a separate Jackrabbit model (not folded into Jackrabbit Oak). The Jackrabbit PMC owns three functionally distinct codebases. The original jackrabbit (commonly "Jackrabbit 2.x" / jackrabbit-core) and jackrabbit-oak share a JCR API contract but have different storage architectures, different security stacks (Oak introduced a redesigned SecurityProvider-based model; Jackrabbit-2 uses the older JR2 ACL + JAAS plumbing), different threading models, and — most importantly — different maintenance postures. Jackrabbit is in maintenance mode with JCR-API and reference-implementation work still happening but no major feature development; Oak is the active product. Triage rules and "what's in scope" differ enough that one document would have to caveat every claim. The Jackrabbit PMC has confirmed (.asf.yaml ties commits to oak-dev@jackrabbit.apache.org for Oak and jackrabbit-dev@… for this repo; they are run as one project but the codebases are independent) that the two are independent codebases. Modelling them separately is the more truthful representation. jackrabbit-filevault also gets its own model because its trust boundary (untrusted zip package → repository) is qualitatively different.

• Project: Apache Jackrabbit (apache/jackrabbit) — the original / legacy JCR implementation, distinct from Apache Jackrabbit Oak. Includes jackrabbit-core (repository), jackrabbit-spi / jackrabbit-spi2dav (SPI layer), jackrabbit-jcr-*, jackrabbit-webdav, jackrabbit-jcr2dav, and the JCR API artefacts (documented: README.txt, repo top-level).
• Commit / version binding: drafted against trunk. A vulnerability report against Jackrabbit version N should be triaged against the model as it stood at N (release tag).
• Date: 2026-05-30.
• Authors: ASF Security team draft, awaiting Jackrabbit PMC review.
• Status: draft — under maintainer review.
• Reporting cross-reference: findings that may violate a §8 property should be reported per the ASF Security Team disclosure channel (security@apache.org) and the project's security mailing list, before public disclosure. Findings under §3, §9, §11a will be closed by Jackrabbit triagers citing this document. (The Jackrabbit website hosts a CVE list at jackrabbit.apache.org/jcr/jackrabbit-security-reports.html — draft-time review of this URL did not produce a full enumeration for this draft; §14 Q1 asks the PMC to confirm the CVE history.)
• Provenance legend: (documented) — drawn from in-repo docs or website docs with citation; (maintainer) — confirmed by a Jackrabbit maintainer in response to this draft; (inferred) — synthesised from code structure or domain knowledge, awaiting PMC ratification (every (inferred) tag has a matching §14 question).
• Draft confidence: 14 documented / 0 maintainer / 32 inferred. (This model leans more heavily on inference than the Oak model because jackrabbit-core's docs are older and less prescriptive about modern security claims; many §8 properties need PMC ratification.)

About the project. Apache Jackrabbit is "a fully conforming implementation of the Content Repository for Java Technology API (JCR, specified in JSR 170 and 283)" (documented: README.txt). It predates Apache Jackrabbit Oak and was the original JCR reference implementation. The repository hosts:

• jackrabbit-core — the legacy repository implementation (JR2 / jackrabbit-2 storage architecture);
• jackrabbit-spi + jackrabbit-spi-commons + jackrabbit-spi2dav + jackrabbit-spi2jcr — the SPI layer used as a bridge between client and server when WebDAV is involved;
• jackrabbit-jcr-commons, jackrabbit-jcr-server, jackrabbit-jcr-tests, jackrabbit-jcr-client — the JCR client / server bindings and the JCR TCK harness;
• jackrabbit-webdav + jackrabbit-jcr2dav — WebDAV-over-JCR;
• examples/jackrabbit-firsthops — sample code.

The maintenance posture is "in active maintenance, not active feature development". Some users still run jackrabbit-2 production repositories (especially the WebDAV-over-JCR stack) but the PMC's forward-looking effort is on Oak (inferred — §14 Q2).

• In-process JCR 2.0 (JSR 283) repository implementation embedded by a host application, or exposed through one of jackrabbit- webdav / jackrabbit-jcr-server as a network service (documented: README.txt; module presence). Unlike Oak, Jackrabbit does ship network bindings.
• The JCR API artefacts and SPI layer are reusable on their own (callers depend on javax.jcr.* interfaces published from this repo); they are also dependencies of Oak and of jackrabbit- filevault.

Jackrabbit covers two distinct deployment shapes:

1. In-process JCR library — same shape as Oak: a host application instantiates a Repository, logs in, gets a Session, reads/writes.
2. Network-exposed via jackrabbit-webdav + jackrabbit-jcr-server + jackrabbit-jcr2dav — the repository is fronted by a WebDAV servlet; HTTP/WebDAV clients authenticate (usually via HTTP Basic or Digest) and the servlet translates WebDAV verbs into JCR operations. This brings authentication, HTTP parsing, and (in 2.x) XML parsing for WebDAV bodies onto the in-model surface.

This split is the most consequential modelling decision: the in-process and the network-exposed deployments have different adversary models (§7), different reachable surfaces (§4), and different downstream responsibilities (§10).

A finding is in-model only if it lands in a row marked yes; see §4 for per-component reachability tests.

Reports requiring any of these will be closed with the cited disposition:

1. Host application correctness (embedded mode) / servlet container configuration (network mode). Tomcat / Jetty misconfiguration, missing TLS, missing HTTP-Basic realm — those are operator / host issues (inferred — §14 Q7). → OUT-OF-MODEL: adversary-not-in-scope.
2. Underlying persistence-manager correctness. Jackrabbit-core's PMs delegate to filesystem or JDBC; a hostile filesystem / hostile database is not Jackrabbit's threat (inferred — §14 Q5). → OUT-OF-MODEL: trusted-input.
3. Failing to rotate the default admin/admin user. Documented convention; operator responsibility (inferred — §14 Q3). → OUT-OF-MODEL: non-default-build.
4. Code that ships but is not part of the supported product: jackrabbit-jcr-tests/ (TCK harness), examples/jackrabbit-firsthops/. → OUT-OF-MODEL: unsupported-component.
5. Issues that exist in jackrabbit-oak. Oak has its own threat model; cross-references not duplications.
6. Issues in jackrabbit-filevault. Filevault has its own threat model.
7. Build / release / SDLC hygiene. Out of model per the SKILL.
8. Java EE / J2EE container vulnerabilities when jackrabbit-jcr- server / jackrabbit-webdav is hosted under one. The container is the operator's choice (inferred — §14 Q8). → OUT-OF-MODEL: adversary-not-in-scope.
9. Maintenance-mode reality. This repository is in active maintenance for bug and security fixes but is not under active feature development (inferred — §14 Q2). A report that "feature X would be more secure if implemented as Y" is, in maintenance mode, more of a roadmap item than a triagable security claim, unless it concerns an upgrade path to a fix.
10. Side channels (cache timing, JVM JIT, co-resident JVM code). → OUT-OF-MODEL: adversary-not-in-scope.
11. WebDAV semantics that the protocol requires. WebDAV exposes directory listing, file PUT, MOVE, COPY, etc. A complaint that "this user can PUT and overwrite my file" is the JCR authorisation model's call, not a WebDAV-layer bug.

Jackrabbit has up to six trust transitions a finding must land inside to be in-model:

A finding is in-model only if it meets the family's reachability test:

• jackrabbit-core: reachable from a JCR session at B1 / B2 with the principal carrying less than admin authority.
• jackrabbit-webdav: reachable from an HTTP request body or header. XML-parse vulnerabilities (XXE, XML entity expansion, DTDs) are in-model here; the WebDAV bodies are the highest- blast-radius input on the network surface (inferred — §14 Q4).
• jackrabbit-jcr-server: in-model for the request-routing and authentication glue.
• jackrabbit-spi: in-model for the SPI bridge's own logic; the underlying SPI implementation is per-deployment trusted.
• jackrabbit-aws-ext (S3 data store): in-model for in-Jackrabbit code paths; the S3 backend itself is trusted.
• examples / TCK: out (§3 item 4).

• Java 11+ at HEAD; Maven 3 build (documented: README.txt). JVM-conformant runtime; no SecurityManager required.
• Servlet container (Tomcat / Jetty) when running in network mode. The container handles connection management, TLS, and often HTTP Basic / Digest realms.
• Persistence. jackrabbit-core uses one of several PMs (bundle PM, ObjectPersistenceManager, database PMs); each writes to a filesystem directory or a JDBC database the operator configures (inferred — §14 Q5).
• Data store. jackrabbit-core can use the FileDataStore (local files) or extensions (jackrabbit-aws-ext for S3); operator- configured trusted (inferred — §14 Q5).
• Search. Lucene-based search index on the filesystem under the repository home.
• Time — System.currentTimeMillis for lock timeouts and observation event timestamps; clock skew internal-only.
• What Jackrabbit does NOT do to its host (predominantly negative — §14 Q10):
  • opens listening sockets only through jackrabbit-jcr-server when it is deployed (in pure-library mode, none);
  • installs no process-wide signal handlers;
  • spawns no child processes from the core;
  • reads system properties (jackrabbit.*, etc.) but not arbitrary LD_* for security-relevant decisions;
  • writes log entries through slf4j.

The insecure-default case. The single most load-bearing knob is the default admin/admin user. The model assumes the operator's posture is "rotate or remove before production" — i.e. failing to rotate is OUT-OF-MODEL: non-default-build. PMC must ratify this in §14 Q3.

• WebDAV / JCR-server accept arbitrary-length request bodies subject to the servlet container's limits (inferred — §14 Q12).
• Jackrabbit core imposes no enforced cap on tree depth, child count, or query complexity (inferred — §14 Q12).
• Lucene full-text query parsing is unbounded by default; a pathological query can burn CPU (inferred — §14 Q12). No DoS protection by default.

The model does not include "authenticated-but-Byzantine peer" (there is no consensus / replication in jackrabbit-core).

• Condition. repository.xml Security element defines a LoginModule; Repository.login invokes the configured JAAS chain.
• Violation symptom. A Repository.login call returns a Session for credentials the configured chain should have rejected.
• Severity. Security-critical (VALID).
• (inferred — §14 Q9)

• Condition. Non-admin principal session; default AccessManager configured.
• Violation symptom. Session.getNode(path) returns an item the configured ACLs do not license.
• Severity. Security-critical (VALID).
• (inferred — §14 Q9)

• Condition. Non-admin principal session; default AccessManager.
• Violation symptom. A Session.save() commits a change the ACLs do not license.
• Severity. Security-critical (VALID).
• (inferred — §14 Q9)

• Condition. jackrabbit-jcr-server deployed; HTTP Basic or Digest realm configured; the servlet container honours the realm.
• Violation symptom. A WebDAV request without valid credentials reaches B2 trust transitions.
• Severity. Security-critical (VALID).

• Condition. Servlet container (Tomcat/Jetty) configured for HTTPS; jackrabbit-webdav does not strip TLS.
• Violation symptom. Cleartext on the wire after TLS is configured.
• Severity. Security-critical (VALID).
• (inferred — §14 Q15)

• Condition. DocumentBuilderFactory configured to disable external entities, disallow DOCTYPEs (or restrict them safely), and cap entity expansion.
• Violation symptom. A WebDAV body triggers XXE (file read, SSRF), Billion-Laughs, or DTD-based remote-fetch.
• Severity. Security-critical (VALID) when reachable from an unauthenticated or low-privilege HTTP peer.
• (inferred — §14 Q4; this is the single highest-confidence-required property for the network-exposed deployment)

• Condition. Default jackrabbit-core MVCC layer; one Session per thread.
• Violation symptom. Cross-session data leakage; a session reading data committed after its login without an intentional refresh.
• Severity. Correctness by default; security-critical iff cross-session leakage crosses an ACL boundary.
• (inferred — §14 Q16)

• Condition. JVM semantics; no Unsafe use in the core security paths.
• Violation symptom. OOB / UAF / data race observable.
• Severity. Security-critical when reachable from §6 input.
• (inferred — §14 Q17)

SimpleCredentials("admin","admin") always works against default config. If the host hands those out, the host has lost. (inferred — §14 Q3)

JDBC / FileDataStore / FS / S3 are all trusted. (inferred — §14 Q5)

Tomcat / Jetty operator owns the realm, the TLS posture, and the deployment descriptor. (inferred — §14 Q1)

No enforced cap on query complexity, tree depth, child count, transient state per session, or WebDAV body size. (inferred — §14 Q12)

§8 P6 is the inverse — this is the disclaimer if §14 Q4 reveals that jackrabbit-webdav does not harden its parser.

Delegated to PM / data-store backend.

Beyond what LoginModule / JCA helpers provide. (inferred — §14 Q18)

If jackrabbit's SimpleSecurityManager was configured to grant admin to any subject, that's the configuration speaking, not a bug.

• Default admin/admin is not a deployed-by-default backdoor — it is documented; the operator is expected to rotate. Whether failing to do so is VALID Jackrabbit or OUT-OF-MODEL operator-config is §14 Q3.
• HTTP Basic without TLS is not secure authentication. Credentials are base64 in cleartext.
• HTTP Digest is not TLS substitute. It protects the password in transit, not the content.
• WebDAV LOCK is an advisory locking primitive, not access control. A holder of LOCK does not become an authoriser.

• XXE / Billion-Laughs / DTD-fetch via WebDAV bodies — (inferred — §14 Q4).
• Authenticated-DoS (pathological queries / tree shapes) — §9.4.
• HTTP Basic over plaintext when jackrabbit-jcr-server is exposed without TLS — OUT-OF-MODEL: non-default-build or operator misconfiguration.
• TOCTOU between ACL evaluation and tree write — (inferred — §14 Q16).

The host application (and, in network mode, the operator) MUST:

1. Rotate or remove the default admin/admin user before exposing the repository to any non-trusted caller (inferred — §14 Q3).
2. Configure a LoginModule and an AccessManager that match the production trust posture. The shipped defaults are intended for demos.
3. Wrap jackrabbit-jcr-server / jackrabbit-webdav with TLS (servlet container HTTPS). HTTP Basic over plaintext is not acceptable production posture (inferred — §14 Q15).
4. Harden the XML parser configuration if jackrabbit-webdav is exposed (XXE, DTD, external-entity, billion-laughs) (inferred — §14 Q4).
5. Apply admission control / rate limits at the servlet container / reverse-proxy layer; Jackrabbit does not.
6. Restrict OS filesystem permissions on repository.home, persistence-manager directories, data-store directories, search index, and any keystores.
7. Track CVE advisories on this repo. Maintenance-mode posture means the security mailing list is the right channel for reports; binary patches are not produced per Apache convention.
8. Plan migration to Oak if the deployment is greenfield or if bug-fixes diverge — Oak is the active codebase (inferred — §14 Q2).

• Failing to rotate default admin/admin before production.
• Deploying jackrabbit-jcr-server / jackrabbit-webdav without TLS. HTTP Basic over plaintext is the default if the operator does not flip a switch.
• Exposing the WebDAV port directly without an authentication realm. WebDAV has no built-in auth; the servlet container does.
• Treating Jackrabbit as the active codebase and not Oak. For greenfield deployments, Oak is the active product.
• Using the SQL1 query language without auditing what callers can submit. SQL1 is more permissive than SQL2 / XPath.
• WebDAV PROPFIND Depth: infinity against the root — a documented amplification vector for any WebDAV-fronted store (inferred — §14 Q12).
• WebDAV MOVE / COPY with a Destination header pointing outside the configured workspace. ACL-bounded; the configured ACL is the gate.

• "Default admin/admin user exists in the shipped configuration." Documented; operator must rotate per §10. → OUT-OF-MODEL: non-default-build (subject to §14 Q3).
• "HTTP Basic credentials sent in cleartext when jackrabbit-jcr-server is exposed over HTTP." Operator must enable TLS (inferred — §14 Q15). → OUT-OF-MODEL: non-default-build.
• "DoS via pathological SQL2 / XPath query." No engine-level cap (inferred — §14 Q12). → BY-DESIGN: property-disclaimed.
• "Hardcoded test password / keystore in examples/jackrabbit-firsthops/, jackrabbit-jcr-tests/." Unsupported components. → OUT-OF-MODEL: unsupported-component.
• "Tomcat / Jetty configuration weakness." Container is the operator's. → OUT-OF-MODEL: adversary-not-in-scope.
• "Vulnerability X exists only in jackrabbit-oak." Oak's threat model and triage queue. → OUT-OF-MODEL: unsupported-component (cross-reference Oak model).
• "Vulnerability X exists only in jackrabbit-filevault." Filevault's threat model. → OUT-OF-MODEL: unsupported-component (cross-reference filevault model).
• "PROPFIND Depth: infinity is amplification." WebDAV protocol semantics; ACL-bounded.
• "Authenticated user with MODIFY_ACCESS_CONTROL rewrote ACL to grant self more privileges." Documented privilege behaviour. → BY-DESIGN: property-disclaimed.

• A new network listener in jackrabbit (currently only via jackrabbit-jcr-server / jackrabbit-webdav when deployed).
• A change in the shipped default LoginModule / AccessManager.
• A change in the shipped default admin/admin posture (e.g. randomised on first start).
• A change in jackrabbit-webdav's XML parser default hardening.
• A change in the project's maintenance posture (return to active feature development).
• A vulnerability report that cannot be cleanly routed to one of the §13 dispositions — that is evidence the model is incomplete.

A report against Jackrabbit receives exactly one of:

Q1. Confirm or correct the CVE inventory and the project's disclosure history page at https://jackrabbit.apache.org/jcr/jackrabbit-security-reports.html. Specifically: what CVEs have been issued against jackrabbit-core / jackrabbit-webdav in the last 5 years, and which patterns recur in inbound reports that you close as not-a-bug? (maps to §1 reporting, §11a)

Q2. Maintenance posture. Proposed: "active for bug + security fixes; not active for feature development; Oak is the recommended codebase for new deployments". Confirm or correct. (maps to §3 item 9, §10 item 8)

Q3. The default admin/admin user. Proposed disposition for "deployment X has not rotated the default admin": OUT-OF-MODEL: non-default-build. Confirm — or has the project moved to randomised first-start? (maps to §5a, §10 item 1, §11a)

Q4. The XXE question. Does jackrabbit-webdav ship hardened XML parser configuration (disable external entities, disallow DOCTYPE, cap entity expansion) for PROPFIND, LOCK, REPORT body parsing? This is the highest-leverage single question for the network-exposed deployment. If not, §8 P6 collapses into §9.5 and §10 item 4 becomes a hard production requirement. (maps to §4 B6, §6 WebDAV rows, §8 P6, §9.5)

Q5. Are persistence-manager backends (FileDataStore, bundle PM, database PMs, S3 via jackrabbit-aws-ext) all modelled as trusted backends — i.e. Jackrabbit does not defend against a malicious backend? Proposed: yes. (maps to §3 item 2, §9.2)

Q6. Module inventory: confirm or correct the list of supported modules vs unsupported / sample / TCK / extension modules. In particular: is jackrabbit-standalone / jackrabbit-standalone-components still part of the repo (the README didn't reach it); is jackrabbit-aws-ext an in-tree module or a separate artefact? (maps to §2 component family)

Q7. Servlet-container responsibility: confirmed that Tomcat / Jetty configuration (TLS, HTTP Basic / Digest realm, request body size caps, request timeouts) is out-of-model and the operator's responsibility? (maps to §3 item 1)

Q8. Java EE container vulnerabilities: confirmed out-of-model? (maps to §3 item 8)

Q9. What is the default LoginModule / AccessManager in the shipped repository.xml of jackrabbit-core? The §8 P1–P3 properties hinge on this configuration; this draft uses generic "configured LoginModule / AccessManager" placeholders. Please state the concrete default class names and the JAAS app-name they register under. (maps to §5a, §8 P1–P3)

Q10. "What Jackrabbit does NOT do to its host" inventory: no process-wide signal handlers, no child process spawn (outside network-mode servlet container), no arbitrary LD_* consumption, no on-disk persistence outside repository.home. Confirm any inaccuracies. (maps to §5)

Q11. Anonymous read posture. Is Repository.login(null, ws) (guest login without credentials) supported in any default configuration, or is it always disabled by default? (maps to §5a, §6, §7 unauthenticated row)

Q12. WebDAV / JCR / Lucene resource bounds. Confirmed that Jackrabbit imposes no enforced cap on:

• WebDAV request body size beyond servlet container limits;
• JCR query complexity (Lucene-based);
• tree depth / child count;
• transient session state;
• PROPFIND Depth: infinity cost?

If correct, all of these belong in §9.4 / §11a as BY-DESIGN: property-disclaimed. (maps to §6, §9.4)

Q13. Same-JVM attacker code (co-installed servlet, OSGi bundle, servlet container's other webapps): confirmed out-of-model? The host container is the security boundary. (maps to §7, §9)

Q14. Side-channel adversaries: confirmed out-of-model? (maps to §3 item 10, §7, §9)

Q15. TLS: confirmed that TLS is always the servlet container's job in network mode, never Jackrabbit's? (maps to §8 P5)

Q16. MVCC visibility: how does jackrabbit-core handle cross-session refresh? Proposed: session reads the revision captured at login, refreshable via Session.refresh. Confirm. (maps to §8 P7)

Q17. Memory safety of safe-Java: confirmed that the core security paths use no Unsafe / JNI? (maps to §8 P8)

Q18. Constant-time comparison of authentication secrets: confirmed all delegated to JAAS / LoginModule / JCA, with no Jackrabbit-internal equals on secrets? (maps to §9.7)

Q19. Should this document live as docs/threat-model.md or under jackrabbit-jcr-commons/src/site/markdown/? (meta)

Q20. Is there an existing Jackrabbit threat-model document (Confluence, JIRA, mailing-list summary, prior PMC discussion) that this should reconcile with rather than supersede? (meta — §3.1a)

Q21. §11a known-non-findings is currently 9 entries, mostly operator-misconfiguration-shaped. Could the PMC contribute 3–5 patterns the Jackrabbit triage queue sees recur in inbound reports that you close as not-a-bug? Patterns like "WebDAV exposed without TLS — operator misconfig, not Jackrabbit" and "DoS via huge PROPFIND Depth-infinity — WebDAV semantics" would harden §11a substantially. (meta — §11a)

Q22. Should this Jackrabbit model cross-reference the (still-to- be-drafted) jackrabbit-oak and jackrabbit-filevault models for items §3 items 5–6? (meta)

Jackrabbit does not currently ship an in-repo SECURITY.md. The de-facto security-policy artefacts are:

• the website page https://jackrabbit.apache.org/jcr/jackrabbit-security-reports.html (CVE history; not fully readable at draft time — §14 Q1);
• the README.txt at the top level (project description, Java / Maven requirements);
• the .asf.yaml (which routes notifications to jackrabbit-dev@…).

The back-map is sparse because the existing artefacts are mostly process-only: