IBM i CVE-2026-18250

Exploitation requires a valid IBM i user account with at minimum low-privilege credentials - the CVSS PR:L metric confirms authentication is mandatory and unauthenticated exploitation is not possible. The attacker must have network-level access to the IBM i system (AV:N). The race condition implies that successful exploitation is probabilistic and may require repeated attempts or the ability to generate or observe concurrent system load to reliably win the timing window. No specific non-default configuration is identified as a prerequisite in the available description; the vulnerability appears to affect standard authenticated sessions. Exploitation is limited by the authentication barrier: anonymous or pre-authentication attack paths are not present. The A:L impact in the vendor CVSS is not corroborated by the description and may not apply in all exploitation scenarios.

The vendor-assigned CVSS 6.3 Medium score is grounded in three moderate signals: network reachability, low-privilege authentication requirement, and bounded Low-level impact across confidentiality, integrity, and availability. The AC:L assignment, however, warrants scrutiny - race conditions inherently require an attacker to win a timing window under concurrent load, which often corresponds more accurately to AC:H; this discrepancy should be verified against IBM's advisory detail. EPSS data was not provided in the source intelligence, limiting probabilistic exploitation forecasting. The absence of a CISA KEV entry and lack of any reported public exploit code collectively reduce near-term urgency. That said, the authentication bypass component elevates the real-world concern above what a pure information-disclosure flaw would warrant: any IBM i environment handling regulated data - financial services, insurance, government - should incorporate this into their standard patch cycle without deferral. The A:L impact in the vendor CVSS is not substantiated by the description, which references only information disclosure and security bypass, and may reflect conservative vendor scoring rather than confirmed availability impact.

An attacker holding a low-privilege IBM i account sends concurrent or rapidly repeated requests to a security-sensitive subsystem, attempting to win the race between the system's authorization check and the resource access that follows it. By timing the requests to collide with concurrent legitimate operations, the attacker reads restricted data or causes the security restriction to be bypassed. No public exploit code has been identified at time of analysis, so this scenario currently requires attacker-developed tooling.