Jacamar CI EUVD-2026-95036

Requires an authenticated CI user with at least low-privilege access to a Jacamar CI runner on an affected release (prior to v0.30.0) that provisions jobs under service accounts. Exploitation depends on the service-account job-validation code path being in use; the flaw lets such a user generate arbitrary account names to impersonate other accounts. Limiting factors: the attacker must already hold valid CI credentials (PR:L), the target must run Jacamar CI below v0.30.0 with service-account provisioning, and the published vector additionally claims required user interaction (UI:R) and adjacent-network access (AV:A) - both constrain reach if accurate, though they appear inconsistent with the described self-submitted-job vector.

Signals are mixed and point to a moderate, not urgent, priority. The published CVSS 3.1 base score is 7.5 with vector AV:A/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:L, indicating adjacent-network access, low attacker privileges, and a scope change, but it also requires user interaction. CWE-290 (authentication bypass by spoofing) plus the description ('generate arbitrary account names' for service accounts) frames this as an account-impersonation/privilege-escalation flaw in Jacamar CI, a GitLab CI custom executor for HPC schedulers. No EPSS score, no CISA KEV listing, and no public POC were provided, so the exploitation signal is weak: no public exploit identified at time of analysis. The CVSS vector is internally inconsistent with the description - the description implies an authenticated CI user triggering their own job (which argues for AV:N and UI:N, not AV:A/UI:R) - so the input vector should be verified with the vendor (GitLab ECP-CI). Net: a credible integrity/authorization weakness worth patching to v0.30.0 on affected HPC CI deployments, but the narrow deployment footprint and absence of exploitation evidence make it a routine-patch rather than drop-everything item.

An authenticated low-privilege CI user submits a crafted job to a Jacamar CI runner (prior to v0.30.0) on an HPC cluster. Due to insufficient job validation for service accounts, the job is mapped to an arbitrary account name of the attacker's choosing, letting them impersonate another user's or service account's execution context. No public exploit code is known at the time of analysis.