IBM Enterprise Quarkus EUVD-2026-74180

The attacker must be able to send HTTP requests to an IBM Enterprise Build of Quarkus application endpoint in versions 3.27.1-3.27.5 or 3.33.1-3.33.3 that resolves a resource using a user-controlled URL query parameter as a key. The CVSS PR:N indicates no authentication credential is required, but the AC:H qualifier implies the attacker must know or enumerate the correct parameter name and valid object keys for unauthorized resources. Exploitation is limited to endpoints where the application fails to re-validate the calling principal's rights against the resolved object; endpoints with no query-parameter-driven authorization logic are not affected. Network-level restrictions (firewalls, API gateways, internal-only deployment) significantly reduce exposure despite the AV:N attack vector.

The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) rates this 7.4 Medium-High. AV:N and PR:N together indicate a remotely accessible, unauthenticated attack surface, which is significant. The AC:H qualifier is the primary risk-reducer: successful exploitation requires the attacker to understand the query parameter structure and craft values that map to unauthorized object keys - not a trivial, spray-and-pray attack. EPSS data is not provided. No CISA KEV listing and no POC code are present in the input, placing this in the 'no public exploit identified' category. The absence of availability impact (A:N) limits the denial-of-service angle. Real-world risk depends heavily on whether affected Quarkus-based endpoints are internet-facing or restricted to internal networks; enterprise Quarkus deployments often sit behind API gateways, which can partially mitigate AV:N exposure. The high integrity impact (I:H) is notable: attackers can not only read but potentially write or overwrite data they should not access.

An attacker sends an HTTP request to a Quarkus application endpoint that accepts a resource identifier (e.g., a user ID, order ID, or document key) via a URL query parameter. By substituting a different object key that belongs to another user or a higher-privilege context, the application performs the operation under the original authorization context without re-validating ownership, granting the attacker read or write access to data they are not authorized to touch. No POC code is publicly available at time of analysis, but the technique is well-understood and straightforward for IDOR-class vulnerabilities once the parameter structure is known.