CVE-2026-42018: JFrog Artifactory Improper Authentication Vulnerability
JFrog Artifactory contains an improper authentication vulnerability that could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled, potentially exposing sensitive resources.
Overview
JFrog Artifactory contains an improper authentication flaw in its AWS token endpoint that issues a valid internal anonymous-user JWT to any unauthenticated caller, even when anonymous access is explicitly disabled. An attacker with network access to a vulnerable self-hosted instance can obtain this token and use it to read artifacts or repository data accessible to the anonymous identity. Wiz Research confirmed active in-the-wild exploitation, with attackers chaining this flaw with a separate privilege-escalation vulnerability to reach full administrative control. All Artifactory versions below 7.111.20, 7.117.27, 7.125.19, 7.133.28, or 7.146.8 are affected.
Vulnerability details
CWE-287 (Improper Authentication) describes a failure to correctly verify a caller's identity before granting access. Here, Artifactory's AWS token endpoint fails to enforce the configured policy that disables anonymous access. A trailing slash appended to the endpoint path bypasses the authentication check entirely, and the server responds with a signed JWT representing the internal anonymous user. The flaw is present regardless of whether an administrator has disabled anonymous access, meaning a security control that appears active provides no protection against this specific request path.
An attacker sends an unauthenticated HTTP POST to /access/api/v1/aws/token/ (with a trailing slash) over the network to a vulnerable Artifactory instance. The server returns HTTP 200 with a signed anonymous-user JWT. Wiz Research observed this token subsequently submitted to /access/api/v1/tokens to exploit a separate scope-validation flaw, escalating the anonymous token to admin-scoped access in a two-step chain. Observed post-exploitation activity included creation of persistent administrator accounts, deployment of malicious Groovy plugins for code execution, and installation of Rust-based backdoors. The instance must be running an affected version and must have anonymous access configured as disabled for the flaw to fire.
Severity and impact
Exploitation status
This vulnerability is confirmed as actively exploited in the wild — it is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
Detection and monitoring
- Monitor Artifactory access logs for POST requests to
/access/api/v1/aws/token/with a trailing slash that return HTTP 200, particularly from source IPs with no prior authenticated session in the same instance. - Alert on token issuance events where the resulting token carries the anonymous username (
token:anonymous) but is subsequently used to perform write or administrative operations such as PUT requests to/api/security/users/or/access/api/ui/users/. - Audit Artifactory user-management logs for newly created administrator accounts created within minutes of an anonymous-user token issuance event, which Wiz Research observed occurring in under five minutes during confirmed exploitation.
Remediation
Additional hardening
- Upgrade Artifactory to 7.111.20, 7.117.27, 7.125.19, 7.133.28, or 7.146.8 (or later within each release line) to address the authentication bypass. See References for the vendor advisory and release notes.
- Restrict network access to Artifactory's API endpoints at the perimeter or load-balancer layer, limiting inbound connections to known CI/CD systems and authorized client IP ranges rather than exposing the instance broadly.
- Audit all administrator accounts and Groovy plugins currently installed on any instance that was internet-reachable while running an affected version, as Wiz Research confirmed post-exploitation persistence through both mechanisms.
- Review Artifactory audit logs for requests to
/access/api/v1/aws/token/and/access/api/v1/tokensoriginating from unauthenticated or anonymous sessions, and treat any confirmed hit as an indicator of compromise requiring full forensic triage.
Key dates
References
- https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases
- https://docs.jfrog.com/releases/docs/jfrog-security-advisories
- https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
- https://nvd.nist.gov/vuln/detail/CVE-2026-42018
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-42018
- https://www.wiz.io/blog/artifactory-under-attack-in-the-wild-exploitation-of-cve-2026-42016-cve-2026-4201
Frequently asked questions
Does CVE-2026-42018 affect my FedRAMP authorization?
If JFrog Artifactory runs inside your authorization boundary, CVE-2026-42018 directly affects your Federal Risk and Authorization Management Program (FedRAMP) authorization. CISA has listed this vulnerability in its Known Exploited Vulnerabilities catalog with a remediation deadline of September 25, 2026. An unpatched KEV inside your boundary is an assessor finding: you must remediate it or formally document a mitigation before your assessor and sponsoring agency raise it.
How does Knox help me handle CVE-2026-42018?
Knox does not patch JFrog Artifactory on your behalf. Under the FedRAMP shared-responsibility model, remediating this vulnerability is your obligation. What Knox provides is the pre-authorized, single-tenant boundary in which you carry out that remediation, along with continuous compliance monitoring and audit-artifact coverage to document the fix for your next assessment. The work of applying the patch is yours; maintaining a compliant posture while you do it is not something you manage on your own.
How does Knox's monitoring help with vulnerabilities like this?
Knox's automated continuous monitoring platform watches your environment for newly disclosed vulnerabilities and compliance issues on an ongoing basis. That means exposure to something like CVE-2026-42018 surfaces during routine monitoring rather than only when an assessor flags it at review time, giving your team earlier visibility and more time to act.
How do I get FedRAMP authorized with Knox?
Knox runs a FedRAMP-as-a-Service platform. It gives SaaS vendors a pre-authorized cloud boundary on AWS, Azure, and GCP. Your application inherits 60-80% of the required security controls. You reach FedRAMP authorization in about 90 days for roughly 90% less than the traditional $3.5M path. Book a meeting and Knox will map your path to authorization.
What happens if CVE-2026-42018 isn't remediated by September 25, 2026?
An unremediated CVE-2026-42018 becomes a Plan of Action and Milestones (POA&M) item. A growing POA&M list is what turns a routine continuous-monitoring review into a difficult conversation with your sponsoring agency. Closing the item and documenting the remediation is what keeps your authorization intact and the agency relationship clean.
Ready to achieve FedRAMP authorization in 90 days or less?
Schedule a meeting to discuss scope, parse readiness, and map your company’s accelerated path to FedRAMP authorization.
_Horizontal_RGB.png)
