Three Artifactory vulnerabilities are being actively exploited against Internet-accessible, self-hosted deployments, with attackers chaining flaws to bypass authentication, escalate privileges, and reach administrator access in under five minutes. Security company Wiz.io says the issue can lead to credential theft, arbitrary code execution, persistence, and anti-forensics once a vulnerable instance has been exposed.
What attackers are doing with the Artifactory flaws
The campaign described by Wiz.io targets self-hosted JFrog Artifactory instances that are reachable from the internet. According to the disclosure, attackers are using a small number of unauthenticated HTTP requests to take control of systems, which makes the chain especially dangerous in environments that treat Artifactory as a trusted internal service.
Wiz.io warned that if an instance was exposed while vulnerable, operators should assume compromise rather than assume that patching alone will remove the attacker. As the company put it, “Upgrading closes the door but does not evict an attacker who is already inside […].”
Once access is established, observed post-authentication actions include creation of persistent administrator accounts, deployment of malicious Groovy plugins for code execution, harvesting of credentials and Access signing keys, backdoor installation, and anti-forensics measures intended to hide activity.
The three CVEs behind the exploitation chain
The active exploitation involves three vulnerabilities, two rated high severity and one rated critical. Wiz.io identified them as:
- CVE-2026-42018 — high severity; Artifactory may return an internal anonymous-user token to an unauthenticated requester, even when anonymous access is disabled.
- CVE-2026-42016 — high severity; Artifactory fails to properly validate a request token, allowing a low-privileged attacker with a valid token to perform unauthorized actions and gain elevated privileges.
- CVE-2026-82329 — critical severity; allows an unauthenticated attacker to obtain administrative control.
According to the disclosure, the first two vulnerabilities can be chained to obtain persistent administrative access. The third flaw can be used independently to obtain an admin-scoped token directly.
How the chain works in practice
Wiz.io described a repeatable attack pattern seen in the wild. First, an unauthenticated request is sent to POST /access/api/v1/aws/token/ with a trailing slash, which returns HTTP 200 and a JWT for the internal anonymous user. That behavior corresponds to CVE-2026-42018.
The attacker then exchanges that JWT for an admin-scoped token using POST /access/api/v1/tokens. That request also returns HTTP 200 and exploits the scope-validation weakness in CVE-2026-42016. The resulting token still appears to belong to the anonymous user, but it carries administrative authority, which means later requests may show an actor of token:anonymous even when the attacker has full control.
Wiz.io said that in some observed cases, attackers completed exploitation and established administrative access in under five minutes. That speed matters because it leaves defenders little time to detect suspicious behavior before the system is fully compromised.
Why Artifactory is a high-value target
Artifactory is widely used as a central repository in software delivery pipelines, which makes it a sensitive part of the software supply chain. If an attacker controls Artifactory, they may be able to manipulate artifacts, steal secrets, or plant malicious components that later move through development and deployment systems.
That supply-chain role is why the exploitation has drawn attention beyond the usual vulnerability alert cycle. As cybersecurity specialist Erik York commented on LinkedIn, “Artifactory sits at the center of a LOT of software supply chains. This is exactly the kind of bug that turns into next year’s SolarWinds story if it’s not patched fast.”
Jim Nitterauer, senior director of information security at Graylog, also emphasized the broader operational risk. He said, “Because Artifactory sits at the heart of software build pipelines, a compromise is a direct supply-chain risk and patch adoption has lagged badly, with attacks observed within four days of disclosure of the third bug.”
What defenders should look for
The fact that exploitation can begin with simple unauthenticated requests means defenders should review logs for unusual calls to the affected endpoints, especially on systems exposed to the internet. Because the exploit chain can create an admin-scoped token that still appears associated with the anonymous user, traditional account-based detection may miss the compromise if teams do not inspect request patterns and resulting privilege changes.
Potential signs of compromise include unexpected administrator account creation, changes to repository settings, unfamiliar Groovy plugins, unusual outbound connections, and evidence of credential or signing-key access. Anti-forensics activity may also make the incident harder to reconstruct, which is another reason Wiz.io recommends treating exposed vulnerable systems as compromised until proven otherwise.
Organizations relying on Artifactory should also review whether the instance was reachable externally during the vulnerable period. Even if the server is now patched, defenders should still investigate whether an attacker established persistence before the update was applied.
Patch guidance for affected Artifactory instances
Wiz.io said all Artifactory self-hosted environments should be immediately patched to a version that fixes the vulnerabilities. The specific fixed releases listed in the disclosure are 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, and 7.161.20, or newer depending on the deployed release branch.
In practice, that means administrators need to determine which branch they are on and move to the appropriate fixed build as soon as possible. Because the vulnerabilities are under active exploitation, the usual advice to “patch when convenient” does not apply here.
Defenders should also consider the response steps that follow patching. A security update is necessary, but not sufficient, if an attacker already gained access. Password resets, token revocation, signing-key review, repository integrity checks, and a search for malicious plugins or unexpected administrative accounts should all be part of the response plan.
Why this incident matters beyond one product
The Artifactory case is another reminder that build and artifact management systems are high-impact infrastructure. They are often trusted by default, connected to many downstream systems, and difficult to monitor at the same granularity as public-facing applications. That combination makes them attractive targets for attackers seeking long-term access or leverage over a software supply chain.
The speed of exploitation reported by Wiz.io also underscores a familiar security pattern: once a reliable chain becomes public, attackers move quickly. For organizations that host Artifactory internally, the exposure is not limited to a single application server. It can extend to the code, credentials, and artifacts that flow through it.
For now, the most important message is straightforward. If your Artifactory self-hosted deployment was internet-accessible and running an affected version, it should be patched immediately and investigated for signs of compromise.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: September 29, 2026 at 10:34 pm
0 views
