Threat Model — Apache Dubbo

§1 Header

Field	Value
Project	Apache Dubbo
Version/commit	3.3 branch (commit to be pinned at release)
Date	2026-06-05
Author(s)	AI-assisted, maintainer-interviewed
Status	Reviewed — maintainer interview completed (Wave 1 + Wave 2)

Version binding. This threat model is versioned alongside the project. A vulnerability report against Dubbo N is triaged against this model as it stood at N, not at HEAD.

Reporting cross-reference.

Findings that violate §8 (claimed properties) should be reported to security@dubbo.apache.org per SECURITY.md.
Findings that fall under §3 (out of scope) or §9 (disclaimed properties) will be closed citing this document.

Provenance legend.

Tag	Meaning
(documented)	Stated in Dubbo's own docs (README, source comments, official website, SECURITY.md). Source cited inline.
(maintainer)	Stated by a maintainer in response to a question from this process.
(inferred)	Reasoned from code structure, absence of a feature, or general domain knowledge — not yet confirmed. Must have a matching entry in §14.

Draft confidence.

Tag	Count
(documented)	30
(maintainer)	13
(inferred)	5

One-paragraph description. Apache Dubbo is a high-performance, extensible RPC and microservices framework for Java. It provides service discovery, load balancing, traffic management, and observability for distributed systems. Applications use Dubbo's API (Spring Boot starters or programmatic configuration) to export and consume remote services over protocols such as Triple (HTTP/2, gRPC-compatible), Dubbo TCP, and REST. Service metadata is managed through pluggable registries (ZooKeeper, Nacos, etc.) and configuration centers. Dubbo assumes an internal-network deployment model throughout (maintainer).

§2 Scope and intended use

Primary intended use cases

In-process Java library for building RPC-based microservices. A developer adds Dubbo as a dependency, configures service interfaces, and the framework handles remote invocation, serialization, service discovery, and load balancing (documented: README.md).
Service-to-service communication between Java applications (providers and consumers) within a trusted internal network. The entire framework is designed around this assumption (maintainer — “整个Dubbo都默认在内网环境工作”).
Polyglot communication via Triple protocol (gRPC-compatible) with Go, Python, Rust, and other language implementations (documented: README.md).

Deployment contexts

In-process Java library (not a standalone server or daemon).
Typically deployed inside Spring Boot or plain Java applications.
JDK 8–21 supported (3.3.x line) (documented: README.md).
Designed for internal data-center / VPC deployment; not designed for direct internet exposure.

Caller expectations

Role	Trust level	Description
Provider developer	Trusted	Configures and exports services; sets auth, SSL, serialization policy
Consumer developer	Trusted	Configures and invokes remote services
Operator	Trusted	Manages registry, config center, QoS access
RPC Client (network)	Untrusted	Any network client reaching the provider's RPC port
Registry	Trusted	Dubbo “can only fully trust the data [registries] push” (documented: official security docs). Confirmed: compromised registry = total cluster compromise (maintainer).
Config Center	Trusted	Pushes configuration that may contain credentials

Component-family table

Family	Representative entry point	Touches network	In this model
RPC Protocol (Triple)	`TripleProtocol.export()`, `TripleProtocol.refer()` — port 50051	Yes (HTTP/2)	Yes
RPC Protocol (Dubbo TCP)	`DubboProtocol.export()`, `DubboProtocol.refer()` — port 20880	Yes (TCP)	Yes
RPC Protocol (InJVM)	`InjvmProtocol`	No (in-process)	Yes
Serialization	SPI: `Serialization` interface (Hessian2, Protobuf, Java, Fastjson2, etc.)	No (encoding layer)	Yes
Registry	`RegistryFactory` → ZooKeeper/Nacos/Multicast	Yes (registry protocol)	Yes
Config Center	`ConfigCenterFactory`	Yes (config protocol)	Yes
Cluster / Routing	`Cluster` SPI, `Router` SPI	No (in-process routing)	Yes
QoS (Management)	`QosProtocolWrapper` — port 22222	Yes (TCP/HTTP)	Yes
Authentication	`dubbo-auth` plugin: `ConsumerSignFilter`, `ProviderAuthFilter`	No (filter chain)	Yes
TLS / Certificate	`SslConfig`, `DubboCertManager`	Yes (CA connection)	Yes
Spring Security	`dubbo-spring-security` / `dubbo-spring6-security` plugins	No (context propagation)	Yes
dubbo-demo	`dubbo-demo-api/`, `dubbo-demo-spring-boot/`	Varies	No — demo/test only
dubbo-test	`dubbo-test/`	Varies	No — test infrastructure
dubbo-compatible	Dubbo 2.x compatibility layer	No	No — scheduled for removal (maintainer)

§3 Out of scope (explicit non-goals)

Use cases not supported

Direct internet exposure. Dubbo is designed for internal networks. Exposing RPC ports (20880, 50051) or QoS (22222) to the internet without a reverse proxy, API gateway, or service mesh is not a supported use case (documented: security docs — “deploy in trusted internal network”; maintainer).
Standalone authorization engine. Dubbo has no built-in RBAC or ABAC. Authorization requires Istio integration (documented: security docs — authorization is “equivalent to Istio documentation”).
Certificate management and distribution. Users must provide their own PKI. Dubbo recommends Istio for this (documented: security docs).
Build-time or supply-chain security. Dependency pinning, artifact signing, and reproducible builds are out of scope for this threat model.
Dubbo Admin. Dubbo Admin is a separate project outside the Dubbo security boundary (maintainer).

Threats not defended against

A compromised registry that pushes malicious provider addresses (documented + maintainer confirmed).
A malicious provider that returns crafted deserialized objects to exploit the consumer (maintainer confirmed).
Insider attacks from operators or developers with access to the registry, config center, or QoS port.
Denial of service from unbounded resource consumption. Dubbo delegates rate limiting to external tools like Sentinel (maintainer).

Code that ships but is not covered

Path	Reason
`dubbo-demo/`	Demo/test only; explicitly for “debugging and smoke test purposes” (documented: dubbo-demo README)
`dubbo-test/`	Test infrastructure
`dubbo-compatible/`	Legacy compatibility; scheduled for removal (maintainer)
`*.class` files at repo root (e.g., `SimpleAI.class`)	Not part of the project

§4 Trust boundaries and data flow

Trust boundary locations

┌─────────────────────────────────────────────────────────────────┐
│                     Trusted Internal Network                    │
│                                                                 │
│  ┌──────────┐    RPC (Triple/Dubbo)    ┌──────────┐            │
│  │ Consumer │ ──────────────────────▶  │ Provider │            │
│  └────┬─────┘                          └────┬─────┘            │
│       │                                     │                   │
│       │ Subscribe/Register                  │ Register          │
│       ▼                                     ▼                   │
│  ┌──────────┐                         ┌──────────┐             │
│  │ Registry │ (ZK/Nacos)              │ Config   │             │
│  │          │                         │ Center   │             │
│  └──────────┘                         └──────────┘             │
│                                                                 │
│  ┌──────────┐                                                   │
│  │   QoS    │  port 22222 (telnet/HTTP)                        │
│  └──────────┘                                                   │
└─────────────────────────────────────────────────────────────────┘

Trust boundaries ( ─ ─ ─ ─ ):

1. Consumer ──Network──▶ Provider    (RPC data plane, unauthenticated by default)
2. App      ──Network──▶ Registry    (Control plane, trusted)
3. App      ──Network──▶ Config Center (Control plane, trusted)
4. Any Host ──Network──▶ QoS Port    (Management plane, localhost-restricted by default)
5. Consumer ◀──Deserialization──◀ Provider (Return value trust)

Data flow and trust transitions

Provider registration: Provider sends its URL (containing IP, port, serialization config, credentials) to the registry. Trust transition: Provider → Network → Registry. The registry is trusted to store and distribute this data faithfully.
Consumer subscription: Consumer queries the registry for provider URLs. Trust transition: Registry → Network → Consumer. Consumer trusts registry data (documented + maintainer confirmed).
RPC invocation: Consumer serializes method arguments and sends them to the provider's port (20880 or 50051). Serialization type is determined by provider-priority negotiation: the Provider declares supported serialization formats in its URL; if multiple formats are declared, negotiation occurs with Provider priority (maintainer). Provider deserializes and invokes. Trust transition: Consumer → Network → Provider. Without TLS, this is cleartext. Without auth, unauthenticated.
RPC response: Provider returns the result (serialized). Consumer deserializes. Trust transition: Provider → Network → Consumer. Consumer implicitly trusts the provider's return value (maintainer confirmed).
QoS command: Client connects to port 22222 via TCP telnet or HTTP, sends command text. Trust transition: Network → QoS Server. When acceptForeignIp=false (default), only loopback connections are accepted. Default anonymousAccessPermissionLevel is PUBLIC (maintainer confirmed — historical default).

Reachability preconditions per component

Component	Reachability precondition for a finding
RPC Provider	Attacker can reach the provider's RPC port (20880 or 50051)
RPC Consumer	Attacker controls a provider's return value OR the registry pushes a malicious provider address
Registry	Attacker has write access to the registry (ZK/Nacos)
QoS	Attacker can reach port 22222 (localhost or remote if `acceptForeignIp=true`)
Serialization	Attacker controls serialized data on the wire (either direction)
Config Center	Attacker has write access to the config center

§5 Assumptions about the environment

Operating system and runtime

JDK 8–21 on Linux, macOS, Windows (documented: README.md).
JVM memory model; no native code (pure Java).
Netty4 for network I/O (NIO/epoll).

Concurrency

Thread-per-connection model in Netty; Dubbo dispatches RPC calls to thread pools.
ServiceConfig and ReferenceConfig are not thread-safe for concurrent reconfiguration (inferred).

Network

Internal network assumed throughout. Dubbo's defaults (no TLS, no auth, no serialization strict mode) assume a trusted network. This is a foundational design assumption, not a temporary limitation (documented: security docs; maintainer — “整个Dubbo都默认在内网环境工作”).
DNS is trusted for hostname resolution (inferred).

What Dubbo does not do to its host

Does not open privileged ports (< 1024) by default.
Does not write to system directories.
Does not install signal handlers.
Does not spawn external processes (user code might).

§5a Build-time and configuration variants

Security-relevant configuration knobs

Knob	Default	Effect on security model	Discouraged?
`ssl-enabled`	`false`	Without SSL, all RPC traffic is cleartext	No, but opt-in
`auth`	`false`	No authentication on RPC requests	No, but opt-in
`serialize.check.status`	`WARN`	Logs but allows unlisted class deserialization; `STRICT` would block	Will become `STRICT` eventually (maintainer — “eventually”)
`serialize.check.serializable`	`true`	Enforces `Serializable` interface on deserialized classes	No
`qos.enable`	`true`	QoS server starts on port 22222	No
`qos.acceptForeignIp`	`false`	QoS only accepts loopback connections	No
`qos.anonymousAccessPermissionLevel`	`PUBLIC`	Anonymous users get PUBLIC-level command access (maintainer confirmed — historical default)	Review recommended
`authenticator` SPI	`basic`	Authentication mechanism selection	No
Serialization SPI	`hessian2`	Default serializer is Hessian2	No
`dubbo.cert.manager.caCertPath`	(empty)	Falls back to `InsecureTrustManagerFactory` if empty (documented: code — “will use insecure connection”)	Yes, code warns
`dubbo.cert.manager.oidcTokenPath`	(empty)	Connects to CA without auth token	Yes, code warns

The insecure-default case

Dubbo's default configuration provides no authentication, no encryption, and permissive deserialization. This is by design for the assumed internal-network deployment. Every security property in §8 is conditional on opt-in configuration.

§6 Assumptions about inputs

Input sources

Source	Example	Trusted?
RPC request body (consumer → provider)	Serialized method arguments	No — attacker can reach the provider port
RPC response body (provider → consumer)	Serialized return value	Partially — trusted if provider is trusted; compromised provider can attack consumer (maintainer confirmed)
Registry data	Provider URLs	Yes (documented + maintainer confirmed)
Config center data	Application configuration	Yes
QoS command input	Telnet/HTTP text	No — any client reaching port 22222
Serialization type	Determined by Provider-priority negotiation (maintainer)	Provider-controlled — Provider declares supported formats; Consumer negotiates within Provider's declared set
Dubbo URL parameters	Configuration strings	Yes — set by trusted developer/operator

Per-parameter trust table — RPC Provider (Dubbo TCP / Triple)

Entry point	Parameter	Attacker-controllable?	Caller must enforce
Dubbo TCP request	Serialization type	Partial — bounded by Provider's declared supported formats (maintainer)	Provider should declare only intended serializers
Dubbo TCP request	Request body (serialized args)	Yes	`serialize.check.status=STRICT` + allowlist
Dubbo TCP request	Service/interface name	Yes	Provider must expose only intended interfaces
Dubbo TCP request	Method name	Yes	Provider must validate method exists
Dubbo TCP request	Attachments (metadata)	Yes	Provider must not trust attachment values blindly
Triple HTTP/2 request	Content-Type	Yes	Provider must validate content-type matches expected serializer
Triple HTTP/2 request	HTTP headers	Yes	Provider must validate auth headers
Triple HTTP/2 request	gRPC trailers	Yes	Provider must validate
RPC response	Return value (serialized)	Partial (provider-controlled)	Consumer must use `STRICT` serialization mode

Per-parameter trust table — QoS

Entry point	Parameter	Attacker-controllable?	Caller must enforce
QoS telnet/HTTP	Command name	Yes	Permission level check
QoS `invoke`	Service/method selector	Yes	Must be PRIVATE permission
QoS `invoke`	JSON argument string	Yes	`PojoUtils.realize()` must be safe
QoS HTTP	Source IP	Partial (spoofable)	`acceptForeignIp` check

Size, shape, and rate assumptions

No built-in rate limiting at the framework level. Rate limiting is delegated to external tools like Sentinel (maintainer).
No request body size limit enforced by Dubbo; Netty's default max message size applies (varies by configuration) (inferred).
No limit on the number of service interfaces or methods a provider exposes.
Hessian2 deserialization can create deeply nested objects; no recursion depth limit enforced by Dubbo (inferred).

§7 Adversary model

Assumed attacker (in scope)

Network-level attacker who can:

Observe and modify traffic on the network between consumer and provider (MITM).
Send crafted RPC requests to any provider's RPC port.
Send crafted responses if they control a provider instance.
Connect to the QoS port if it is accessible.

Capabilities:

Can observe timing (inferred: no constant-time guarantees).
Can inject/modify packets on the wire (if TLS is not used).
Can influence serialized data content (controls request body).
Can request a serialization format, but Provider has priority in negotiation — the attacker cannot force a serialization format the Provider has not declared (maintainer).
Cannot break TLS/mTLS (assumes proper PKI).
Cannot write to the registry (registry is trusted).
Cannot write to the config center (config center is trusted).

Explicitly out of scope

Actor	Reason
Compromised registry	Dubbo explicitly trusts the registry (documented + maintainer)
Compromised config center	Configuration is trusted
Malicious Dubbo developer (insider)	Not a threat the framework can mitigate
Attacker with physical host access	OS-level compromise is out of scope
Compromised CI/CD pipeline	Supply-chain security is out of scope

Distributed-systems actor: authenticated-but-Byzantine provider

Dubbo's consumer implicitly trusts the provider (maintainer confirmed). A legitimately registered provider that turns malicious (or serves compromised code) can:

Return crafted serialized objects to exploit the consumer's deserialization (maintainer confirmed).
Slow-read or refuse connections to cause consumer timeouts.
Return incorrect results without detection (no result integrity verification).

This actor is in scope but Dubbo provides no defense against it by default.

§8 Security properties the project provides

P1: Serialization class checking (conditional)

Property: When serialize.check.status=STRICT, Dubbo blocks deserialization of classes not on the allowlist, mitigating deserialization-based RCE. (documented: code — DefaultSerializeClassChecker, official security docs)

Conditions: Requires explicit opt-in (STRICT mode); only applies to serializers integrated with SerializeSecurityManager (Hessian2, Fastjson2). Java native serialization is NOT covered.

Violation symptom: Remote code execution via gadget chain deserialization.