Back to Intelligence

JFrog Artifactory Chained Exploit Grants Admin Access: Detection, Hunting, and Remediation for Self-Hosted Servers

SA
Security Arsenal Team
September 11, 2026
13 min read

Between August 15 and September 8, researchers at Wiz observed attackers chaining two vulnerabilities in JFrog Artifactory — the artifact repository that software build pipelines pull dependencies from — to gain administrator-level control of self-hosted servers and plant a persistent unauthorized access mechanism. Both flaws were patched by JFrog before the campaign began, which means every compromised server had one thing in common: it was running an outdated version.

This is not a theoretical supply-chain risk. Artifactory sits at the heart of your CI/CD pipeline. It stores your internal packages, container images, build artifacts, and often the credentials those pipelines use to publish downstream. An attacker with admin control of Artifactory can poison artifacts your developers and build systems consume, exfiltrate proprietary source and secrets, and persist quietly inside infrastructure that most security teams treat as trusted. If you run self-hosted Artifactory and have not confirmed your patch level this week, treat that as an open incident until proven otherwise.

Technical Analysis

What Happened

Per Wiz's reporting, attackers chained two distinct flaws in self-hosted JFrog Artifactory deployments:

  1. Initial access flaw — the first vulnerability provided the foothold needed to interact with the application in an unauthorized way.
  2. Privilege escalation / admin takeover flaw — the second flaw converted that foothold into full administrative control of the Artifactory instance.

With admin control established, the attackers planted a persistent access mechanism — consistent with web shell deployment or the creation of rogue admin accounts/access tokens, both of which survive a simple service restart and, in some cases, survive patching itself.

Affected Products

  • Product: JFrog Artifactory, self-hosted deployments (Linux and Windows installations, Docker images, and Kubernetes/Helm deployments)
  • Not affected by this campaign: JFrog SaaS (cloud-hosted) instances, which are patched by JFrog centrally
  • Vulnerable condition: Any self-hosted instance that had not applied JFrog's fixes before the August 15 – September 8 exploitation window

The news item does not publish CVE identifiers for the two chained flaws. Do not guess or assume identifiers from older Artifactory advisories. Pull the exact fixed versions directly from the JFrog release notes and security advisories page for your major version train (7.x), and verify against your running build.

Why the Attack Chain Matters to Defenders

Chaining is the defining characteristic here. Individually, each flaw may have looked moderate in isolation — limited initial access on one side, an escalation requiring existing access on the other. Chained together against an internet-exposed or broadly internally reachable Artifactory server, they produce unauthenticated-to-admin compromise. This is why CVSS scores on individual CVEs routinely understate real-world risk, and why "we'll patch it next cycle" is not an acceptable posture for build infrastructure.

Exploitation Status

  • Confirmed active exploitation in the wild: Yes — observed by Wiz between August 15 and September 8, 2026
  • Preconditions: Unpatched self-hosted Artifactory instance, network-reachable by the attacker (internet-facing instances are at highest risk, but internal instances are reachable via any initial foothold)
  • Post-exploitation behavior: Persistence mechanism planted (web shell and/or rogue credentials)

Post-Exploitation Persistence: What to Look For

Based on the tradecraft described, the realistic persistence and post-exploitation artifacts on a compromised Artifactory host include:

  • Dropped web shells (JSP files) under the Artifactory web application directories, e.g. /opt/jfrog/artifactory/app/artifactory/tomcat/webapps/ — look for recently created or modified .jsp files, especially with randomized names
  • Rogue admin accounts or access tokens created in the Artifactory security configuration (visible in the UI under Administration → Identity and Access, and in the access/audit logs)
  • Anomalous outbound connections from the Artifactory Java process (Tomcat/java) to non-repository destinations
  • Child processes spawned by Tomcat/Java — shells, curl/wget, base64-decoding pipelines — which a repository manager has no legitimate reason to execute

Detection & Response

Sigma Rules

The following rules target the highest-signal behaviors: the Artifactory web server spawning command interpreters (web shell behavior), JSP file creation in the Tomcat webapps tree, and rogue admin token/account creation events in Artifactory audit logs.

YAML
---
title: Artifactory Tomcat Process Spawning Shell or Command Interpreter
id: 3f8a2c71-9b4e-4d12-a6f0-7c1e5d9b2a48
status: experimental
description: Detects the Artifactory/Tomcat Java process spawning shells, downloaders, or scripting interpreters, consistent with web shell execution following chained exploitation of JFrog Artifactory flaws.
references:
  - https://thehackernews.com/2026/09/attackers-chain-jfrog-artifactory-flaws.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1505.003
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/artifactory/'
      - '/tomcat/'
    ParentCommandLine|contains:
      - 'artifactory'
      - 'catalina'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Artifactory backup or maintenance scripts executed via cron under the artifactory user — verify parent chain is systemd/cron rather than Tomcat
level: high
---
title: Suspicious JSP File Creation in Artifactory Tomcat Webapps Directory
id: 8c1d4e62-3a7f-4b95-9d21-5e6a8c0f3b17
status: experimental
description: Detects creation or modification of JSP files inside the Artifactory Tomcat webapps directory, a strong indicator of web shell deployment following administrative compromise of self-hosted Artifactory.
references:
  - https://thehackernews.com/2026/09/attackers-chain-jfrog-artifactory-flaws.html
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/artifactory/app/artifactory/tomcat/webapps/'
      - '/opt/jfrog/artifactory/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate Artifactory upgrades redeploy WAR/JSP content — correlate with scheduled maintenance windows and upgrade logs
level: high
---
title: Artifactory Admin Token or User Creation in Audit Logs
id: 5b9e7a34-2c6d-4f18-b3a0-9d4c1e7f6a52
status: experimental
description: Detects creation of access tokens, API keys, or new user accounts recorded in Artifactory access/audit logs, which may indicate rogue persistence established after admin-level compromise.
references:
  - https://thehackernews.com/2026/09/attackers-chain-jfrog-artifactory-flaws.html
  - https://attack.mitre.org/techniques/T1136/
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/09/15
tags:
  - attack.persistence
  - attack.t1136
  - attack.t1098
logsource:
  category: application
  product: jfrog
detection:
  selection:
    Message|contains:
      - 'create token'
      - 'token created'
      - 'create user'
      - 'user created'
      - 'POST /access/api/v1/tokens'
      - 'POST /artifactory/api/security/users'
      - 'PUT /artifactory/api/security/users'
  condition: selection
falsepositives:
  - Legitimate CI service-account provisioning — baseline expected token creation sources (automation IPs, IaC pipelines) and alert on deviations
level: medium

KQL (Microsoft Sentinel / Defender)

The following hunts assume Artifactory hosts forward syslog/audit logs to Sentinel (CEF or Syslog via AMA), and that Defender for Endpoint or equivalent process telemetry exists on the servers. Run both across the exploitation window (August 15 – September 8, 2026) and the present — persistence planted in August will still be firing today.

KQL — Microsoft Sentinel / Defender
// Hunt 1: Artifactory/Tomcat spawning suspicious child processes (web shell behavior)
DeviceProcessEvents
| where TimeGenerated >= datetime(2026-08-15)
| where InitiatingProcessCommandLine has_any ("artifactory", "catalina", "tomcat")
    or InitiatingProcessFolderPath has_any ("artifactory", "tomcat")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "python", "python3", "perl", "nc", "ncat", "base64", "cmd.exe", "powershell.exe")
| project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| order by TimeGenerated desc;

// Hunt 2: Artifactory audit events indicating token/user creation (via Syslog/CEF ingestion)
Syslog
| where TimeGenerated >= datetime(2026-08-15)
| where SyslogMessage has_any ("POST /access/api/v1/tokens", "/artifactory/api/security/users", "token created", "user created")
| project TimeGenerated, Computer, HostIP, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: Outbound network connections from Artifactory Java process to rare external destinations
DeviceNetworkEvents
| where TimeGenerated >= datetime(2026-08-15)
| where InitiatingProcessFileName =~ "java" and InitiatingProcessCommandLine has "artifactory"
| where RemoteIPType == "Public"
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by DeviceName, RemoteUrl, RemoteIP, RemotePort
| where ConnectionCount < 50  // rare destinations — repositories see high volume to known upstreams
| order by FirstSeen asc;

Velociraptor VQL

Deploy this hunt across your Artifactory fleet to surface web shell artifacts and suspicious process lineage in one sweep. It checks the Tomcat webapps tree for recently modified JSP/WAR content and enumerates running processes for shell children of Java.

VQL — Velociraptor
-- Hunt: Artifactory web shell artifacts and suspicious Tomcat child processes
-- Artifact: SecurityArsenal.Artifactory.CompromiseSweep

-- Part 1: Recently modified JSP/WAR files in the Tomcat webapps tree
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=['/opt/jfrog/artifactory/**/tomcat/webapps/**/*.jsp',
                 '/opt/jfrog/artifactory/**/tomcat/webapps/**/*.jspx',
                 '/opt/jfrog/artifactory/**/tomcat/webapps/**/*.war',
                 '/var/opt/jfrog/artifactory/**/webapps/**/*.jsp'])
WHERE Mtime > '2026-08-01'
ORDER BY Mtime DESC

-- Part 2: Suspicious child processes of java/Tomcat (run as separate hunt or join)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(sh|bash|curl|wget|python|perl|nc|ncat)$'
  AND Ppid IN (
      SELECT Pid FROM pslist()
      WHERE CommandLine =~ '(artifactory|catalina|tomcat)'
  )

Verification and Hardening Script

Run this on every self-hosted Artifactory host. It confirms the installed version against the patched baseline, sweeps for web shell artifacts, enumerates unexpected listening services, and lists local users/tokens for review. Adjust $JFROG_HOME and the minimum patched version to match JFrog's advisory for your release train.

Bash / Shell
#!/bin/bash
# Security Arsenal - Artifactory chained-exploit verification & hardening script
# Run as root or with sudo on each self-hosted Artifactory node.

set -euo pipefail

JFROG_HOME="${JFROG_HOME:-/opt/jfrog/artifactory}"
MIN_PATCHED_VERSION="7.XX.X"   # <-- SET from JFrog security advisory for your train
REPORT="/tmp/artifactory_ir_sweep_$(date +%Y%m%d_%H%M%S).txt"

echo "=== Artifactory IR Sweep $(date -u) ===" | tee "$REPORT"

# 1. Version check — confirm installed version meets or exceeds the patched baseline
echo -e "\n[1] Installed Artifactory version:" | tee -a "$REPORT"
INSTALLED=$(grep -oPm1 '(?<=<version>)[^<]+' "$JFROG_HOME/app/artifactory/tomcat/webapps/artifactory/WEB-INF/classes/artifactory.version" 2>/dev/null \
  || curl -s -u admin:ADMIN_PASSWORD http://localhost:8081/artifactory/api/system/version 2>/dev/null \
  || echo "UNKNOWN - check via UI: Administration > Monitoring > Service Status")
echo "Installed: $INSTALLED | Minimum patched: $MIN_PATCHED_VERSION" | tee -a "$REPORT"

# 2. Web shell sweep — JSP/WAR files modified since Aug 1, 2026 in Tomcat tree
echo -e "\n[2] JSP/WAR files modified since 2026-08-01 (investigate ANY hit):" | tee -a "$REPORT"
find "$JFROG_HOME" -path '*/tomcat/webapps/*' \( -name '*.jsp' -o -name '*.jspx' -o -name '*.war' \) \
  -newermt '2026-08-01' -ls 2>/dev/null | tee -a "$REPORT" || echo "None found" | tee -a "$REPORT"

# 3. Suspicious process lineage — shells/tools parented by java/tomcat
echo -e "\n[3] Suspicious child processes of java/tomcat:" | tee -a "$REPORT"
ps -eo pid,ppid,comm,args --forest | grep -E 'java|artifactory|catalina' -A2 | \
  grep -E '\b(sh|bash|dash|curl|wget|python|perl|nc|ncat|base64)\b' | tee -a "$REPORT" || \
  echo "None found" | tee -a "$REPORT"

# 4. Unexpected outbound connections from the Artifactory java process
echo -e "\n[4] Established outbound connections from java (review for non-repository destinations):" | tee -a "$REPORT"
JPID=$(pgrep -f 'artifactory|catalina' | head -5 | tr '\n' '|' | sed 's/|$//')
if [ -n "$JPID" ]; then
  ss -tnp state established | grep -E "pid=($JPID)" | awk '{print $5, $NF}' | sort -u | tee -a "$REPORT"
else
  echo "Artifactory java process not found - is the service running?" | tee -a "$REPORT"
fi

# 5. Local user / persistence review
echo -e "\n[5] Recently created local accounts (since 2026-08-01):" | tee -a "$REPORT"
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read -r u; do
  CH=$(chage -l "$u" 2>/dev/null | awk -F': ' '/Last password change/{print $2}')
  echo "$u (last pw change: $CH)" | tee -a "$REPORT"
done

# 6. Artifactory-side review checklist (manual, via UI/API)
echo -e "\n[6] MANUAL STEPS REQUIRED in Artifactory UI/API:" | tee -a "$REPORT"
cat <<'EOF' | tee -a "$REPORT"
  a) Administration > Identity and Access > Users: enumerate ALL admin accounts;
     remove any not attributable to your team. Check creation dates.
  b) Administration > Identity and Access > Access Tokens: revoke ALL tokens
     created since 2026-08-01 that cannot be tied to automation. When in doubt,
     revoke and reissue.
  c) Review $JFROG_HOME/var/log/access/ and audit logs for POST /access/api/v1/tokens
     and /api/security/users calls from unexpected source IPs since 2026-08-01.
  d) Rotate ALL credentials stored in or used by Artifactory: repository replication
     passwords, docker/registry credentials, CI service accounts, signing keys.
EOF

echo -e "\nSweep complete. Report: $REPORT" | tee -a "$REPORT"
echo "If section [2] or [3] returned ANY results: isolate the host, preserve the report and logs, and initiate your IR process before patching — evidence first."

Remediation

Patching alone does not evict the attacker. Because the campaign planted persistence, an Artifactory server that was vulnerable during the August 15 – September 8 window must be treated as potentially compromised, not merely out of date.

  1. Identify every self-hosted Artifactory instance — including dev, staging, and "temporary" instances that slipped outside your CMDB. Scan your external attack surface for exposed ports 8081/8082 (and any reverse-proxy front ends) serving the Artifactory UI.
  2. Upgrade to the JFrog-fixed version for your release train. Pull the exact fixed build numbers from JFrog's official security advisories and release notes at jfrog.com/security and the JFrog release notes for Artifactory 7.x. Both flaws are already patched — there is no excuse to remain on a vulnerable build.
  3. Assume breach for anything unpatched during the window. Before or immediately after patching, run the sweep script and hunts above. If you find rogue JSP files, unexpected admin accounts, or unexplained tokens, isolate the host and pivot to full IR: memory capture, log preservation, and timeline reconstruction back to at least August 15.
  4. Rotate everything Artifactory touches. Repository credentials, replication passwords, CI/CD service accounts, container registry credentials, GPG/signing keys, and any cloud credentials reachable from the host. Treat artifact integrity as suspect until validated — audit builds produced during and after the window.
  5. Remove internet exposure. Artifactory should not be reachable from the public internet. Place it behind a VPN/ZTNA gateway or an authenticated reverse proxy with IP allowlisting. This single control would have broken the campaign's delivery path for most victims.
  6. Add detection coverage permanently. Deploy the Sigma rules above to your Artifactory fleet, forward Artifactory access and audit logs to your SIEM (they are off by default in many installs — enable them), and alert on admin-token creation and Tomcat child processes as ongoing detections, not one-time hunts.
  7. Set an internal remediation SLA. For actively exploited build-infrastructure vulnerabilities, your patch SLA should be measured in days, not quarters. Confirm CISA KEV status for the applicable CVEs once JFrog's identifiers are published and apply any associated federal deadlines as your floor, not your ceiling.

The Bigger Lesson

Artifact repositories are tier-zero assets wearing the costume of middleware. They hold your code, your packages, your container images, and the trust of every pipeline that pulls from them — yet they routinely run months behind on patches because "it's internal tooling." This campaign is the counterargument: two chained bugs, a four-week exploitation window, and full administrative control of the system every developer trusts by default. Inventory your Artifactory estate today, patch it, hunt it, and get it off the internet.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.