Ship Property Management System CVE-2025-9210

The attacker must hold a valid, authenticated user account in the Ship Property Management System - unauthenticated exploitation is not possible given PR:L in the CVSS vector. No special system configuration or non-default feature is required beyond the application's standard JWT-based session management, which appears to be the default authentication mechanism. The limiting factors are: (1) possession of any valid credential, (2) network access to the application endpoint, and (3) awareness of the vulnerability to know which JWT claims to modify. There is no user interaction required from a victim, and the attack complexity is low once credentials are obtained.

The CVSS 8.1 score reflects a genuinely serious flaw: network-reachable (AV:N), low complexity (AC:L), no user interaction required (UI:N), and high impact on both confidentiality and integrity (C:H/I:H). The principal limiting factor is PR:L - an attacker must first hold a valid user account, which reduces the attack surface compared to a fully unauthenticated flaw. No EPSS data was provided, and the absence of a KEV listing suggests exploitation has not been observed at scale. However, the simplicity of JWT tampering - requiring only a browser developer console or HTTP proxy - means the technical barrier is extremely low for any authenticated user who is aware of the flaw. The maritime software sector often operates with shared credentials or broad account provisioning, which could make the PR:L prerequisite easier to satisfy than in other contexts. Overall this is a real, high-priority remediation target rather than a theoretical risk inflated by CVSS scoring.

An attacker with a standard user account logs in, captures the issued JWT using browser developer tools or an intercepting proxy such as Burp Suite, and decodes the base64url payload to reveal role or permission claims. The attacker modifies the claim (e.g., changing 'role':'viewer' to 'role':'admin'), re-encodes the payload, and substitutes it into subsequent requests - the server accepts the forged token without signature verification and grants administrative access. No public proof-of-concept code has been identified, but the technique is well-documented and requires no specialized tooling.