CVE-2026-82329: JFrog Artifactory Auth Bypass Exploited in the Wild

This week in our InSEKurity of the Week series: a vulnerability whose damage is not measured in the machine it compromises, but in everything that machine is trusted by. On August 28, 2026, JFrog published a security advisory for CVE-2026-82329: an authentication weakness in JFrog Artifactory that, “under default configuration, may allow an unauthenticated attacker with network access to obtain administrative privileges.” CVSS 9.8. No credentials. No user interaction. No exploit chain.

Four days later, on September 1, watchTowr’s honeypot network was already recording it: attackers minting themselves administrator tokens, then enumerating users, groups, credential sets, and federated access topologies. In a limited number of cases they created backdoor administrator accounts — a second, quieter way back in that survives the patch. On September 2, CISA added the CVE to the Known Exploited Vulnerabilities catalog with a remediation deadline of September 5 and, notably, flagged it as requiring forensic triage rather than just a patch.

Here is why that matters more than the CVSS number suggests. Artifactory is not an application server. It is the binary repository that your build systems pull from without asking questions. Every mvn install, every npm ci, every docker pull, every Helm chart, every internal Go module in a large organisation routes through it — and the artifacts it hands back are trusted implicitly, because that is the entire point of having a trusted internal registry. Administrative control of Artifactory is not a foothold on one server. It is write access to the software your organisation is about to ship, and to the software your customers are about to install.

🚨 Summary

CVE ID: CVE-2026-82329
CVSS 3.1 Score: 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) — assigned by JFrog as the CNA
CWE: CWE-287: Improper Authentication
Affected Software: JFrog Artifactory, self-managed only — 7.111.4 to 7.111.20, 7.117.0 to 7.117.27, 7.125.0 to 7.125.19, 7.133.0 to 7.133.28, 7.146.0 to 7.146.37, and 7.161.0 to 7.161.19
Not affected: JFrog Cloud (SaaS). JFrog patched its own hosted instances; anything you run yourself — on-premises, in your own AWS/Azure/GCP account, in Kubernetes — is your responsibility
Attack Vector: Network — reachable wherever the Artifactory HTTP interface is reachable
Authentication Required: None. The flaw is the authentication
Root Cause: The join key used by JFrog Access to establish server-to-server trust. Instances where an administrator never explicitly configured one fall back to a product-generated key — what watchTowr called a “phantom” join key — which an attacker can abuse to forge access and mint administrator-level tokens
Impact: Full administrative takeover of the Artifactory instance — and therefore of every artifact, repository, permission, credential, and downstream build that depends on it
Patch Status: Available since 2026-08-28 — fixed in 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20
Published: NVD record published 2026-08-28, last modified 2026-09-03, status Analyzed
Exploitation Status: Actively exploited. First in-the-wild activity observed by watchTowr on 2026-09-01, four days after the patch. CISA’s SSVC assessment records exploitation: active, automatable: yes, technical impact: total
CISA KEV: Listed — added 2026-09-02, remediation due 2026-09-05 under BOD 26-04, ransomware use recorded as Unknown, forensic triage required: Yes
The part people miss: Upgrading does not revoke tokens that were already minted. A forged admin token issued before you patched keeps working until it expires or you revoke it

🖥️ What is JFrog Artifactory?

JFrog Artifactory is a universal binary repository manager. It sits between the public package ecosystems and your engineers, and between your engineers and production. Every artifact your organisation builds, consumes, or ships passes through it: Maven and Gradle JARs, npm packages, PyPI wheels, NuGet packages, Go modules, RubyGems, Docker and OCI images, Helm charts, Debian and RPM packages, Terraform providers, raw generic files.

It plays three roles at once, and each one makes this vulnerability worse:

A proxy and cache for the public internet. Remote repositories mirror npmjs.org, Maven Central, PyPI, Docker Hub. Developers point their toolchains at Artifactory instead of the internet — so whatever Artifactory serves is what the build gets.
The home of internal releases. Your own libraries, your own container images, your own installers. Local repositories hold the things that only exist inside your organisation, including the artifacts you hand to customers.
A credential store by accident. To do its job Artifactory holds upstream registry credentials, cloud storage keys, replication credentials to sibling instances, LDAP/SAML/OIDC configuration, and a large collection of long-lived access tokens belonging to CI/CD systems. An administrator can read or replace all of it.

JFrog states that its platform is used by a majority of the Fortune 100. That is the deployment base we are talking about — and by design, Artifactory is reachable from every build agent, every developer laptop, and in a great many organisations from the internet, because contractors, remote workers, and cloud CI runners need to pull from it too.

Typical Use Cases

Central artifact repository for all package formats used across an organisation
Docker/OCI registry feeding Kubernetes clusters and production deployments
Proxy and cache for public registries, giving control, availability, and an audit trail
Release distribution — the place customers and downstream teams pull signed releases from
CI/CD integration point for Jenkins, GitLab CI, GitHub Actions, Azure DevOps, Bamboo
Build metadata and provenance storage, including SBOM and Xray scan results
Multi-site federation and replication between data centres and cloud regions

🔍 Technical Analysis

Vulnerability Description

CVE-2026-82329 lives in JFrog Access — the platform microservice responsible for issuing and validating credentials. Access is what turns a login, an API key, or a service identity into a token that the rest of the platform will honour. Compromise the component that decides who you are, and every downstream authorisation check is answering the wrong question correctly.

The mechanism is the join key. In a JFrog Platform deployment, multiple services and multiple nodes have to trust each other: Artifactory and Access, an HA cluster’s members, federated instances across sites. That trust is bootstrapped with a shared secret — the join key. JFrog’s own documentation is explicit about how it is obtained:

“For automation purposes, it’s recommended to generate your own Join Key and share it with every new instance. Access will then use the provided join key instead of the auto-generated one, save it to its database, and share it with Artifactory.”

Read that sentence from an attacker’s perspective. Instead of the auto-generated one. If the administrator supplies a key, the supplied key is used. If the administrator supplies nothing — which is the default path for a simple single-node install, and therefore extremely common — the product generates one itself. watchTowr’s term for the resulting condition is a “phantom” join key: a server-to-server trust secret that exists, that grants full inter-service trust, and that no human ever chose, recorded, or rotated.

That is the whole vulnerability. An unauthenticated attacker who can reach the Artifactory HTTP interface can reach a state where Access will issue them a token — and because join-key trust is service-level trust, the token it issues is not a user’s token. It is an administrative one.

Root Cause Analysis

A default that is a secret. The security of the deployment depends on a value that the operator was never required to set, never shown during installation, and in most installs has never looked at. There is no configuration error to find in an audit, because nothing was misconfigured — the default is the exposure.
Service trust and user trust share a door. The join key exists so that Artifactory and Access can trust each other over a private link. The flaw is that this trust relationship was reachable through the same network-facing surface that serves users, rather than being confined to an internal channel.
Trust bootstrap is not authentication. A join key proves “I am a member of this cluster.” An admin token proves “I am allowed to do anything.” The bug is that the first was sufficient to obtain the second, with no additional check in between.
The credential outlives the fix. Tokens minted through this path are, from the platform’s perspective, entirely legitimate. They have their own lifetimes and their own revocation state. Patching the issuing flaw does nothing to the credentials it already issued.
Total impact by design. Artifactory has no meaningful privilege tier above administrator, and no separation between “manage the system” and “rewrite the artifacts.” One escalation reaches everything.

Attack Vector

The following diagram shows the trust relationship the flaw abuses. It is a conceptual data-flow diagram, not a network map.

Illustrative only -- conceptual trust flow, not a functional exploit.

  Internet / build network
          |
          |  (1) HTTP request, no credentials
          v
  +---------------------------+
  |  Artifactory HTTP front   |
  +-------------+-------------+
                |
                |  (2) service-to-service trust,
                |      bootstrapped by the JOIN KEY
                v
  +---------------------------+       join key was never set by an
  |  JFrog Access             | <---- admin -> product generated one
  |  (issues + validates      |       ("phantom" join key)
  |   all platform tokens)    |
  +-------------+-------------+
                |
                |  (3) Access issues a token for a
                |      trusted "cluster member"
                v
        [ ADMINISTRATOR ACCESS TOKEN ]
                |
     +----------+-----------+-----------------+
     v          v           v                 v
  read all   create      rewrite /        read upstream
  users +    backdoor    replace          registry creds,
  tokens     admin user  artifacts        storage keys
                                              |
                                              v
                                   downstream builds pull
                                   the poisoned artifact

Step 1 — Reach the instance. No authentication step is required, so reconnaissance is simply “is there an Artifactory here.” The unauthenticated health endpoint answers that question:

# Unauthenticated reachability check -- returns the literal string "OK".
# Documented as: GET /artifactory/api/system/ping
curl -sk "https://artifactory.example.com/artifactory/api/system/ping"

Step 2 — Obtain an administrator token. The exact request that triggers the phantom-join-key path has deliberately not been published by JFrog or by watchTowr, and we will not speculate about it here. What is publicly documented is the outcome: the attacker ends up holding a valid administrative access token issued by JFrog Access, without ever presenting a username, password, API key, or existing token.

Step 3 — Use it like an administrator, because that is what it is. From here nothing is an exploit any more. Every subsequent action is a documented, supported API call made with a credential the platform considers legitimate. That is what makes the post-exploitation phase so quiet — and these are exactly the calls watchTowr observed:

# All of the following are ORDINARY, DOCUMENTED Artifactory/Access API calls.
# They become an attack only because the token was forged in step 2.
# Shown here so defenders know what to hunt for in their logs.

# Enumerate every token in the system (admins see all tokens, users see only their own).
curl -sk -H "Authorization: Bearer <FORGED_ADMIN_TOKEN>" \
  "https://artifactory.example.com/access/api/v1/tokens"

# Enumerate all platform users -- the basis for picking a name that blends in.
curl -sk -H "Authorization: Bearer <FORGED_ADMIN_TOKEN>" \
  "https://artifactory.example.com/access/api/v2/users"

# Enumerate every repository, local, remote and virtual.
curl -sk -H "Authorization: Bearer <FORGED_ADMIN_TOKEN>" \
  "https://artifactory.example.com/artifactory/api/repositories"

Step 4 — Persist. watchTowr reported that in a limited number of intrusions the attackers created additional administrator users. This is the step that turns a patchable vulnerability into an unpatched incident: the created account is a normal account. Upgrading Artifactory does not remove it.

Exploitation in the Wild

2026-08-28 — JFrog publishes the advisory and the fixed builds. The NVD record goes live the same day at 20:20 UTC.
2026-09-01 — watchTowr’s “Attacker Eye” honeypot network records the first real-world exploitation: four days after the patch. Attackers mint administrator tokens and begin enumerating users, groups, credential sets, and federated access topologies.
Observed tradecraft — Activity came from a small number of geographically distributed IP addresses, with no evidence of indiscriminate mass scanning. Operators verified that their forged credentials worked, surveyed the environment, and appear to have been assessing whether a given instance was worth deeper exploitation. In a limited subset, they created backdoor administrator users.
2026-09-02 — CISA adds CVE-2026-82329 to KEV. The SSVC decision points recorded are exploitation: active, automatable: yes, technical impact: total.
2026-09-05 — Federal remediation deadline under BOD 26-04.

The “no mass scanning” detail is the one worth sitting with. Loud, indiscriminate exploitation gets noticed within hours and burns the bug. Selective, targeted use of an authentication bypass against a build system is what you do when the goal is what gets built, not the server.

Post-Exploitation Impact

Artifact poisoning. An administrator can deploy, overwrite, or redirect artifacts in any repository. A modified internal library or container image is pulled automatically by every build that depends on it — no user interaction, no warning, no signature failure if the signing happens downstream of the repository.
Remote repository redirection. Remote repositories can be re-pointed or their caches populated with attacker-controlled content, so a npm ci that appears to fetch from the public registry is served something else entirely.
Credential harvesting at scale. Upstream registry credentials, cloud object-storage keys, replication credentials, and the platform’s token inventory are all administrator-readable. CI/CD tokens stored in Artifactory frequently have production reach.
Persistent access. Backdoor administrator users and long-lived tokens both survive the software upgrade that closes the vulnerability.
Federation spread. Where instances are federated or replicated across sites, administrative control of one node is a documented path towards the others.
Downstream customer impact. For organisations that ship software from Artifactory, the blast radius does not stop at the perimeter. It stops wherever the customers are.
Audit destruction. Administrators can alter retention and logging configuration, degrading the very evidence needed for the forensic triage CISA is asking for.

📊 Impact Assessment

Immediate Impact

Complete administrative compromise of the Artifactory instance from an unauthenticated network position
Integrity loss across the software supply chain — the artifacts feeding every downstream build become untrusted
Confidentiality loss of stored credentials, tokens, and platform configuration
Persistence that survives patching via already-minted tokens and created accounts
A regulatory and contractual problem, not just a technical one, for anyone distributing software built through the affected instance

Affected Versions

Version branch	Affected range	Fixed in
7.111.x	7.111.4 – 7.111.20	7.111.21
7.117.x	7.117.0 – 7.117.27	7.117.28
7.125.x	7.125.0 – 7.125.19	7.125.20
7.133.x	7.133.0 – 7.133.28	7.133.29
7.146.x	7.146.0 – 7.146.37	7.146.38
7.161.x	7.161.0 – 7.161.19	7.161.20
JFrog Cloud	Patched by JFrog	no action

All fixed builds were released on 2026-08-28. Note that JFrog backported the fix to six maintenance branches: you do not have to jump to 7.161.20 from 7.117.x — take 7.117.28 and stay on your branch.

Affected Environments

Self-managed Artifactory of any edition and topology — on-premises, self-hosted in a cloud account, Docker, Docker Compose, Kubernetes/Helm, HA clusters
Highest risk: internet-exposed instances. Cloud CI runners, external contractors, and remote developers are the usual reasons an Artifactory ends up with a public hostname
Also at real risk: internal-only instances. “Network access” here means any network access. A single compromised developer workstation or build agent — the exact things that are supposed to talk to Artifactory — is enough
Instances that were never explicitly given a join key, which is the default for the majority of standard installations

Attacker Profiles

Supply-chain-focused state actors. A build system is the highest-leverage target in a software organisation, and the observed tradecraft — selective targeting, careful reconnaissance, no noisy scanning — fits this profile precisely.
Ransomware and extortion crews. Administrative access yields production credentials and the ability to deny an organisation its own artifacts, which halts every deployment simultaneously.
Access brokers. A confirmed admin token on a named enterprise’s Artifactory is a sellable commodity.
Opportunists. SSVC rates this automatable: yes. Selective exploitation today does not stay selective; commodity scanning follows every KEV listing.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

1. Determine your version. The REST endpoint below is the documented way; it accepts any valid user, including anonymous if anonymous access is enabled.

# Documented endpoint: GET /artifactory/api/system/version
# Returns JSON containing "version", "revision", "license" and installed add-ons.
curl -sk -u '<user>:<password_or_token>' \
  "https://artifactory.example.com/artifactory/api/system/version"

For Linux package installations you can also ask the package manager directly:

# RPM-based systems (RHEL, Rocky, Alma, SLES).
# Use jfrog-artifactory-oss or jfrog-artifactory-cpp-ce for those editions.
rpm -q jfrog-artifactory-pro

# Debian/Ubuntu -- print just the package name and version.
dpkg-query -W -f='${Package} ${Version}\n' jfrog-artifactory-pro

2. Upgrade to the fixed build on your branch. Pick the fixed version matching your current branch from the table above — do not cross branches unnecessarily.

# Debian/Ubuntu, JFrog APT repository configured.
# Replace 7.161.20 with the fixed build for YOUR branch (e.g. 7.117.28).
sudo apt-get update
sudo apt-get install jfrog-artifactory-pro=7.161.20

# RHEL/Rocky/Alma, JFrog YUM repository configured.
sudo dnf install jfrog-artifactory-pro-7.161.20

# Docker: pull and redeploy the fixed tag.
# Official image per JFrog's Docker installation docs.
docker pull releases-docker.jfrog.io/jfrog/artifactory-pro:7.161.20

3. Assume the tokens are compromised and revoke them. This is not optional and it is not covered by the upgrade. List what exists, then revoke anything you cannot account for.

# List all tokens (admin sees every token in the system).
curl -sk -H "Authorization: Bearer <YOUR_ADMIN_TOKEN>" \
  "https://artifactory.example.com/access/api/v1/tokens"

# Revoke a specific token by its ID.
curl -sk -X DELETE -H "Authorization: Bearer <YOUR_ADMIN_TOKEN>" \
  "https://artifactory.example.com/access/api/v1/tokens/<TOKEN_ID>"

Then rotate what those tokens could reach: CI/CD service credentials, upstream registry credentials, and cloud storage keys configured in the platform.

4. Set an explicit join key. Remove the “phantom” condition permanently. JFrog documents the location and the configuration parameter:

# Where the (encrypted) join key lives on a standard installation.
ls -l "$JFROG_HOME/artifactory/var/etc/security/join.key"

# It is configured in the system YAML under shared.security:
#   shared:
#     security:
#       joinKey:     <explicit value -- takes precedence>
#       joinKeyFile: <path, e.g. /opt/jfrog/artifactory/var/etc/security/join.key>
sed -n '/^shared:/,/^[a-z]/p' "$JFROG_HOME/artifactory/var/etc/system.yaml"

The current value can also be read in the UI under Administration > Security > General > Connection Details, by entering your password in the Current Password field and clicking Unlock.

5. Restrict network access. Artifactory should not be reachable from the open internet. If external build agents genuinely require it, put it behind a VPN, an authenticating reverse proxy, or an IP allow-list.

Detection Measures

CISA marked this CVE as requiring forensic triage, and it is right to: exploitation leaves behind credentials that look completely legitimate. There is no vendor-published set of IoCs that reliably catches every attempt, so hunting is behavioural. Start in the logs, which live in a documented location:

# JFrog service logs: $JFROG_HOME/<product>/var/log
# Access runs as a microservice under Artifactory, so its logs sit alongside it.
cd "$JFROG_HOME/artifactory/var/log"

# 1. Every request to the Access token API since the patch date.
#    -E enables extended regex, -i makes it case-insensitive.
grep -E -i "/access/api/v[12]/tokens" access-request.log

# 2. Requests to the user-management API -- backdoor account creation shows up here.
grep -E -i "/access/api/v[12]/users" access-request.log

# 3. Anything in the Access service log mentioning the join key or token issuance.
grep -E -i "join.?key|token.*(created|issued)" access-service.log

# 4. Same sweep across rotated logs, which are compressed into archived/.
zgrep -E -i "/access/api/v[12]/(tokens|users)" archived/access-request.log*.gz

Then compare what you find against reality:

Tokens issued on or after 2026-08-28 that no engineer, pipeline, or change ticket accounts for
Administrator accounts created since 2026-08-28, especially names that mimic service accounts (ci-svc, build-admin, jfrog-sync)
Administrative API activity from source IPs outside your build network, VPN ranges, and office egress
Bulk enumeration patterns — a single principal reading the full user list, the full token list, and the full repository list in quick succession is not how humans or pipelines behave
Permission target or repository configuration changes that no change record explains
Artifacts overwritten or redeployed with unexpected checksums since 2026-08-28

If any of that turns up, treat it as an incident affecting everything built from that instance, not as a server compromise. The scope of the investigation is the artifacts, not the host.

Long-term Security Improvements

Treat the build system as tier-0 infrastructure. Artifactory, your CI controllers, and your signing infrastructure deserve the same isolation, monitoring, and change control as your domain controllers. In most organisations they get considerably less.
Never leave a trust secret to a default. Explicitly set and document every join key, cluster secret, and master key at install time, and rotate them on a schedule. If nobody can tell you what a secret’s value is or when it was last changed, that is the finding.
Sign artifacts outside the repository. If provenance is established by the repository, then whoever controls the repository controls provenance. Sigstore/cosign signatures and SLSA provenance created in the build and verified at deployment survive a compromised registry.
Verify at consumption, not just at publication. Pin digests for container images, enforce lockfiles, and make your deployment gate check signatures — so a swapped artifact fails closed.
Short-lived, scoped tokens only. Replace long-lived admin and CI tokens with short-lived, narrowly scoped ones. The reason “revoke every token” is a painful instruction this week is that the tokens were built to last forever.
Ship platform logs off-box. Access and Artifactory logs must land in a SIEM that an Artifactory administrator cannot alter, or the forensic triage has nothing to work with.
Subscribe to the vendor’s advisory feed and act on it in days, not quarters. The window between the JFrog advisory and in-the-wild exploitation was four days.
Know your exposure before the next one. Maintain an inventory that answers “is it internet-facing, what version, who owns it, when was it last patched” for every piece of build infrastructure — ahead of the advisory, not after it.

⚠️ Why is this Critical?

The barrier to entry is nil. Unauthenticated, network-reachable, no user interaction, no chaining. CVSS 9.8 with an exploitability sub-score of 3.9 — the maximum.
The default configuration is the vulnerable configuration. There is no misconfiguration to blame and no hardening guide that would have prevented it. Standard installs are affected.
Exploitation began four days after the patch, and the operators looked deliberate rather than opportunistic — which is the profile of an actor interested in what you build.
Patching is not remediation here. Forged tokens and created accounts persist through the upgrade. Organisations that patched and moved on may still be compromised.
The blast radius is downstream. Artifacts served by a compromised Artifactory are trusted automatically by every build, every deployment, and in many cases every customer.
CISA required forensic triage, not just patching — an explicit signal that the agency expects compromise to be present and invisible.
The trust relationship is the target, and it is spreading. Federated and replicated instances multiply a single administrative compromise across sites.
Supply-chain compromise scales in a way server compromise does not. SolarWinds, Codecov, xz-utils, and the 3CX incident all followed the same shape: one build system, thousands of victims.

📅 Timeline and Disclosure

2026-08-28 — JFrog publishes its security advisory and releases fixed builds 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20. JFrog Cloud instances are patched by the vendor. NVD publishes the CVE record at 20:20 UTC.
2026-09-01 — watchTowr’s Attacker Eye honeypot network observes the first in-the-wild exploitation: attackers minting administrator tokens and enumerating users, groups, credential sets, and federated access topologies. Backdoor administrator users are created in a limited number of cases.
2026-09-02 — CISA adds CVE-2026-82329 to the Known Exploited Vulnerabilities catalog. SSVC assessment: exploitation active, automatable yes, technical impact total. Forensic triage is flagged as required.
2026-09-02 — watchTowr publicly confirms the exploitation activity; mainstream security press picks the story up over the following days.
2026-09-03 — NVD record last modified; analysis completed, CPE ranges assigned.
2026-09-05 — Remediation deadline for US federal civilian agencies under BOD 26-04.

📚 Resources and References

🤝 SEKurity Supports You

This is the second week running that the InSEKurity of the Week is a system whose job is to be trusted. Last week it was the appliance that terminates your VPN; this week it is the repository your builds pull from without asking. Both illustrate the same uncomfortable point: the systems with the widest blast radius are rarely the ones with the most attention, because they are infrastructure — they work, they are boring, and nobody schedules a penetration test against the artifact repository.

Attackers do not share that blind spot. They are explicitly looking for the machine that everything else believes. If you do not know whether your build platform is internet-reachable, which version it runs, who holds administrative tokens on it, or whether anything unusual happened on it since August 28, that is the gap — and it is one we help close.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your build and release infrastructure is our drive.

Sources

NVD — CVE-2026-82329 — CVSS vector, CWE-287, affected version ranges, SSVC assessment, KEV dates
CISA — Known Exploited Vulnerabilities Catalog — KEV entry, added 2026-09-02, due 2026-09-05, forensic triage required
CISA — Seven Known Exploited Vulnerabilities Added to Catalog (2026-09-02)
GitHub Advisory Database — GHSA-c5pf-6p5j-gj87 — advisory text and CVSS vector
BleepingComputer — Hackers exploit critical JFrog Artifactory flaw to forge admin tokens — fixed versions, token persistence after upgrade
The Hacker News — Attackers Exploit Critical JFrog Artifactory Flaw to Mint Admin Tokens Days After Disclosure — phantom join key mechanism, exploitation timeline, observed tradecraft
SecurityWeek — Critical JFrog Artifactory Vulnerability Reportedly Exploited in the Wild — self-hosted vs. SaaS scope, supply-chain implications
Dark Reading — Attackers Jump on Critical Artifactory Flaw After Disclosure
Qualys ThreatPROTECT — CISA Added JFrog Artifactory Vulnerability to KEV
securityonline.info — Weekly CVE Report: 10 Exploited Vulnerabilities Hit CISA KEV — CW36 vulnerability shortlist
JFrog Documentation — View the Join Key — auto-generated vs. explicitly provided join key
JFrog Documentation — Log Files Location and Naming — log paths used in the detection section
JFrog Documentation — Linux Package Installation and Docker Installation — package names, image name, upgrade commands

InSEKurity of the Week (CW36/2026): JFrog Artifactory Authentication Bypass to Admin (CVE-2026-82329)