Eclipse Jetty CVE-2026-19864

Exploitation requires a specific deployment: Jetty must be configured to persist sessions to a SessionDataStore (e.g., JDBC, file, or cache-backed session persistence), authentication must be in use such that a SessionAuthentication object holds credentials containing a plaintext password, and the attacker must already hold sufficient privileges to read the persisted session data (database access, filesystem/backup access, or cache access). Limiting factors: this is local/privileged access only (AV:L, PR:H), there is no network vector and no user interaction, exploitation is impossible against deployments that do not persist sessions (the common in-memory default) or that do not retain plaintext passwords in the credential object, and impact is confined to disclosure of credentials with no integrity or availability effect.

This is a genuine but modest-priority issue, not a high-urgency flaw. The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:H/UI:N, VC:H) scores 5.6 (Medium) and the signals are internally consistent: exploitation is local (AV:L), requires high privileges (PR:H), and carries an attack requirement (AT:P) that reflects a non-default precondition - sessions must actually be persisted to a session data store and must contain plaintext-password credentials. Impact is confidentiality-only (VC:H, VI:N, VA:N). No EPSS score, KEV listing, or POC was provided in the input, so the real-world exploitation signal is: no public exploit identified at time of analysis. This is fundamentally a defense-in-depth / cleartext-storage weakness (CWE-312) rather than a remotely weaponizable vulnerability - an attacker must already possess sufficient privileges to read the persisted session store, which typically means they have substantial access to the backing database, filesystem, or cache. The practical value is post-compromise credential harvesting and lateral movement (plaintext passwords reused elsewhere), not initial access. Net: real and worth patching, but low likelihood of mass exploitation and dependent on a specific deployment configuration.

An application runs Jetty with session persistence enabled (e.g., JDBC or file-based SessionDataStore) and uses form/basic authentication that stores plaintext passwords in the SessionAuthentication object. An attacker who already has read access to the backing session store - such as a DBA, a compromised service account, or someone who obtained a backup of the session data - deserializes or inspects the stored session and recovers authenticated users' plaintext passwords, which can then be reused against other systems. No public exploit code was identified in the provided data.