Dokploy EUVD-2026-102485

Requires an authenticated account that is owner or admin of at least one organization on a multi-tenant Dokploy instance (i.e., a shared deployment hosting more than one organization), plus knowledge or enumeration of a valid portId or applicationId belonging to a victim organization, which is then passed to port.create/port.one/port.update/port.delete. No user interaction is needed. Limiting factors: exploitation is meaningless on single-tenant/single-org deployments, the attacker must already hold a privileged (owner/admin) role somewhere on the same instance, and impact is scoped to port-mapping configuration of other tenants' applications rather than full account or host compromise.

This is a genuine but moderate-severity multi-tenant authorization flaw (CWE-639 IDOR), not a drop-everything emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L, base 5.3 Medium) is internally consistent with the description: exploitation is over the network via the tRPC API, trivial (AC:L) once a target ID is known, requires an authenticated privileged account (PR:L - owner/admin of some organization), needs no user interaction, and yields only Low confidentiality/integrity/availability impact limited to port-mapping records. No CISA KEV entry and no EPSS score are present in the input, so there is no evidence of active exploitation or a quantified exploitation probability - this should be read as absence of signal, not as proof of safety. A public, detailed technical write-up (hackmd) documents the exact vulnerable code paths (port.ts and permission.ts at v0.30.8), which materially lowers the barrier to reproduction even though no weaponized exploit tool is referenced. The main factor tempering real-world risk is the PR:L prerequisite combined with the requirement for a shared multi-tenant instance: an attacker must already hold a privileged account on the same Dokploy deployment and know/enumerate a victim's portId or applicationId. Net assessment: a credible, easily-reproduced tenant-isolation bug worth prompt patching on any shared/multi-org Dokploy instance, but its Low impacts and authenticated, multi-tenant preconditions keep it below critical priority for single-tenant or small-footprint deployments.

On a shared Dokploy instance hosting multiple organizations, an attacker who is owner or admin of their own (or a low-value) organization calls the port.update or port.delete tRPC endpoint supplying a victim tenant's portId or applicationId, which the router never validates against the caller's organization. The attacker thereby reads, alters, adds, or deletes the victim's port mappings, disrupting how that tenant's services are exposed. A detailed public technical write-up pinpoints the exact vulnerable code, though no packaged exploit is referenced in the input.