CVE-2026-109194

Executive Summary

CVE-2026-109194 is an authorization flaw (CWE-639, Authorization Bypass Through User-Controlled Key) in Red Hat Quay's build trigger management API. The API fails to verify that a requested build trigger belongs to the repository the caller is authorized against, allowing any authenticated user with administrative access to any repository to view, modify, or permanently delete build triggers and their associated write tokens belonging to a different repository, provided the attacker knows the victim trigger's UUID. With a CVSS base score of 6.4 and no patch or workaround available, exposure is limited to environments where attacker and victim share a Quay deployment and trigger UUIDs can be obtained.

Technical Analysis

The vulnerability resides in the build trigger management API of Red Hat Quay — the component responsible for creating, listing, updating, and deleting repository build triggers and for issuing the write tokens that allow external systems (for example, source-control webhooks) to initiate builds against a repository. Per the CNA description, the API "fails to verify whether a requested trigger belongs to the specified repository."

This is a textbook instance of CWE-639 (Authorization Bypass Through User-Controlled Key). In CWE-639, an application uses an object identifier supplied by the caller to look up a resource, but performs its authorization decision against a different or insufficiently scoped object — here, the repository path supplied by the caller — rather than against the object the identifier actually resolves to. The security decision is therefore decoupled from the data access. A caller who is legitimately an administrator of repository A passes that authorization check, but the identifier they submit resolves to a trigger owned by repository B. Because the ownership check is missing, the operation proceeds against repository B's object.

Three properties make this exploitable:

1. The key is caller-controlled. The trigger UUID is supplied by the attacker in the request. The attacker is not required to be a member of the victim repository — only an administrator of some repository on the same Quay instance.
2. The object is sensitive. Build triggers are not merely configuration. They carry associated write tokens — credentials that authorize pushing images into the target repository. Reading a trigger can therefore yield a credential; modifying it can repoint build automation; deleting it is destructive and can be paired with token deletion to disable the victim's CI/CD pipeline.
3. The impact is asymmetric. Modify and delete operations against another tenant's pipeline constitute a high-integrity/low-availability impact on the victim, which the CVSS vector reflects via I:H and A:L, while confidentiality is assessed as low (C:L) — consistent with the write token being a narrower-scope secret than a full user credential.

The stated attack complexity is High (AC:H). This is significant and should temper severity expectations: the flaw is not trivially weaponizable at scale. Per the description, exploitation requires knowledge of the victim trigger's UUID, which is not enumerated or discoverable through the vulnerable API itself — it must be obtained out-of-band (leaked logs, shared CI configuration, exposed webhook URLs, screenshots, support tickets, or other information disclosure). This prerequisite is almost certainly what drives the High complexity rating rather than any cryptographic or race-condition requirement.

The privilege requirement is Low (PR:L) — an authenticated account — because administrative rights over any repository on the instance suffice. No user interaction is required (UI:N), and the attack is network-reachable (AV:N). Scope is Unchanged (S:U) — impact remains within the Quay application's security authority.

Note the description does not disclose the specific API endpoint paths, parameter names, or the trigger-identifier field. No such implementation details are asserted here. What can be stated from the description is limited to: build trigger management API, repository scoping, trigger UUID as the key, and write tokens as a linked asset.

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template exists for this CVE. The attack chain below is inferred strictly from the vulnerability class (CWE-639) and the factual elements stated in the NVD description. No endpoint paths, parameter names, or function names are invented.

1) Reconnaissance and target identification. The attacker requires two things: authenticated access to a Red Hat Quay instance with administrative rights over at least one repository, and the UUID of a build trigger belonging to a repository they do not control. The latter is the pacing item. The attacker enumerates the Quay deployment (typically reachable over HTTPS on standard container-registry ports), obtains a low-privileged or repository-admin account through normal onboarding, self-registration where enabled, or a compromised developer credential, and then hunts for leaked trigger UUIDs. Realistic sources include CI/CD configuration committed to source control, webhook URLs containing the trigger identifier, build logs, container image labels or annotations, public issue trackers, and API responses cached by intermediaries.

2) Triggering the flaw. With a victim trigger UUID in hand, the attacker issues requests to the build trigger management API while authenticated as an administrator of a different, attacker-controlled repository. The API authorizes the caller against the repository the caller claims or the repository context supplied in the request, but resolves the operation against the object named by the caller-supplied UUID. Because the missing check is precisely "does this trigger belong to this repository," the operation is permitted. This is the CWE-639 pattern applied at the object-authorization layer: the authorization subject and the data subject are allowed to diverge.

3) Action at the vulnerability-class level. The description states three distinct operations are reachable: view, modify, and permanently delete the target trigger and its associated write tokens. Viewing discloses trigger configuration and the linked write-token material. Modifying permits the attacker to alter trigger behavior — plausibly including the destination or parameters of the build automation — which converts a read primitive into a supply-chain positioning primitive. Deleting removes the trigger and its write token, severing the victim repository's automated build/push path and, if the token is the only credential in use, halting image publication.

4) Post-exploitation impact. The highest-value outcome is not the deletion but the write token. A write token captured from a victim trigger is a pushing credential for the victim repository. In a container registry, push access is equivalent to artifact-integrity control: the attacker can publish attacker-controlled images under the victim's namespace, overwriting or shadowing trusted tags. Any downstream consumer — Kubernetes clusters, CI pipelines, deployment automation — that pulls those tags by name or by mutable tag executes attacker-supplied content. This makes CVE-2026-109194 a potential supply-chain pivot rather than a simple cross-tenant configuration bug, despite the moderate CVSS score. The destructive delete path additionally provides a denial-of-service capability against the victim's build pipeline and, if unrecoverable, an integrity and recovery burden.

Because the attacker need not know the victim repository's full identity — only a trigger UUID — the flaw also collapses a presumed tenant boundary within a shared Quay instance. Multi-tenant registries, shared platform instances, and managed Quay services carry the broadest blast radius.

Impact Assessment

The CVSS 3.1 base score of 6.4 (Medium) derives from vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L:

• AV:N — the API is network-accessible; no local access required.
• AC:H — exploitation depends on prior knowledge of the victim trigger's UUID, which is not obtainable from the vulnerable API itself.
• PR:L — any authenticated user with repository-administrative rights qualifies; no instance-wide administrator role is needed.
• UI:N — no victim interaction.
• S:U — impact is confined to the Quay application's authorization scope.
• C:L — confidentiality impact is limited primarily to trigger configuration and write-token material.
• I:H — the dominant term: an attacker can modify another tenant's build configuration and, via captured write tokens, publish unauthorized artifacts to the victim repository, directly tampering with build outputs.
• A:L — permanent deletion of triggers and tokens degrades or halts the victim's build automation.

Business impact centers on three axes: tenant isolation failure (a shared Quay instance no longer guarantees that repository-administrative rights are confined to the repositories a user owns), artifact integrity (write tokens compromise the trustworthiness of published images, propagating downstream), and CI/CD availability (destructive deletion of triggers and tokens). Because the write-token theft path can lead to malicious image publication, downstream systems that consume images from the affected registry should be treated as potentially in scope for follow-on investigation, even though the CVSS vector itself models the immediate CVE impact as Medium. There is no evidence of exploitation in the wild, no CISA KEV listing, and no EPSS score reported by FIRST.org at the time of writing.

Detection Guidance

Sigma Rule

title: Red Hat Quay Build Trigger Cross-Repository Access Attempt (CVE-2026-109194)
id: 8e2f6a3c-4b71-4d90-9c1e-7a5f2d6b0e42
status: experimental
description: Detects access, modification, or deletion of build triggers against a repository
  other than the caller's own, consistent with CWE-639 authorization bypass in Red Hat Quay's
  build trigger management API.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-109194
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1190
logsource:
  product: redhat_quay
  service: api
detection:
  selection_method:
    http_method:
      - GET
      - PUT
      - PATCH
      - DELETE
  selection_path:
    http_url|contains:
      - '/trigger'
  selection_anomaly:
    - 'repo_owner != caller_org'
    - 'trigger_repo != request_repo'
    - 'status: "403"'
  condition: selection_method and selection_path and not selection_anomaly
falsepositives:
  - Legitimate administrator operations within a single repository
level: medium

YARA Rule

rule CVE_2026_109194_Quay_Trigger_Authz_Bypass_Artifacts
{
    meta:
        description = "Detects log or configuration artifacts referencing Quay build trigger UUIDs accessed cross-repository, consistent with CVE-2026-109194"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-109194"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $t1 = "build trigger" ascii nocase
        $t2 = "trigger_uuid" ascii nocase
        $t3 = "write token" ascii nocase
        $quay = "quay" ascii nocase

    condition:
        uint32(0) != 0xDEADBEEF and
        $quay and
        1 of ($t1, $t2) and
        $t3
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-109194 Red Hat Quay Build Trigger Cross-Repository Access Attempt"; flow:established,to_server; http.method; content:"DELETE"; http.uri; content:"trigger"; http.uri; content:"uuid"; reference:cve,CVE-2026-109194; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-109194; classtype:attempted-user; sid:2026109194; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.outcome == "success" ]
  [ http where http.request.method in ("GET","PUT","PATCH","DELETE")
      and url.path : "*trigger*"
      and http.response.status_code in (200, 204) ]
  [ http where http.response.status_code == 403 and url.path : "*trigger*" ]

Splunk SPL Query

index=quay sourcetype=quay:api
| where match(http_method, "^(GET|PUT|PATCH|DELETE)$") and match(uri_path, "trigger")
| eval cross_repo=if(repo_namespace!=authenticated_org, 1, 0)
| stats count values(trigger_uuid) as trigger_uuids values(repo_namespace) as victim_repos by authenticated_user, cross_repo
| where cross_repo=1
| sort - count

Wazuh OSSEC Rule

<group name="redhat_quay,cve-2026-109194,">
  <rule id="2026109" level="8">
    <decoded_as>json</decoded_as>
    <field name="http_method">GET|PUT|PATCH|DELETE</field>
    <match>trigger</match>
    <field name="http_status">200|204</field>
    <description>CVE-2026-109194: Possible Red Hat Quay build trigger cross-repository authorization bypass</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>access_control,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No vendor fix, workaround, or affected-version range has been published by any tracked source. The mitigations below are defensive engineering measures, not vendor-provided fixes.

1) Immediate mitigations

• Enforce object-level authorization at the network edge or API gateway where possible: reject build-trigger API requests whose target object is not demonstrably within the caller's authorized repository namespace. This is a stopgap that requires maintaining a mapping of trigger UUIDs to owning repositories.
• Audit and rotate. Enumerate all build triggers and their associated write tokens across the instance. Treat as compromised any trigger whose write token may have been exposed via shared logs, committed CI configuration, or public webhook URLs. Rotate those tokens and invalidate the associated triggers where feasible.
• Minimize the population of repository administrators. Every repository administrator is a potential exploitation principal for this flaw. Reduce repository-admin grants to the minimum required, and prefer scoped robot accounts over human repository-admin roles.
• Restrict retrieval of trigger UUIDs. Remove trigger identifiers from build logs, image labels, CI configuration committed to source control, and public webhook listings. UUID secrecy is, per the CVSS AC:H rating, the principal control currently limiting exploitability.
• Network segmentation. Restrict access to the Quay API to trusted client networks and CI runners; do not expose the registry API more broadly than necessary.

2) Patch/upgrade steps

• There is currently no patch to apply. Monitor the Red Hat Quay security advisories and the NVD entry for CVE-2026-109194 for a fixed release.
• When a fix is published, validate in a staging deployment that the build trigger management API rejects operations on triggers owned by repositories the caller is not authorized against, and that the ownership check is performed on the resolved object rather than on caller-supplied repository context.
• Because no affected version range is published, plan to upgrade all deployment channels — including any embedded or downstream distributions of Quay — once the fix is identified, and track the version in your SBOM.

3) Long-term hardening

• Adopt object-level authorization as a code invariant. Every API operation that accepts a caller-supplied object identifier must re-derive the owning tenant from that identifier and authorize against the derived owner, never against a caller-supplied namespace. This is the direct remediation for CWE-639 and prevents the entire class of cross-tenant identifier attacks.
• Automated cross-tenant authorization regression tests. Add test cases that authenticate as an administrator of repository A and attempt to read, modify, and delete objects belonging to repository B using valid object identifiers. These tests should run in CI and block merges that regress tenant isolation.
• Treat write tokens as high-value secrets. Apply short expiration, least-privilege scoping, automatic rotation, and anomaly alerting on pushes performed by tokens that have not pushed recently or that originate from unusual source networks.
• Promote registry audit log review to the SOC. Correlate trigger-mode operations against the authenticated caller's repository namespace. A repository administrator acting on an object outside their namespace is the single highest-fidelity signal for this vulnerability.
• Reduce reliance on mutable image tags. Pin downstream deployments to immutable digests so that a stolen write token cannot silently redirect a deployment by shadowing a tag.

References

• NVD — CVE-2026-109194: https://nvd.nist.gov/vuln/detail/CVE-2026-109194
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• Red Hat Security Advisories (vendor advocacy and patch tracking): https://access.redhat.com/security/
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• FIRST.org EPSS (no score currently published for this CVE): https://www.first.org/epss/

Threat actor and exploit-in-the-wild note: no public proof-of-concept, no exploit code, no Nuclei template, and no CISA KEV listing are associated with CVE-2026-109194 at the time of writing. No threat actor campaign has been attributed. The absence of PoC material is consistent with the high attack complexity and the requirement for out-of-band knowledge of a victim trigger UUID.