JFrog Artifactory: How Tokens Become Admin and How to Hunt the Abuse
A software repository sits between the people who build software and the systems that run it. When that repository is compromised, the investigation needs to answer more than whether someone accessed a server. It needs to establish whether the company can still trust the identities, credentials, and artifacts passing through it.
Recent Artifactory exploitation illustrates why.
Two vulnerabilities allow an attacker to obtain a token and escalate its authority. A separate vulnerability abuses cluster trust to reach administrative access. Understanding those mechanisms helps defenders recognize the activity, assess the consequences, and investigate what an upgrade alone cannot resolve.
For a self-hosted Artifactory deployment, the practical questions are:
Could an attacker reach the vulnerable service?
Did an unexpected identity obtain administrative authority?
What did that identity access, change, or leave behind?
What evidence supports returning the environment to normal operation?
1. How the attack works
A valid token should not automatically mean permission
A token represents an identity and the authority granted to it.
Those are separate decisions. A service can correctly verify who issued a token and whether its signature is valid, yet still make the wrong decision about what the holder may do.
An authorization check must establish both:
Authenticity: Is this token valid and issued by a trusted authority?
Permission: Does this identity have the scope required for this action?
The Artifactory token chain crosses that boundary.
The first flaw exposes a token; the second increases its authority
CVE-2026-42018 can expose an internal anonymous-user token to an unauthenticated caller. CVE-2026-42016 can then allow that token to obtain administrative scope because the relevant validation fails to enforce scope correctly. These are separate weaknesses that become more consequential when combined. JFrog security advisories
Wiz observed the following sequence:
Step | Request | Investigative significance |
Obtain a token | POST /access/api/v1/aws/token/ | A successful response supplies the internal anonymous-user JWT. |
Increase its authority | POST /access/api/v1/tokens | The token is exchanged for administrative scope. |
Use that authority | Subsequent privileged requests | Activity may still appear under token:anonymous. |
Wiz observed this chain between August 15 and September 8, 2026. In some cases, attackers created an administrator within five minutes. Wiz’s exploitation analysis
The important lesson is the mismatch between identity and behavior. An identity labeled “anonymous” deserves investigation when it starts exercising administrative authority.
A separate flaw abuses cluster trust
CVE-2026-82329 reaches administrative access through the registry-join mechanism.
Cluster members need a way to establish trust. In this vulnerability, an empty configuration value can be treated as a trusted join key. That enables a forged token to pass validation and obtain administrative access through the join workflow.
The entry point is:
POST /access/api/v1/registry/joinLegitimate cluster peers also use this endpoint and can receive HTTP 201. Fastly identifies the forged token’s key ID (the SHA-256 hash of an empty string) as a distinguishing signal when that evidence is available. A successful response alone does not establish compromise. Fastly’s technical analysis
Both paths illustrate a broader failure: the service accepts a credential or trust relationship that grants more authority than the requester should possess.
2. What this means for a company
Administrative access to an artifact repository can affect several parts of the business.
Software integrity. Repository administrators may be able to alter artifacts or repository configuration. Investigators should determine whether downstream builds consumed anything changed during the suspected intrusion.
Credentials and integrations. Repository services interact with build systems, storage, and other infrastructure. Credentials accessible through the compromised service may extend the investigation into those systems.
Availability. Changes to permissions, repositories, or configuration can interrupt builds and deployments even when there is no evidence of artifact tampering.
Persistent access. New accounts, issued tokens, or changes on the host may remain after the original vulnerability is patched.
These are impact areas to investigate. They should not be presented as evidence that every affected organization experienced all of them.
For your environment, start with ownership and dependencies: who administers Artifactory, which pipelines depend on it, which credentials it can access, and which systems consume its artifacts? Those answers determine the scope of a potential incident.
3. How to mitigate and reduce risk
Establish exposure and close the vulnerable paths
Inventory self-hosted instances, including development systems, older deployments, and alternate routes through proxies or load balancers.
Record each instance’s version, network exposure, owner, and patch history. Use the current vendor advisory to select an appropriate fixed release for the relevant branch. JFrog states that affected cloud environments have already been fortified and require no customer action. JFrog security advisories
Restrict unnecessary access to administrative services while remediation proceeds. Coordinate changes with application owners so controls do not unexpectedly break legitimate integrations or cluster communication.
Preserve the evidence needed to investigate
Preserve Artifactory and Access audit logs, reverse-proxy or WAF logs, endpoint telemetry, and relevant configuration history.
Keep original request paths alongside normalized versions. A trailing slash can matter to this investigation, and normalization can erase that distinction.
Do not enable indiscriminate logging of authorization headers or token bodies. Where sensitive evidence already exists, restrict access and handle it as credential material.
Investigate access that could survive an upgrade
Review:
Newly created administrators and unexpected permission changes.
Tokens issued during the suspected exposure period.
Changes to plugins, authentication settings, and cluster trust.
Unexpected processes, files, or outbound connections on repository hosts.
Repository and artifact changes associated with suspicious identities.
For affected credentials, plan revocation or rotation with the owners of dependent services. Cluster keys and integration credentials require coordination to avoid disrupting legitimate operations.
Where an attacker executed code on the host, assess whether rebuilding from a trusted baseline is necessary. Removing a visible account or file does not establish that all persistence has been removed.
Define what “resolved” means
A useful closure record should explain:
Which instances were exposed and when.
Which fixes and access restrictions were applied.
Which identities, credentials, hosts, and artifacts were investigated.
What suspicious activity was found and addressed.
Which logging gaps limit confidence.
An upgrade demonstrates remediation of the vulnerable software. The investigation supplies evidence about what happened before that remediation.
4. How to hunt the activity
The hunting objective is to reconstruct behavior across three stages:
Token or join request → authority obtained → privileged actionStart with endpoint discovery, then connect the results to audit and endpoint evidence.
For CVE-2026-42018, Wiz describes a particularly strong pattern: the same client receives 401 on the bare AWS-token path, then 200 on a variant such as the trailing-slash path shortly afterward. Wiz’s detection guidance
Across platforms, retain timestamps, destination, client address, method, original path, response status, actor, and request or session identifiers when available.
Client IP is a useful pivot, but shared proxies and NAT can put unrelated users behind the same address. Strengthen correlations with identity and request context.
These queries are starting points. Map the telemetry and field names to your environment, then validate against known events before using the results for incident decisions.
Microsoft Sentinel: find relevant HTTP requests
This example assumes HTTP events are available in CommonSecurityLog. Replace the example hostname with your instance’s logged destination name and choose a time range covering its possible exposure.
let StartTime = ago(30d);
let ArtifactoryHost = "artifactory.example.com";
CommonSecurityLog
| where TimeGenerated >= StartTime
| where DestinationHostName =~ ArtifactoryHost
| where RequestMethod =~ "POST"
| where RequestURL contains_cs "/access/api/v1/aws/token"
or RequestURL contains_cs "/access/api/v1/tokens"
or RequestURL contains_cs "/access/api/v1/registry/join"
or RequestURL contains_cs "/artifactory/api/security/token"
| project
TimeGenerated,
DestinationHostName,
SourceIP,
SourceUserName,
RequestMethod,
RequestURL,
RequestClientApplication,
DeviceAction,
AdditionalExtensions
| order by TimeGenerated ascThis retrieves candidate requests, including failures and legitimate activity. HTTP response status is connector-dependent; map its actual field before adding success filters. The standard schema provides the other fields used above. CommonSecurityLog reference
For each candidate, inspect adjacent events from the same client and destination. Look for the failed-to-successful path variation, subsequent token issuance, and privileged actions by the associated identity.
The query uses substring matching to retain path variants. Kusto’s has_any matches terms and is unsuitable for enforcing a complete URL path match. Kusto string operators
Falcon LogScale / Next-Gen SIEM: discover the same requests
Select the repository or view containing Artifactory HTTP, proxy, or WAF logs. Scope it to the relevant destination and exposure period using your parser’s fields and the time selector.
This example searches the raw event because parsed HTTP field names vary:
@rawstring = /\/access\/api\/v1\/(aws\/token|tokens|registry\/join)|\/artifactory\/api\/security\/token/
| table([@timestamp, @rawstring], limit=1000)The output uses LogScale’s table() syntax. Expand the selected columns with the source address, destination, method, status, and identity fields supplied by your parser. LogScale table reference
These HTTP logs must be ingested; Falcon endpoint telemetry alone does not guarantee visibility into the requests.
Inspect the matching timeline before restricting it to successful responses. Failures can reveal the path probing that makes a later success meaningful. If the result reaches the table limit, narrow the interval or export the relevant results so truncation does not hide activity.
Once a suspicious interval is identified, pivot into endpoint process and file telemetry for that Artifactory host.
Splunk: normalize fields and preserve the timeline
Replace YOUR_ARTIFACTORY_HTTP_INDEX with an index containing HTTP events for the deployment under investigation. Set the search time range to its possible exposure period.
index=YOUR_ARTIFACTORY_HTTP_INDEX
| eval method=upper(coalesce(http_method, method, request_method))
| eval path=coalesce(uri_path, uri, url, http_uri)
| eval client=coalesce(src_ip, src, clientip, client_ip)
| eval http_status=tonumber(coalesce(status, http_status, status_code))
| eval actor=coalesce(user, user_name, username)
| where method="POST"
AND (
like(path, "%/access/api/v1/aws/token%")
OR like(path, "%/access/api/v1/tokens%")
OR like(path, "%/access/api/v1/registry/join%")
OR like(path, "%/artifactory/api/security/token%")
)
| table _time host dest client method path http_status actor
| sort 0 _timeCheck the field mapping against a known event before relying on the result. The normalization accommodates several common names, but your data may use others. Splunk’s CIM Web model provides a useful reference for HTTP fields. Splunk CIM Web documentation
Preserve the event timeline during initial triage. Aggregating immediately into counts by IP can conceal whether requests occurred in the order required for the attack.
For suspicious clients, expand into audit logs and review subsequent token issuance, account creation, and permission changes.
Kibana: filter HTTP events in Discover
This example uses Kibana Query Language, with Elastic Common Schema fields. Replace the hostname and set the global time range to the relevant exposure period.
server.domain: "artifactory.example.com"
AND http.request.method: POST
AND url.path: (
/access/api/v1/aws/token*
OR /access/api/v1/tokens*
OR /access/api/v1/registry/join*
OR /artifactory/api/security/token*
)Add these Discover columns:
@timestamp
source.ip
server.domain
url.path
http.response.status_code
user.name
user_agent.originalKibana KQL filters events; it does not itself correlate a sequence or aggregate results. The query uses trailing wildcards and requires fields mapped to your data. Elastic KQL documentation
Sort chronologically and inspect each candidate’s surrounding activity. Pivot into application audit data separately: requiring an HTTP method on every search could exclude audit records that have no HTTP fields.
A Lens chart can help identify bursts, but return to the underlying events before drawing a conclusion.
Interpret the results before escalating
A matching endpoint establishes that a request occurred. Additional evidence determines its meaning.
Finding | Next investigative step |
Failed requests to a token endpoint | Check whether the same client later succeeded using a path variant. |
Successful token or join requests | Establish the caller, expected purpose, and authority issued. |
Anonymous identity performing administrative actions | Verify the action’s outcome and trace the associated requests and credentials. |
Unexpected administrator or permission change | Identify the creator, approval history, and subsequent use. |
Suspicious host activity near the request sequence | Correlate process lineage, file creation, and outbound connections on the affected host. |
Avoid escalating solely because a process mentions /tmp, a username resembles a service account, or a request uses a particular User-Agent. These can be useful pivots, but they need context.
Also validate negative results. An empty search may mean there was no matching activity, or it may mean the required logs were never collected, the fields differ, or retention does not cover the exposure period.
Put the lesson to work
The durable detection opportunity is an identity exercising authority it should not have.
Apply that reasoning beyond Artifactory: establish the identity’s expected permissions, identify the action it performed, and investigate the mismatch. Then follow the consequences into credentials, configuration, host activity, and the systems that depend on the service.
For teams using Microsoft Sentinel and Defender, Inception Security can help connect those investigative questions to the telemetry already available. An Inception Foresight M365 Assessment can help identify visibility and detection gaps that affect that work.
