This is an automated email from the ASF dual-hosted git repository.
jungm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomee.git
The following commit(s) were added to refs/heads/main by this push:
new 6c06712eb8 initial AGENTS.md/SECURITY.md
6c06712eb8 is described below
commit 6c06712eb86835821b48d5d58bfc065d10e61ad5
Author: Markus Jung <[email protected]>
AuthorDate: Sun May 17 16:49:31 2026 +0200
initial AGENTS.md/SECURITY.md
---
AGENTS.md | 3 ++
SECURITY.md | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 121 insertions(+)
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000000..922fc03031
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,3 @@
+## Security
+
+See [SECURITY.md](SECURITY.md) — the linked security model for the project's
threat model, in-scope / out-of-scope declarations, and known non-findings
before reporting issues.
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 0000000000..6cb48ec3a4
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,118 @@
+# Apache TomEE — Security Model
+
+Apache TomEE is a Jakarta EE and MicroProfile runtime. The Apache TomEE
Security Team reviews reported vulnerabilities against the security model
described below. Reports that fall outside it will be rejected.
+
+Report suspected vulnerabilities privately to **[email protected]**. Do not
file security reports as public Jira tickets or GitHub issues.
+
+## Administrative users
+
+Administrative users are always considered to be trusted. Reports for
vulnerabilities where an attacker already has access to or control over any of
the following will be rejected:
+
+- TomEE binaries and scripts (everything under a TomEE distribution's `bin/`
and `lib/`).
+- TomEE configuration (`conf/`, `conf/tomee.xml`, `conf/system.properties`,
`conf/server.xml`, `conf/conf.d/`, realm files, JAAS login configuration).
+- Log files (`logs/`).
+- The temp directory (by default `$CATALINA_BASE/temp`).
+- Application working directories (by default `$CATALINA_BASE/work`).
+- The TomEE-provided web applications shipped with the distribution (`tomee/`,
`webaccess/`, plus/plume admin UIs).
+- The JMX API (local or remote).
+- The Java Attach API or any other debugging or agent interface.
+- The OpenEJB `apps/` and `webapps/` deployment directories.
+- Resource definitions in `tomee.xml` / `resources.xml` (datasources,
connectors, services).
+
+Reports for vulnerabilities where an attacker tricks an administrative user
into performing an action the administrator did not intend (e.g. CSRF in the
bundled TomEE web applications) will be accepted.
+
+## Deployed applications
+
+Applications and modules deployed to TomEE — WARs, EARs, EJB-JARs, RARs — are
considered to be trusted. This applies whether they are dropped into `webapps/`
or `apps/`, deployed via the Deployer, installed by `tomee-maven-plugin`, or
embedded via `tomee-embedded`. It also covers:
+
+- Application-provided JAX-RS / JAX-WS endpoints (handled by CXF but
configured by the application).
+- Application-provided JMS clients and listeners.
+- Application-provided JPA entities and persistence units.
+- Application-provided CDI beans, interceptors, and decorators.
+
+Vulnerabilities in application code are application vulnerabilities, not TomEE
vulnerabilities.
+
+Applications that enable functionality permitting modification of the deployed
application (hot-deploy endpoints, WebDAV, HTTP `PUT`, custom upload handlers)
are expected to secure that functionality themselves. Failure to do so is an
application vulnerability, not a TomEE vulnerability.
+
+Reports against the TomEE-provided web applications shipped with standard
distributions from the ASF — the TomEE webapp, web console, REST admin
endpoints, `webaccess`, plus/plume admin UIs — will be accepted. Reporters
should review the *Security Considerations* notes in the documentation for the
version under test before filing.
+
+## Connectors and transports
+
+Data received via any TomEE-exposed connector or transport is considered to be
untrusted, regardless of protocol. This explicitly covers the OpenEJB
transports under `server/`:
+
+- `openejb-ejbd` — the EJBd binary protocol.
+- `openejb-http` — OpenEJB's HTTP transport for remote EJB and REST
invocations.
+- `openejb-hessian` — Hessian RPC transport.
+- `openejb-ssh` — SSH-based admin transport.
+- CXF-backed JAX-WS and JAX-RS endpoints exposed by TomEE itself (separate
from application-provided endpoints in the *Deployed applications* section).
+
+**EJBd Java-object deserialization.** The EJBd protocol deserializes Java
objects from clients by design — this is what the protocol is. Exposing EJBd on
an untrusted network without authentication and a deserialization filter is
misuse, not a TomEE vulnerability. An optional transport flag enables TLS, but
the default cipher suite is not authenticated; operators are responsible for
selecting authenticated cipher suites and configuring a JEP 290 deserialization
filter (`-Djdk.serialFilte [...]
+
+All clients — including reverse proxies and remote EJB clients using
`openejb-client` — are responsible for the consequences of the data they
present to TomEE. If a client presents a malformed request that TomEE processes
per the protocol specification, any security impact to the client is the
client's responsibility.
+
+## Embedded network services
+
+TomEE can be configured to start network-listening services beyond the main
HTTP and EJBd transports. Each is admin-enabled; when enabled, the following
services require a trusted network or explicit authentication, and exposing
them on an untrusted network without hardening is misuse, not a TomEE
vulnerability:
+
+- **Embedded databases with network listeners.** Derby Network Server
(`openejb-derbynet`) and HSQLDB Server (`openejb-hsql`) listen on TCP ports
when configured to do so. Operators are responsible for binding them to trusted
interfaces or enabling their authentication.
+- **Embedded ActiveMQ broker.** When `openejb-activemq` is configured with a
network connector (e.g. a `tcp://` transport), the broker accepts JMS client
connections. Operators are responsible for the broker's authentication,
authorization, and TLS configuration.
+- **JMX over RMI.** TomEE exposes JMX MBeans. When a remote JMX connector is
enabled, operators are responsible for its authentication and TLS
configuration. (See also *Administrative users*: an attacker who already has
JMX access is treated as administrative.)
+- **The SSH admin transport** (`openejb-ssh`). Already covered as a connector
in *Connectors and transports*; mentioned here for completeness because it is
also an admin control plane.
+
+Reports against any of these services that assume they should be safe to
expose on an untrusted network without authentication will be rejected.
+
+## Service discovery
+
+OpenEJB provides peer-to-peer service discovery between cluster nodes via two
mechanisms:
+
+- **Multipoint discovery** (`MultipointDiscoveryAgent` / `MultipointServer` in
`openejb-server`). TCP-based gossip between known peers.
+- **Multicast discovery** (`MulticastDiscoveryAgent`, `MulticastPulseAgent` in
`openejb-multicast`). UDP multicast for peer discovery on a local network.
+
+A trusted network is integral to this feature. Operators who need to run
discovery across an untrusted network are responsible for providing
transport-level protection (VPN, network segmentation, etc.) themselves.
+
+Reports against multipoint or multicast discovery that depend on the absence
of network-layer protection — including deserialization of cluster traffic,
peer impersonation, or message injection — will be rejected on the basis that a
trusted network is part of the deployment contract.
+
+## Bundled third-party libraries
+
+TomEE distributions bundle implementations of Jakarta EE and MicroProfile
specifications from upstream projects, including (non-exhaustive):
+
+- Apache CXF (JAX-RS, JAX-WS).
+- Apache ActiveMQ (JMS broker and client).
+- Apache MyFaces and Mojarra (Jakarta Faces).
+- Apache OpenJPA (Jakarta Persistence).
+- Apache BVal (Jakarta Validation).
+- HSQLDB and Apache Derby (embedded databases).
+- MicroProfile implementations (JWT, Config, etc.).
+
+TomEE owns only its **integration code** — the wiring that exposes these
libraries through TomEE's deployment model, configuration, and defaults (for
example, how `openejb-cxf-rs` integrates CXF with the EJB container, or how a
`<Resource>` in `tomee.xml` configures an ActiveMQ broker).
+
+Reports of vulnerabilities in TomEE's integration code are accepted. Reports
of vulnerabilities in the upstream library itself — independent of how TomEE
wires it in — are out of scope; they should be reported to the upstream
project's security contact.
+
+**TomEE-modified library code is in scope.** TomEE does not ship all bundled
libraries unmodified. Where TomEE forks an upstream class (e.g. the BCEL
`ConstantPool`/`ConstantPoolGen` fork under `openejb.shade.*`, the patched
Tomcat `ServerInfo`), plants a class in an upstream package to reach internals
(e.g. `org.apache.bval.jsr.job.ConstraintValidators`,
`org.apache.catalina.startup.OpenEJBContextConfig`), shades or relocates a
library under TomEE coordinates (e.g. `commons-dbcp2-shade` [...]
+
+If you are unsure whether a finding is in TomEE's integration code or in the
upstream library, send it to **[email protected]** and the team will route it.
+
+## Logging
+
+Security-sensitive information will not be logged with the default
configuration apart from anything included in the request URI.
+
+Security-sensitive information may be logged with modified logging
configurations, particularly when debug logging is enabled. Common examples in
TomEE deployments:
+
+- Raising OpenEJB log levels.
+- Enabling CXF request/response logging (JAX-RS / JAX-WS).
+- Turning on JPA SQL logging (e.g. OpenJPA `openjpa.Log`, Hibernate
`show_sql`).
+- Enabling JMS broker trace logging.
+
+The default logs are likely to contain personally identifiable information
(PII) such as the IP address of users.
+
+TomEE is not responsible for the content of log messages generated by deployed
applications.
+
+## Known non-findings
+
+The following non-findings are frequently reported despite being invalid under
the model above. Repeated reports of non-findings from any source will be
treated as spam and will result in all email from the source being blocked at
the ASF's border.
+
+1. Any report that depends on deserialisation of OpenEJB multipoint or
multicast discovery traffic — discovery requires a trusted network (see
*Service discovery*).
+2. Any report that depends on write access to an application's `docBase`, to
the OpenEJB `apps/` deployment directory, or to any other location already
controlled by an administrative user per the *Administrative users* section
above.
+3. Any report that depends on deploying a malicious application — deployed
applications are trusted (see *Deployed applications*).
+4. Any report against the EJBd protocol, JMX, the embedded ActiveMQ broker,
Derby Network Server, HSQLDB Server, or other management or admin endpoints
that assumes they should be safe to expose on an untrusted network without
authentication (see *Connectors and transports* and *Embedded network
services*).
+5. Any report against bundled third-party libraries — including but not
limited to CXF, ActiveMQ, MyFaces, Mojarra, OpenJPA, BVal, HSQLDB, Derby, and
MicroProfile implementations — where the root cause is in the upstream library
as released rather than in TomEE's integration code or in any code TomEE forks,
patches, shades, or byte-code-transforms (see *Bundled third-party libraries*).
