CVE-2026-18235 is an authenticated command injection in IBM i's Control Language (CL) subsystem, scoring CVSS 8.3 with EPSS 0.00304. The severity is warranted — successful exploitation grants arbitrary CL execution, which on IBM i means full access to the object's permission model that constitutes the platform's primary security boundary. There is no secondary containment layer below it.
This is not an isolated validation failure. IBM i has exhibited a multi-decade lineage of authenticated CL injection vulnerabilities across diverse entry points — web APIs, modified services, refactored handlers. The pattern is genetic, not coincidental. The platform's architectural assumption that 'authenticated' constitutes a sufficient trust boundary creates a structural attractor for this vulnerability class. Developers operating inside that model perceive defense-in-depth at every CL entry point as unnecessary cognitive overhead. The architecture doesn't merely permit this oversight; it actively rewards it.
Compounding this is a remediation dynamic that reinforces the vulnerability rather than eliminating it. Each patch targets a specific entry point while leaving the underlying trust model intact, teaching developers that intervention at the architectural level wasn't necessary. When one vector closes, exploitation migrates to the next available path — not because attackers are exceptionally clever, but because the underlying model guarantees another path exists. This is vector succession, not recurrence.
The blast radius extends further in modern deployments. Contemporary IBM i systems integrate with web applications, REST APIs, and hybrid environments that extend far beyond the original green-screen trust model. A vulnerability that once required terminal access now potentially spans from an API endpoint to complete system compromise.
Your remediation priorities: audit all CL program entry points exposed through web interfaces, REST APIs, or any modern integration layer — these are the paths least likely to have received input validation. Assume legacy CL programs exist that were written for long-deprecated workflows but remain executable and unaudited. The question to pose to your IBM i team isn't 'what changed recently' but 'what CL programs exist that we forgot were there.' Deprecated does not mean unreachable.