OliveTin EUVD-2026-50563

OliveTin must be deployed with OAuth2 authentication configured, because the vulnerable handler is the OAuth2 login endpoint (/oauth/login) in restapi_auth_oauth2.go - instances using other authentication methods do not expose this code path. When OAuth2 is enabled there are no further prerequisites: the endpoint is reachable pre-authentication (PR:N), needs no user interaction (UI:N), and works against default OAuth2 configurations, so any attacker able to send HTTP requests to the server can trigger it. The primary limiting factor is therefore configuration-dependence (OAuth2 must be in use) plus network reachability of the instance; there is no version-specific or platform-specific constraint beyond running an affected release (3000.0.0-3000.16.x).

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, score 7.5) indicates a network-reachable, low-complexity, unauthenticated attack with high availability impact and no confidentiality or integrity impact - consistent with a pure DoS. The description supports this vector cleanly: the /oauth/login endpoint is pre-authentication by design, so PR:N is justified. There is one important qualifier the raw vector does not capture: the vulnerable code path only exists when OAuth2 authentication is actually configured, so environments using other auth backends are not exposed. No EPSS score was supplied and the CVE is not listed in CISA KEV, so there is no evidence of active exploitation; the referenced GitHub commit is the vendor fix, not exploit code, so this should not be conflated with public POC availability. Overall this is a real but bounded risk - easy to trigger and impactful for availability, but limited to OAuth2-enabled deployments of a niche product, so it is a patch-soon issue rather than an emergency for most environments.

An attacker who can reach an internet-exposed OliveTin instance with OAuth2 enabled scripts a loop that repeatedly requests /oauth/login?provider=..., each request permanently adding a state entry to server memory. After enough requests the OliveTin process exhausts available memory and is killed or becomes unresponsive, denying access to all legitimate users and their configured commands. No authentication, user interaction, or special tooling is required, though no public exploit is identified at time of analysis.