CVE-2026-123710: Red Hat Quay Token Forgery and Fixes

CVE-2026-123710 affects the trust used to authorize access to Red Hat Quay container images. Red Hat describes an unauthenticated signing-key takeover when the key-management endpoint is reachable by untrusted clients. A registry token is accepted for a purpose it should not authorize, allowing an attacker-controlled key to become trusted. The vendor rates the issue Critical at 9.8. See Red Hat’s CVE advisory.

The recovery problem is therefore different from resetting a compromised user’s password. A registry must decide which keys it trusts, which software is running, and whether images or downstream consumers were affected. Those are separate evidence requirements. A successful login after maintenance leaves signing-key legitimacy unresolved. An image scanner can assess package vulnerabilities while leaving publisher provenance unresolved.

This analysis uses the public vendor guidance available on November 13, 2026, and proposes a defensive response method. It does not claim to reproduce the Quay exploit, inspect a customer registry, or establish active exploitation in an environment. The educational example is an in-memory authorization model with no registry traffic and no real signing keys.

Why a valid registry token must not authorize key management

Cryptographic validity answers whether a token was signed by a key the verifier accepts and whether the relevant validation checks passed. Authorization answers whether that credential is permitted to perform the requested operation. These decisions can be implemented in nearby code and still protect very different authority. A token intended for repository access should not automatically authorize changing the keys trusted by the registry.

In the vendor-described mechanism, the key-rotation path checks the signature, audience, and issuer without establishing that the token is a rotation credential. The resulting trust change can support tokens accepted for repository reads and writes. This is a purpose-validation failure, not evidence that the underlying signing algorithm has been broken.

That distinction determines the response. Replacing a user’s credential addresses the authority attached to that user. Removing an unauthorized signing key addresses a different trust relationship. Updating the verifier addresses the defect that permitted the relationship to be created. A response that completes only one of those tasks may leave another part of the problem unresolved.

について CNCF Distribution token authentication specification describes a normal registry flow in which a client obtains a token representing authorized repository access and presents it to the registry. The specification provides useful context for the separation between issuing credentials and consuming them. It is not evidence that every registry implementation shares this Quay vulnerability.

For design review, distinguish the component that issues a token, the component that validates it, the policy that grants repository operations, and the authority that changes trusted keys. Write down the expected credential class at each boundary. If the same issuer supports multiple classes, each consumer needs a rule that rejects credentials intended for the other classes.

The diagram below shows that conceptual separation and the impact described by the vendor. The downstream-image branch is an investigation concern, not a statement that an image was altered in a particular registry. No request sequence, exploit payload, or production key-registration procedure is included.

Establish the affected deployment and the relevant fixed build

Start with the deployment you operate, not the product name in a scanner result. Identify whether it is standalone Quay, an Operator-managed deployment, or a mirror registry, then record the exact running images and the applicable product branch. Red Hat’s public remediation article includes these deployment forms in its environment scope.

Two fixed-build examples can be verified directly from the vendor errata reviewed for this article: RHSA-2026:99025 identifies Quay 3.10.28そして RHSA-2026:99026 identifies Quay 3.17.7. Both list CVE-2026-123710. These are branch-specific examples, not a claim that every other branch shares the same minimum version or that every Quay 5 deployment is corrected.

Observed deployment	Evidence required	Safe interpretation
Quay 3.10 branch	Applicable erratum and running image identity	Compare with the verified 3.10.28 advisory and current vendor guidance
Quay 3.17 branch	Applicable erratum and running image identity	Compare with the verified 3.17.7 advisory and current vendor guidance
Another branch or Quay 5	Current branch-specific vendor correction	Do not infer a fixed version from these examples
Operator-managed registry	Desired configuration and actual running components	An update request alone does not establish rollout completion
Mirror or internal registry	Deployment identity and access paths	Internal placement alone does not resolve trust exposure

Record the image digest as well as the human-readable release. A deployment may specify a desired image while an old instance continues to serve traffic. A cached status page may describe the last successful rollout rather than every running component. The acceptance record should connect the deployed instance to the security correction, with the observation time and the person responsible for checking it.

When vendor product tables and individual errata have different presentation or update timing, do not fill the gap with arithmetic. Use the exact security advisory for the branch and ask support to resolve ambiguity. A later-looking version string is not a substitute for a documented correction when packaging, backports, or multiple product lines are involved.

Maintain a list of unresolved instances. A registry used only during disaster recovery may be absent from routine monitoring but become trusted by production systems during an emergency. A staging registry can publish base images consumed by production builds. Include these dependencies according to their actual role rather than the label attached to the environment.

Map every path to the registry key service

The relevant access condition concerns untrusted clients reaching the key-management service. Red Hat’s advisory recommends restricting the /keys endpoint to trusted internal components at the proxy or load balancer. It also names service-key rotation and deletion events for review. Use the current vendor mitigation as the authority for the endpoint and event names.

Build a route inventory before assuming that one edge rule covers the deployment. Include public ingress, internal ingress, alternate hostnames, administrative routes, direct backend access, and any secondary load-balancer path actually configured. These are review categories, not a claim that Quay creates every path by default. The owner should identify which ones exist in the specific environment.

For each path, record the source population allowed to use it and the component that enforces that decision. A private network can include developers, build agents, customer workloads, or compromised machines that should not administer registry trust. Define trusted internal components narrowly enough to describe a real allow decision, rather than equating every internal address with key-management authority.

Check policy at the enforcement point that receives the request. A rule on one proxy says little about traffic that bypasses it. A change to a template says little about an existing deployment until the rendered configuration and active route are verified. Keep the intended policy, effective policy, and validation observation as linked records.

Plan a functional check for legitimate components before applying a restriction. A broad denial may interrupt a required internal workflow. The objective is to protect the management boundary while preserving explicitly authorized use. Have the registry owner confirm the dependent components and the method for diagnosing failures, rather than reopening the endpoint to every client when an unexpected error appears.

A route review does not require installing a signing key or sending a real exploit. Configuration inspection and a narrowly scoped, non-mutating access check can establish many exposure conditions. Agree on the method with the owner and retain the result. Where an application response is ambiguous, keep the exposure question open until the routing and enforcement evidence resolve it.

Contain access and preserve the trust-store evidence

Do not begin by deleting every unfamiliar key. First establish who owns the registry, who can interpret its key inventory, and where evidence will be retained. A legitimate key may have an unexpected name because of an old rollout or an undocumented component. An unauthorized key may have an ordinary-looking name. The decision needs provenance and context rather than appearance alone.

Use the supported administrative and incident procedures to preserve the current key state and relevant records. Record identifiers, observed metadata, collection time, and the baseline used for comparison. Keep sensitive material in the approved evidence location. A working report can reference those artifacts without distributing private keys, tokens, or diagnostic exports to everyone involved in status reporting.

Restrict the vulnerable path and deploy the appropriate correction as coordinated actions. The ordering should account for ongoing activity, service dependencies, and the evidence that may change during maintenance. If a threat is active, immediate containment may take precedence over complete collection. Record the reason and the resulting evidence limit rather than presenting the later investigation as if nothing was lost.

Red Hat warns that an unauthorized signing key can survive a restart and that ordinary password or robot-token changes do not revoke it. The vendor’s remediation guidance also explains why disabling anonymous access is not a complete fix. These facts make key-trust review a required part of the response plan rather than an optional follow-up to a password reset.

Assign separate owners to the software rollout, key review, repository-integrity review, and consumer assessment. One team may perform several tasks, but the evidence should still answer each question. A deployment engineer can verify a corrected image without being the person authorized to determine whether a particular signing key is legitimate.

Keep the registry available only to the extent consistent with the incident decision. A service owner may choose temporary restrictions on publishing or other workflows while image integrity is investigated. Such choices depend on the actual exposure and business role; they are not presented here as universal vendor instructions. Document the scope, duration, and acceptance condition for every temporary restriction.

Investigate service-key activity with provenance and context

An event name is a starting point for a search, not a conclusion. Preserve the original record, identify the event source and schema, and relate it to the key inventory. Compare the observation with approved maintenance and component activity. A rotation event can be legitimate; a lack of a recognizable human identity may require interpretation of the deployment’s service identities.

Build a timeline that links key changes, access-path changes, registry activity, and software rollout. Retain original timestamps and normalize a working copy for correlation. If the relevant systems have different clock settings or collection delays, describe the uncertainty. A key created just before an image change may be relevant, but temporal proximity alone does not establish that the events share a cause.

Quay’s usage-log documentation describes UI, API, and export access to repository and namespace activity. Use a collection route suited to the needed interval and volume. A page of recent UI results is not automatically a complete history, and a collection account may not have visibility into every namespace included in the incident.

Distinguish missing data from a negative result. If a log was never collected, expired, or cannot be accessed by the analyst, record that limitation. If a query completed against a known source and interval, record what it found. This difference is decisive when a response owner must decide whether the evidence supports closure or whether further investigation is needed.

Classify keys using a defensible ownership record. An approved key should have a known component or process that explains its presence and lifecycle. A candidate unauthorized key needs a recorded investigation result and a supported removal decision. Avoid publishing a universal deletion script: the public guidance does not establish that every deployment exposes the same administrative tooling or that every unexpected row is malicious.

Review ordinary registry failures in the same timeline. The vendor’s public guidance notes that interference with legitimate keys can affect pushes and pulls. An authentication error could therefore be an incident clue, a maintenance effect, or an unrelated configuration problem. Determine which explanation fits the key state and deployment events before resetting credentials repeatedly.

Understand what token-purpose separation should enforce

RFC 8725 recommends explicit token typing where appropriate and mutually exclusive validation rules for different kinds of JWTs. The design goal is to prevent a credential accepted in one context from being substituted into another. A valid signature is necessary for many token systems, but it does not eliminate the need to validate the intended use.

For a system you own, define each credential class before writing shared verification helpers. Describe who may issue it, who consumes it, which operation it authorizes, its lifetime, and its relationship to other credentials. Then review whether a lower-authority credential can satisfy the higher-authority consumer’s checks. This is a general engineering method, not a description of every line of Quay’s implementation.

Prefer a design in which the consumer can make the authorization decision from trusted context and a validated credential profile. Do not treat an attacker-controlled claim as authority merely because it appears in a signed object. The issuer’s rules, the claim’s meaning, and the consumer’s policy must agree. Where several consumers share an issuer, test the rejection rules between their credential classes.

Test whether a credential valid for one operation is rejected by a consumer requiring another authority. Positive tests alone can establish that a permitted workflow succeeds while missing substitution between workflows. Record why a credential was rejected and confirm that a legitimate credential still works under the supported validation path. This produces evidence about the intended boundary rather than a superficial response-code comparison.

Keep design review separate from incident remediation. A general lesson about token classes can guide future engineering, but production Quay recovery must follow the vendor correction and supported key-remediation process. Do not replace a released security fix with a locally invented token rule simply because it appears to address the same concept.

A safe in-memory demonstration of the authorization boundary

This toy program models a consumer that must distinguish repository access from a higher-authority administrative operation. It contains no JWT library, real keys, Quay endpoints, network listener, or registry calls. The fields are trusted test fixtures, not a recipe for constructing a production token. The example demonstrates a policy decision without implementing the real vulnerability.

from dataclasses import dataclass

@dataclass(frozen=True)
class Credential:
    signature_valid: bool
    issuer: str
    audience: str
    purpose: str
    permissions: frozenset

def weak_check(credential):
    return (
        credential.signature_valid
        and credential.issuer == "demo-issuer"
        and credential.audience == "demo-service"
    )

def administrative_check(credential):
    return (
        weak_check(credential)
        and credential.purpose == "administrative-demo"
        and "trust.manage" in credential.permissions
    )

reader = Credential(
    True, "demo-issuer", "demo-service", "repository-demo",
    frozenset({"image.read"})
)
administrator = Credential(
    True, "demo-issuer", "demo-service", "administrative-demo",
    frozenset({"trust.manage"})
)

assert weak_check(reader) is True
assert administrative_check(reader) is False
assert administrative_check(administrator) is True
print("Toy purpose boundary checked; no registry contacted.")

The first assertion shows why a common cryptographic wrapper can be insufficient for an administrative decision. The second shows the lower-authority fixture being rejected. The final assertion checks that the illustrative authorized case remains possible. The program does not prove that adding these exact fields is a sufficient production defense; a real implementation must validate its credential profile and trusted context correctly.

A useful extension for an internal engineering exercise is to write a matrix of credential classes and operations, then identify every combination that must be denied. Keep the matrix independent of implementation details so it expresses the security requirement. Reviewers can then compare the application’s actual checks and tests with the requirement, including unknown types and omitted mandatory fields.

Do not extend the exercise by replaying credentials against a production registry or registering a test key in a live trust store. Those actions have materially different effects. A supported administrative inspection and vendor-prescribed verification are the appropriate starting points for a real response. Any deeper product testing belongs in an isolated, explicitly authorized environment with a recovery plan.

Distinguish image vulnerabilities from image integrity

A scanner can identify known vulnerable software inside an image while missing whether an unauthorized actor replaced that image. Conversely, a trustworthy image can contain an unpatched dependency. These findings belong to different control objectives. Registry recovery needs an integrity and provenance review in addition to the organization’s normal vulnerability-management workflow.

Kubernetes’ container-image documentation distinguishes tags from digests and describes image-pull behavior. A digest identifies particular image content, whereas a tag can be updated to point elsewhere. That makes digest history useful during an investigation, but a digest alone does not establish who approved or built the content it identifies.

Build an expected-image record from an appropriately trusted source: an approved release artifact, a preserved build record, or another reference whose integrity can be established. Compare the image actually consumed with that reference. If both the registry and the record used as the baseline could have been modified through the same incident, the comparison may not provide independent assurance.

For a multi-platform image, identify the level of the reference being compared. A deployment may refer to an index that resolves to a platform-specific manifest. Preserve enough context to connect the expected release, the selected platform, and the content that ran. Avoid declaring a mismatch malicious before confirming that the compared references describe the same platform and release artifact.

Image signatures and attestations can add provenance evidence when the verification policy and trusted signer are appropriate. They do not automatically answer every incident question. Ask what was signed, which identity was trusted, when the record was produced, and whether the verification occurred at the point that matters. A signature made by an already untrusted authority cannot restore confidence merely because its cryptographic verification succeeds.

The operational question is concrete: which repositories changed, which references were consumed, and which workloads used them during the relevant interval? Answering it requires release and runtime evidence, not only a snapshot of the current registry. If a tag has already been corrected, preserve its earlier history where available rather than treating today’s resolution as the whole story.

Trace published artifacts through CI, mirrors, and caches

Start with the publication path. Identify which build systems push images, which accounts they use, which repositories receive the result, and how a release is promoted. A registry can sit between a development pipeline and many consumers. Map the actual path rather than assuming that the primary production cluster is the only system that matters.

Then map replication and caching. A mirror may copy an image before a tag is corrected at the origin. A deployment may use a locally cached image without making a new registry request at the time of a restart. These are reasons to inspect consumer behavior and retained records; they are not evidence that a particular cache contains malicious content. The investigation should identify actual content and timing.

For each candidate affected image, record the repository, tag, digest, publication interval, expected publisher, and known consumers. Add the evidence source and its coverage limits. If the pipeline stores only a tag name, the absence of a digest in its logs is a visibility gap. Seek another source rather than inventing an exact content identity from the release label.

Review automated promotion rules. A trusted registry namespace may cause images to move into another environment without a separate human approval. The recovery team should understand whether an unauthorized image could have followed that approved automation. Follow the configured path and the evidence of actual events; do not infer a complete supply-chain compromise solely from the registry’s potential authority.

Coordinate repository restrictions with build owners. Temporarily pausing a release can prevent uncertainty from propagating while the image history is assessed, but it also has a business consequence. Define who can authorize the pause and what evidence permits publication to resume. A broad restriction without a recovery criterion tends to become either permanent friction or an undocumented exception.

When a clean replacement image is built, retain the connection between the source revision, build environment, output digest, and approval. Rebuilding from the same source in an unreviewed pipeline may reproduce an unauthorized dependency or credential exposure. The response should establish why the replacement path is trusted, not merely that it produced a different digest.

Preserve the approval identity separately from the account that uploads the artifact. A shared publishing account can explain the technical write while leaving the human or automated release decision unclear. Linking both records helps an investigator distinguish an authorized rebuild from an unexplained replacement, especially when many projects publish through the same integration and use similar tag names.

Review secrets inside images and the authority they provide

Unauthorized read access creates a question about the information present in the images that could have been retrieved. Inventory relevant image contents and build practices using approved inspection methods. Look for embedded credentials, configuration values, internal endpoints, and other sensitive material according to the organization’s policy. Do not assume either that every image contains a secret or that a private repository contains nothing sensitive.

Prioritize secrets by authority and evidence of exposure. A credential with broad production access deserves different handling from a revoked demonstration value. Record its issuer, owner, privilege, lifetime, reuse, and dependent services. The response decision should explain why it was rotated, disabled, or retained, with the evidence supporting that choice.

Rotate through a trusted path. If the same affected pipeline builds a replacement image containing a new long-lived credential, the response may recreate the storage pattern that made the original exposure consequential. Coordinate with the secret owner on the supported mechanism for removing the secret from the image and supplying it at runtime where appropriate for the environment.

Separate a secret’s presence from evidence of its use. Image access records can help establish what was retrievable, while identity-provider or service logs can help investigate later credential activity. Neither source necessarily supplies the full history. State the interval and limitations of the review, and avoid describing a potential credential exposure as confirmed misuse without the supporting event.

Plan the service impact of revocation. A credential can be stored in several images, jobs, or environments. Changing it without identifying legitimate consumers may cause avoidable failures. The security objective remains revocation of the compromised authority; the operational plan should make that change durable and verify that authorized workloads receive the replacement correctly.

Use the incident record to improve build hygiene after urgent response work. Document the concrete storage or publication path that created the risk and the control that will change it. A broad instruction to avoid secrets is less useful than a specific owner, an identified pipeline step, and an acceptance test showing that future artifacts omit the material.

Validate recovery without mutating production trust

Define recovery assertions before choosing tools. One assertion concerns access to the key-management boundary. Another concerns the running corrected software. Another concerns the legitimacy of approved signing keys. Further assertions concern image integrity, credential exposure, and downstream use. A single successful pull cannot establish all of them.

Assertion	Evidence to collect	Insufficient shortcut
Untrusted key-service access restricted	Effective ingress policy and approved non-mutating verification	One proxy configuration file
Corrected software running	Applicable erratum and observed running image identity	Desired deployment tag
Signing trust reviewed	Key inventory, provenance, and supported remediation result	Passwords changed
Image history assessed	Trusted reference compared with relevant published content	No known package CVEs
Consumers assessed	Actual image references and deployment interval	The current tag looks correct

For access validation, use the owner-approved method and distinguish denial at the intended enforcement point from an unrelated failure. A timeout can result from routing or service instability. An application error can occur after the request already passed the boundary. Interpret the observation using configuration and route evidence rather than treating every unsuccessful request as proof of effective containment.

For software validation, inspect every instance that can serve the registry workflow. A rollout may temporarily mix component versions, and a failed replacement may leave an old instance active. Record the observed population, the collection time, and any exceptions. Keep vendor-specific upgrade procedures authoritative; this article does not propose an improvised Operator or database change.

For key validation, obtain the supported inventory and the owner-approved legitimacy decision. Preserve the state needed for incident analysis before removal. After the correction and key-remediation work, verify that expected registry operations succeed using approved accounts and test repositories. Do not create a rogue key in production merely to prove that the original condition once existed.

The diagram below is a proposed acceptance workflow. It separates software, trust, artifact, and consumer checks so that one completed task cannot erase another open question. The sequence should be adapted to the incident decision and the vendor’s current instructions.

Diagnose authentication errors during the response

Authentication errors can come from several layers. A client credential may be expired, a token may be unsuitable for the requested repository, the registry may not trust the expected signing key, or a new access restriction may block a legitimate internal component. Record the exact failing workflow and timestamp before changing settings. Repeated credential resets can obscure the original symptom without resolving its cause.

Compare a failed request with a known approved workflow under the owner’s control. Confirm the expected repository, operation, identity, and route. A successful public pull does not establish that a private push works, and a successful UI login does not establish the registry token path. Choose checks that correspond to the service being restored.

Review recent deployment and key-management changes together. An authentication failure that begins after a key was removed deserves an investigation of that key’s legitimate dependencies. That does not mean the removal was wrong; it means recovery must account for the components that depended on the old state. Use supported procedures rather than restoring an unrecognized key to make an error disappear.

Observe the active enforcement point when diagnosing a route restriction. A legitimate component may use a different address or path from the one documented in an old diagram. Resolve that discrepancy with the owner and narrow the allow decision appropriately. Avoid responding to uncertainty by granting every internal client access to an administrative endpoint.

Keep troubleshooting artifacts within the evidence policy. The Quay configuration documentation warns that certain debug settings can expose credentials in clear text. Do not enable broad credential-bearing debug output as a routine first step. If support requires diagnostic collection, follow its procedure and control the resulting material.

A hypothetical registry-to-workload investigation

Consider a fictional company with a Quay registry serving a build pipeline, a production cluster, and a disaster-recovery mirror. A security engineer identifies an unrecognized approved service key during the response to the advisory. The registry is internal, but several build agents and development networks can reach it. These facts require investigation of the trust boundary; they do not establish who created the key or whether any image was altered.

The first task is provenance. The registry owner compares the key inventory with deployment history and approved component changes. The engineer preserves the relevant state through the supported procedure and opens an incident record for the unexplained entry. The route owner checks every configured ingress to the administrative service and identifies which components require legitimate access. The response lead coordinates restriction and correction without relying on the internal-network label as an assurance.

Suppose the key remains unexplained after the owner review. The team treats it according to the incident criteria and supported remediation guidance. It retains the evidence needed to understand when the key appeared and which activity might relate to it. It does not test its power by forging a token or pulling another team’s private repository. That would create new access events and alter the environment without answering whether earlier access occurred.

The artifact review starts with a release promoted during the uncertain interval. The build record contains an expected digest, while the registry’s current tag points to different content. Before concluding that this is malicious, the release owner checks whether an approved rebuild or promotion explains the change and whether the references describe the same platform artifact. A legitimate change can create a mismatch; an unexplained mismatch requires deeper analysis.

Next, the production owner supplies the image identity actually used by the workload during the interval. If it matches the independently trusted release record, that finding narrows the question for that workload. It does not clear every repository in the registry. If the runtime history is unavailable, the report retains that limitation and seeks other sources, such as deployment records or preserved node observations, under the owner’s incident procedure.

The disaster-recovery mirror receives its own review. Suppose it synchronized the uncertain tag before the origin was corrected but has not served a workload since. The team still needs to establish what content the mirror holds and whether it could be used during a later failover. Leaving it outside scope because it is currently idle could reintroduce uncertainty during the next emergency.

The final response record contains several independent results: the management path is restricted as intended, the applicable corrected build is running, the key inventory has an owner-approved disposition, a specified release has been compared with a trusted reference, and named consumers have been assessed. Any missing history remains an explicit exception. This example demonstrates an investigation method; it is not a report of an actual Quay compromise.

Keep recovery environments from restoring an old trust failure

A registry recovery plan often focuses on availability: restore the database, reconnect object storage, bring the service online, and confirm a pull succeeds. During a signing-trust incident, those steps need an additional question: what trust state is being restored? A backup can preserve the very unauthorized key or uncertain image mapping the response is trying to remove.

Identify the recovery materials and their creation times. Compare them with the suspected exposure interval and the known-good baseline. If the backup is newer than the uncertain key’s appearance, do not assume that restoring it creates a clean state. If it is older, determine what legitimate releases and configuration changes would be missing. The correct choice requires both incident and service-owner judgment.

Keep software and data recovery coupled in the plan. A database restored to a corrected application and a corrected database state served by old vulnerable software present different risks. Record the software version, data state, key inventory, and access restriction expected after restoration. Test the supported recovery procedure in an appropriate environment rather than inferring its behavior from the backup’s filename.

Review mirrors, exports, and secondary registry instances as actual services. Some may have separate administrative ownership or update schedules. An emergency copy can become a trusted publication source even if it was created only for continuity. Record the permitted role of each copy and the condition under which it can return to service.

Define how a recovery exercise will avoid publishing uncertain artifacts. Use designated test content and accounts, keep the exercise within its authorization, and preserve the observation that connects the restored service to its expected trust state. A successful functional test should be reported as such. It should not silently certify the integrity of every historical image or the absence of earlier unauthorized reads.

After urgent remediation, update the continuity plan with the evidence fields that were missing. A future recovery should be able to identify its trusted software, approved key state, artifact baseline, and consumer constraints without reconstructing them during an outage. That is a concrete improvement derived from the response, rather than a generic instruction to keep better backups.

Use audit coverage as an input to the decision

A complete-looking dashboard can hide a narrow collection scope. Ask which events are generated, which components forward them, which identities can view them, and how long they remain available. Distinguish application activity from proxy access, platform changes, and downstream runtime evidence. These sources answer related questions but do not substitute perfectly for one another.

について Quay configuration reference documents separate controls for several audit and failure-event categories. Verify the actual configured settings before assuming that an unsuccessful access attempt would necessarily appear in the records under review. A product’s ability to log an event does not establish that the event was retained in a particular deployment.

Create a coverage table with source, time interval, scope, and known gaps. For example, a repository export may cover the relevant namespace while lacking key-management context; a proxy log may show a route request while lacking the application’s authorization outcome. These examples are proposed interpretations of evidence types, not promises about every deployment’s schema.

Use gaps to guide targeted collection. If the unresolved question concerns image identity, repeatedly searching login failures adds little. If the unresolved question concerns who changed a key, a current image scan adds little. The most efficient next step is the observation most likely to distinguish the remaining explanations, subject to the evidence and access actually available.

Describe negative findings with their boundaries. A clear result might state that no unapproved image change was identified in a named repository during a specified interval using a particular trusted release record. That statement can be useful even when broader history is unavailable. Avoid expanding it into a registry-wide assertion that no unauthorized read or write occurred.

NIST SP 800-61 Revision 3 frames incident response as part of cybersecurity risk management. In this case, the acceptance decision should connect evidence limits to the actual business consequence: continued publication, access to private artifacts, and reliance by downstream services. A missing record is not automatically proof of compromise, but it can change what confidence is justified.

Specify useful deliverables for a registry security assessment

A registry assessment should begin with the authority boundary to be reviewed. Name the registry instances, ingress paths, namespaces, administrative components, and allowed methods. State whether the work covers current exposure, remediation validation, historical incident analysis, or all three. Those scopes differ substantially in required access, time, and evidence.

Require a source-backed software decision, an effective-route review, a supported key-inventory assessment, and a clear record of exceptions. If artifact integrity is included, identify the trusted baseline and which repositories and intervals will be compared. If consumer review is included, name the systems and the evidence available to establish what ran. Avoid a deliverable that consists only of a generic vulnerability list.

For a workflow carried out with Penligent or another assessment platform, define which tasks the software performs and which tasks remain with the registry owner or incident team. Do not assume that general application testing automatically inventories Quay signing keys, upgrades the Operator, or reconstructs historical image use. Acceptance should rest on observed evidence rather than an unverified product capability.

Agree on what a blocked check means. An unreachable internal service, insufficient account permission, or absent historical log should produce an explicit limitation and next action. It should not become a passed test. This protects the customer from receiving a reassuring report whose conclusion depends on parts of the environment that were never observed.

Make retest requirements concrete. A retest should identify the changed condition and the evidence that now supports it, using the same asset identity and scope where practical. When the environment changes materially, document the difference. That makes the final report useful for engineering review and incident acceptance without treating a tool’s completion badge as the security result.

Review queued publication jobs before reopening the pipeline

A paused pipeline can accumulate work that was created under the old trust assumptions. Before resuming publication, identify queued builds, delayed promotions, retrying automation, and manual release requests that actually exist in your environment. The objective is to prevent an operational restart from automatically publishing artifacts whose inputs or approvals have not been reviewed. This is a proposed recovery check, not a claim about a default Quay feature.

For each queued release, determine whether its source revision, build environment, dependency resolution, and output artifact remain appropriate. A job submitted before containment may run only after the registry is corrected. Its later execution time does not establish that all of its inputs were created after recovery. Where provenance is uncertain, the release owner should choose whether to rebuild through a trusted path or retain the job as a documented exception.

Inspect retries as distinct events. An earlier failed push may be retried after service returns, creating a new registry event from a job that appears old in the build system. Correlate the job identity, attempt number, and output digest so the event is not mistaken for unrelated unauthorized publication. Equally, do not dismiss an unexplained write merely because legitimate retries were expected during the same period.

Review emergency credentials issued during the response. A temporary account may have broad permission to restore service or move approved images. Record its owner, purpose, dependent jobs, and revocation condition. Removing it too early can break the recovery workflow, while leaving it indefinitely can preserve unnecessary authority. The incident record should make the transition back to routine access deliberate and observable.

Use a staged return to normal publication where the service owner considers it appropriate. Begin with designated test content and a representative approved workflow, verify the resulting artifact and audit trail, then expand according to the acceptance plan. This provides a controlled way to distinguish recovery problems from normal load. It should not bypass the organization’s usual release approval or replace the vendor’s supported deployment procedure.

Capture the first accepted post-recovery release as a reference point. Retain the source revision, build identity, approved output, publication record, and consumer selection. That reference helps future responders understand where the new trusted interval begins. It also exposes practical gaps in the pipeline’s evidence before an important production release depends on them.

Test credential-class boundaries in registry integrations

Teams developing their own registry integrations can use this incident as a reason to examine authority-changing operations. Build a list of the operations that can modify trusted identities, keys, access policy, or publication destinations. Identify the credential class each operation is intended to accept and the component responsible for enforcing that rule. A shared authentication helper should not make these operations appear equivalent to an ordinary image read.

Illustrative credential class	Illustrative allowed task	Boundary that should reject it
Repository reader	Read approved test content	Trust administration
Repository publisher	Publish within assigned test scope	Unrelated repository and trust administration
Administrative credential	Owner-approved management operation	Operations outside its defined authority
Unknown or incomplete class	No assumed task	Every operation requiring a recognized profile

This table is a design example, not a Quay permission model or an assertion about its internal token classes. Translate it into the specific integration’s documented requirements. For each rejected combination, decide which evidence will establish that the intended control made the decision. A generic failure response is ambiguous when the request might have failed earlier because of routing or malformed input.

Exercise both the negative and permitted paths in an isolated development environment. If every request is rejected, the test may demonstrate an unavailable service rather than correct authorization. If the permitted request succeeds and the lower-authority request reaches the same consumer but is denied for the intended reason, the result is more informative. Keep the fixtures synthetic and avoid using production credentials in test logs.

Review change management around the trust configuration itself. A new issuer, key source, or administrative integration can alter which credentials a consumer accepts even when no repository policy changes. Require an owner to describe that effect and to update the boundary tests. Otherwise, a refactor intended to simplify authentication may accidentally broaden the authority of an existing credential class.

Finally, define the operational signal for an unexpected authority-changing request. The useful record identifies the operation, the validated caller context, the decision, and the case or change reference where available, while excluding the secret credential itself. That allows defenders to investigate the event without turning the logging system into a second repository of sensitive tokens.

Keep credential lifetime and trust lifetime distinct in that review. A short-lived repository credential does not establish that a separately installed signing key has the same lifetime. For every object involved, record what expires, what remains trusted, and which supported action revokes it. Ask the integration owner to demonstrate those lifecycle assumptions in the isolated environment. This catches a class of recovery error in which a team waits for one credential to expire while an independent authority continues to be accepted.

Questions about CVE-2026-123710 and registry recovery

Does CVE-2026-123710 break JWT cryptography?

• The published mechanism concerns accepting a credential for the wrong authority boundary. Cryptographic validity and permission for an administrative operation are separate checks.
• Do not infer that every JWT implementation or every container registry has the same flaw. Use the product-specific advisory for affected scope.

Is an internal Quay registry automatically protected?

• No network label establishes who can reach an administrative service. Review actual routes and the clients allowed to use them.
• Include development, automation, mirror, and recovery paths that exist in your deployment. Record effective restrictions rather than assuming a perimeter rule covers every route.

Does changing passwords or robot tokens restore signing trust?

• Those changes address their respective credentials. They do not establish that the registry’s approved signing-key inventory is legitimate.
• Follow the vendor’s supported key-remediation and software-correction guidance, and keep the evidence for each task separate.

Which fixed version should I install?

• Use the current erratum for your product branch and deployment. The 3.10.28 and 3.17.7 examples above are tied to their specific advisories.
• Do not apply their version numbers to another branch or infer that a desired deployment tag proves every running instance has updated.

Can a clean vulnerability scan prove an image was not replaced?

• A package-vulnerability result does not establish image provenance or authorized publication. Compare relevant content with an independently trusted release record.
• Retain the reference and platform context needed to interpret a digest comparison. An unexplained difference needs investigation; a legitimate rebuild can also change content.

Should I test the exploit against my production registry?

• Begin with supported inspection and non-mutating verification agreed with the owner. Creating a signing key or accessing another namespace changes the environment and can affect its trust.
• Any deeper validation belongs in an isolated, explicitly authorized setting with defined recovery and stop conditions.

Does restarting Quay remove an unauthorized key?

• The vendor warns that an installed unauthorized key can persist across restarts. Treat service availability and trust-store remediation as different outcomes.
• Preserve and assess the key state through supported procedures rather than using a restart as an incident-closure test.

Is active exploitation confirmed for my registry?

• This article makes no such claim. Determine your environment’s status through its evidence and incident criteria.
• A vulnerable software state, an exposed management path, an unrecognized key, and confirmed unauthorized image use represent different findings. Label each result accurately and retain unresolved questions.

The following Penligent video presents a general authorized security-testing workflow. It does not demonstrate exploitation of CVE-2026-123710 or establish that any registry, key store, or downstream workload has been inspected.

Close the response only when the accepted evidence matches the decision being made. A corrected application, a reviewed signing-key inventory, a trusted artifact baseline, and assessed consumers address different parts of the registry’s authority. Keep their status visible so restored service does not hide an unresolved question about what the organization is trusting.