Quay: recovering trust requires a signing key review
A container registry needs to demonstrate who authorizes access to images. Our proposed recovery connects trusted keys, published content and decisions by the services consuming that content.
Auf Portugiesisch lesenBy Pentesty
What the sources establish
The Red Hat advisory describes CVE-2026-123710 as critical: an unauthenticated client can install a trusted signing key and issue access tokens for any repository. The advisory recommends restricting the /keys endpoint and reviewing key rotation and deletion events. Exposure depends on untrusted clients being able to reach that service.
Red Hat public guidance explains that changing passwords or regenerating robot tokens does not revoke an unauthorized key. A November 11 upstream change identifies a fix for the CVE; by itself, this does not establish an installed version or a corrected enterprise package.
Map the registry as a trust relationship
Propose a map with three parts: who administers registry authority, who publishes images and who receives the content. Record the service and accountable person for each connection. The map organizes acceptance questions and helps prevent a team closing an investigation with evidence another team still needs to assess.
Consider an internal application receiving a new image through a delivery routine. In the proposed exercise, the team should connect publication authorization with approved content and expected execution. If one relationship lacks evidence, record the outstanding item alongside the service depending on it.
Our analysis of Docker Hub tokens and image trust complements this discussion. The technical situations differ; use the relationship between authority, publication and consumption to organize your environment review.
Preserve evidence before acceptance
The response team should define collection and authorization before changing the environment. The proposed record brings together key and event references without storing private material in a shared report. For each record, note its origin, timestamp, collection owner and the question it can answer.
Choose a small set of images relevant to the business. Record which approval supports each version, where it was published and which services used it during the examined period. When that connection cannot be demonstrated, keep the uncertainty visible. A missing record calls for investigation without automatically becoming confirmation of misuse.
- Authority. Ask the registry owner to review trusted keys and document the decision for each examined entry, including the reason and supporting references.
- Content. Connect each selected image with its approval and observed identifier. Keep the conclusion about content separate from the conclusion about who could publish it.
- Consumers. Ask each application owner for the versions actually used within scope. Record which services have sufficient evidence and which still await verification.
Test recovery through a controlled path
After recovery is authorized, propose an isolated exercise with a harmless image and a test consumer. Define an allowed publication and an action that should be denied in advance. Preserve the results and ask a reviewer to check whether they correspond to the planned identities and resources.
Acceptance should also show which change became active. The analysis of fixes in the process serving a site offers a useful question: does the evidence describe something available, installed or actually running? Adapt it to the registry without treating exercise success as proof that compromise never occurred.
If the test fails, preserve its result and refer the discrepancy to the appropriate owner. Avoid accumulating informal decisions during the window. A released operation needs a recorded scope, return condition and next accountable owner.
Deliver a decision consumers can recognize
At completion, each service should receive a conclusion about what it may use again and under which conditions. Include the examined images, required evidence, limitations and next review. This distinguishes a restricted release from a decision still awaiting investigation.
To assess the process, give a reviewer a record with one image deliberately lacking its associated approval. The exercise succeeds when that gap prevents acceptance of the path and reaches someone able to resolve it. Deliverable quality lies in the traceability of the decision.
Frequently asked questions
Does changing a password remove an unauthorized key?
Red Hat guidance says this does not revoke the signing key. The recovery decision needs to include that authority.
Does the upstream commit identify the installed package?
The commit is a change reference. The team must still connect it with the product, package and state actually observed.
Which image should enter the exercise first?
Agree with the business owner on a test image and validation service, without real data or production consumers.
What evidence prevents premature closure?
A record keeping authority, content and consumers separate, with an individual conclusion for each part and accountable owners for the gaps.
Sources and references
- SecurityWeek: November 12 editorial reference
- Red Hat: CVE-2026-123710 advisory
- Red Hat: public guidance on image impact
- Quay: November 11 upstream change
Original Pentesty analysis, published November 12, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.