Patch or Revoke First? Your Post-Exploit Decision Tree

When a critical vulnerability affects a software supply chain tool, your first instinct might be to patch. However, if the exploit window was already open, patching alone won't secure your environment. The JFrog Artifactory authentication bypass (CVE-2026-82329) moved from disclosure on August 28 to active exploitation by September 1. This forces your team to answer a harder question: what do you do when the patch closes the door but doesn't evict the intruder?

This decision tree guides you through the post-exploit response protocol for repository compromise scenarios. Your choice depends on three factors: exposure window, credential architecture, and downstream integrity verification.

The Decision You're Facing

You've confirmed your Artifactory instance was vulnerable during the exploit window. You've applied the patch (versions 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20, depending on your branch). Now you're deciding between three response paths:

• Path A: Revoke all administrator tokens immediately, then audit
• Path B: Audit first, revoke selectively based on findings
• Path C: Treat the instance as compromised and rebuild from a known-good state

Choosing incorrectly could leave valid attacker credentials active or waste days on forensics while malicious artifacts spread.

Key Factors That Affect Your Choice

Exposure window duration: How long was your instance vulnerable and internet-accessible? CVE-2026-82329 allows unauthenticated attackers to mint administrator tokens under default configuration. If your system was exposed between August 28 and your patch date, assume token generation occurred.

Token validity architecture: Administrator tokens created before remediation remain valid until explicitly revoked. Patching fixes the authentication weakness but doesn't invalidate credentials already issued. If your token lifecycle management relies on expiration rather than revocation, you're carrying forward the compromise.

Downstream verification posture: Can your CI/CD pipeline verify artifact integrity independently of the repository? If you're pulling container images by tag (mutable reference) rather than digest (immutable reference), and you're not checking signatures at deployment, a tampered artifact stored during the exploit window will deploy successfully even after you patch.

Audit log completeness: JFrog Access logs token creation events. If your logs were tampered with or if you don't have complete coverage for the exposure period, you can't audit your way to confidence.

Path A: Immediate Revocation, Then Audit

Choose this path if:

• Your instance was internet-exposed during any part of the vulnerability window
• You don't have cryptographic verification of artifact integrity at deployment
• Your audit logs show gaps or anomalies
• You support critical or important functions that depend on this repository
• Your substitutability assessment shows you can regenerate tokens within your RTO

What you're protecting against: An attacker who generated administrator credentials on August 29, used them to push a backdoored library on August 30, and is now waiting for you to assume the patch resolved the threat. That token is still valid. That artifact is still in your repository.

Implementation steps:

1. Revoke all administrator tokens created before patch deployment.
2. Issue new administrator credentials through a separate, verified authentication path.
3. Rotate service account credentials that authenticate to Artifactory.
4. Review audit logs for token creation events, user enumeration, credential set access, and artifact modification during the exposure window.
5. Generate a manifest of all artifacts modified during exposure and flag them for integrity verification.

Trade-off: You'll disrupt automation that depends on those tokens. Plan for service interruption and have your credential distribution protocol ready before you revoke.

Path B: Audit First, Revoke Selectively

Choose this path if:

• Your instance was not internet-exposed (internal network only with strict access controls)
• You have complete, tamper-evident audit logs covering the full exposure period
• Your logs show no anomalous token creation or administrative activity
• You can verify artifact integrity through external provenance records
• Your incident escalation protocol allows for a measured forensic window before containment

What you're protecting against: Unnecessary operational disruption when evidence suggests no exploitation occurred.

Implementation steps:

1. Export and preserve audit logs covering August 28 through patch deployment.
2. Search for administrator token creation events you can't attribute to legitimate users.
3. Review user and group enumeration activity.
4. Check for artifact uploads, modifications, or deletions during the window.
5. If you find evidence of unauthorized access, immediately shift to Path A.
6. If logs are clean and you have high confidence in their integrity, revoke only tokens that were exposed or suspect.

Trade-off: You're betting on log integrity and complete visibility. If an attacker with administrator access tampered with logs or if your logging configuration missed the relevant events, you're carrying forward the compromise while you investigate.

Path C: Assume Compromise, Rebuild

Choose this path if:

• Audit logs are incomplete, corrupted, or show evidence of tampering
• Your artifact repository supports build pipelines for customer-facing software or regulated systems
• You cannot independently verify artifact integrity for the exposure period
• Your assessment of JFrog's patch velocity or your own response time suggests the window was sufficient for sophisticated exploitation
• Your wind-down plan allows you to stand up a parallel instance and migrate

What you're protecting against: Persistent backdoor access, tampered artifacts that passed initial integrity checks, and unknown unknowns in a compromised trust anchor.

Implementation steps:

1. Stand up a new Artifactory instance in a clean environment.
2. Restore artifacts from a known-good backup predating the vulnerability disclosure.
3. Re-verify artifact signatures and provenance before migration.
4. Rebuild artifacts created during the exposure window from source in a verified build environment.
5. Migrate build pipelines to the new instance only after verification.
6. Decommission the compromised instance and treat it as a forensic artifact.

Trade-off: This is the most disruptive path. You're trading operational continuity for certainty. It's appropriate when the cost of a missed compromise exceeds the cost of rebuilding.

Summary Matrix

Factor	Path A (Revoke First)	Path B (Audit First)	Path C (Rebuild)
Exposure	Internet-facing during window	Internal only, strict controls	Any exposure + high stakes
Log integrity	Gaps or anomalies present	Complete and verified	Incomplete or tampered
Downstream verification	Tag-based pulls, no signature checks	Digest pinning + signature verification	Cannot verify exposure-period artifacts
Criticality	Supports Critical or Important Functions	Non-critical internal tooling	Customer-facing or regulated pipelines
Disruption tolerance	Can regenerate tokens within RTO	Low tolerance, need continuity	Can stand up parallel environment
Primary risk	Valid attacker tokens remain active	Operational disruption from false positive	Persistent backdoor in trust anchor

The Artifactory case demonstrates a broader principle: patching closes the vulnerability, but it doesn't remediate the exploitation. When an attacker can mint credentials, the patch is step one. Revocation, verification, and in some cases rebuilding are the steps that actually secure your supply chain.

Your decision tree starts with a simple question: do you know with certainty that no attacker walked through that door? If the answer is anything other than yes, revoke first.