Cleanup asks which artifacts were pushed during the window. The harder question is which of the ones already there you can still certify, and against what.
Ihor K
CEO
Registry recovery plans are written around a window: find where it opens, find where it closes, quarantine what landed in between. Administrative access is the case where there is nothing left to find the opening with, because you would find it in records the administrator was holding.
JFrog's advisory for CVE-2026-82329 describes an authentication weakness in Artifactory that, under default configuration, lets an unauthenticated caller with network access obtain administrative privileges. The fixes went out on 28 August 2026 across six supported branches, 7.111.21 through 7.161.20 — six branches being a fair measure of how many self-hosted installs sit at how many different ages. By 1 September watchTowr's honeypot network was recording the bypass in use: attackers minting administrator tokens, then enumerating users, groups, credential sets and federated access topologies. The first question everyone asks is which artifacts were pushed while that was true. The answer tends to come back reassuring, for a reason that should not be reassuring at all: an attacker holding administrative access over a registry has no particular need to push anything.
Take the service at its healthiest. Artifactory answers exactly one question — given a coordinate, a tag, a version range, a latest that floats, return these bytes. Every consumer downstream takes that answer without a second opinion, because taking it without a second opinion is what dependency resolution is. There is no quorum, no cross-check, no second registry consulted for agreement. The answer is trusted structurally: the trust is wired into the resolver rather than decided per build.
Administrative access is authority over that mapping. It is also authority over the retention policy that decides whether the previous bytes still exist to be compared against, and over the access log that would have recorded a substitution. Those three read like separate systems and are administered as one account. The standard remediation guidance for this CVE — patch, assume compromise, review your audit logs, rotate credentials — is right, and the third item is being asked of a record that sat inside the blast radius. A log an administrator could edit does not stop being a log; it stops being evidence.
So the incident loses its earliest date. The attacker need not have reached backwards at all; what is missing is the record you would use to decide how far back to look, and that record was administrable. Which artifacts landed inside the window is a query with an answer. Which artifacts you can still certify is not a query, and the real depth of the second question is your retention horizon rather than the disclosure date — retention itself being a setting on the same console. Cleanup bounds what an attacker added. Nothing bounds what you can still vouch for, because the capacity to vouch is the thing that was administered.
The rule that follows is about where the trust root lives. If the service telling you an image is signed is the same service an unauthenticated request can administer, the check is decorative — not because the cryptography is weak, but because the claim and the evidence for it answer to one account. Move the root somewhere else. The cluster's admission controller holds the public keys and the policy, in configuration your team maintains and reviews in its own repository, and the registry's job narrows to handing over bytes whose digest is checked against that root. Whoever takes the admin console then does not also get to decide what counts as verified. And the policy has to be enforcing: left in audit mode because enforcement once broke a build, it writes a log line at the moment you wanted a stopped deploy.
That is a narrower claim than it sounds. A digest checked against a root you control establishes that the bytes are the bytes you approved. It establishes nothing about a build that was already under someone else's control when the digest was computed — the half I wrote about in May, after the TanStack compromise, where the attestations on the malicious versions were perfectly valid and attested a build the maintainers no longer controlled. That path closes on the CI side or it does not close. One question asks who signed; this one asks who gets to answer. What makes the second one awkward is that the remedy has an expiry date built into it. Relocating a trust root means deciding which of the artifacts you already hold you are willing to sign into it, and that judgement is precisely what an administrative compromise takes away. Afterwards there is nothing left to certify the candidates for the new root except the root you are replacing.
SOURCES