CVE-2026-82329 — what is happening in your pipelines
CVE-2026-82329 is an authentication bypass in the REST API component of JFrog Artifactory. With a CVSS 3.1 score of 9.8 (critical), it allows a remote, unauthenticated attacker to completely bypass access controls: they can read, write and delete artifacts in any Maven, npm, Docker or other repository. The flaw was reported to JFrog in late July 2026, and Fastly collected evidence of active exploitation as early as August 25. On September 2, CISA added it to its Known Exploited Vulnerabilities catalog, meaning malicious actors are using it at scale, not merely as a proof of concept. In a CI/CD context, a compromised Artifactory repository is a direct entry point into every environment that pulls its dependencies from that server: the next build becomes the propagation vector.
The Rust backdoor: CVE-2026-42016 and CVE-2026-42018
Incidents documented by SecurityWeek and The Hacker News reveal a two-stage chain. CVE-2026-42016 first exploits CVE-2026-82329 to drop a Rust executable into a package in the targeted dependency chain. CVE-2026-42018 describes the malicious behavior of that executable: encrypted C2 connection, exfiltration of environment tokens (CI_JOB_TOKEN, DOCKER_AUTH_CONFIG, Vault secrets) and persistence via a post-install hook. The attacker does not need to compromise the Artifactory server itself — they only need to write into a shared repository consumed by your GitLab runners, GitHub Actions or Jenkins. The next build downloads and executes the backdoor in the pipeline context, with all secrets injected by your CI. The vector bypasses classic antivirus analysis because the Rust binary presents itself as a legitimate test tool.
Who is affected — versions and configurations
- Artifactory on-premises 7.x all editions (OSS, Pro, Enterprise) up to and including 7.84.17
- Artifactory on-premises 6.x: all versions (end-of-life branch, no patch planned)
- Artifactory Cloud (JFrog SaaS): patched by JFrog on August 28, 2026 — no action required
- Artifactory on Kubernetes (official Helm chart): the image version determines the vulnerability, not the chart version
- Instances exposing the REST API to the Internet via a reverse proxy: immediate and confirmed risk
- Internal-network-only instances: reduced but non-zero risk — lateral movement post-breach is documented
Emergency triage — 4 steps before patching
Check the installed version
Go to Administration → General → About or run: curl -u admin:PASSWORD http://localhost:8082/artifactory/api/system/version. If the version returned is below 7.84.18, the instance is vulnerable. Note the exact number for the update procedure.
Search for indicators of compromise (IOC)
Check your logs ($ARTIFACTORY_HOME/var/log/artifactory-request.log) for anonymous POST requests on /api/storage/, /api/deploy/ or /api/conan/. An unusual volume of 401 responses followed by a 201 or 200 with no known user-agent is a strong signal. Compare the hashes of your critical packages with the expected values in your SBOM or lockfile.
Isolate the instance if compromised
If you detect suspicious artifacts, block inbound access on ports 8081 and 8082 (ufw deny in 8081 / 8082) and revoke all existing API tokens. Preserve logs before patching — they are the evidence needed for forensic analysis. Notify your CI teams to avoid any build pulling dependencies from the instance until triage is complete.
Audit consuming CI pipelines
List all pipelines pointing to your Artifactory. For each build triggered between August 25 and today, verify the downloaded artifacts, binaries executed during the test phase, and tokens potentially exposed. As a precaution, rotate all CI secrets injected into runners that pulled dependencies from the suspect instance.
Patching Artifactory — official JFrog procedure
JFrog released the fix in version 7.84.18 for the 7.x branch. For an RPM or DEB installation, stop the service (systemctl stop artifactory), replace the package (yum update jfrog-artifactory-pro or apt-get install --only-upgrade jfrog-artifactory-oss), verify configuration file integrity in $ARTIFACTORY_HOME/var/etc/artifactory/, then restart. Downtime is typically 5 to 10 minutes depending on the size of your Derby or PostgreSQL database. For Helm deployments, update the image tag to releases-docker.jfrog.io/jfrog/artifactory-oss:7.84.18 and run helm upgrade. The 6.x branch is no longer maintained: upgrading to 7.84.18+ is the only supported option — a WAF workaround is not sufficient.
A lasting alternative: Gitea Packages
If you run Artifactory mainly as a package registry for your CI/CD pipelines, Gitea Packages covers the same functional scope since version 1.20 without Enterprise license fees or a shared attack surface. Gitea Packages natively supports Maven, npm, Docker, PyPI, Cargo (Rust), Go modules, NuGet, Debian, RPM, Helm and Composer, all accessible via the standard URLs expected by your tools (mvn, npm, pip, docker, cargo). Authentication uses existing Gitea tokens, organization permissions and deploy keys — the same primitives as your Git forge. A self-hosted Gitea instance gives you full control over retention, policy webhooks and OIDC integration, without relying on a third-party vendor for your production artifacts.
Artifactory OSS vs Gitea Packages — practical comparison
Scroll the table
| Criterion | Artifactory OSS 7.x | Gitea Packages 1.21 |
|---|---|---|
| Supported formats | Maven, Gradle, npm, PyPI, Docker, Helm, Conan | Maven, npm, Docker, PyPI, Cargo, Go, NuGet, Debian, RPM, Helm, Conan |
| License | SSPL (commercial cloud usage restrictions) | MIT — free for any use |
| Minimum infra | 4 vCPU / 8 GB RAM recommended | 2 vCPU / 4 GB (team ≤ 10), 4 vCPU / 8 GB (active team) |
| Critical CVEs (24 months) | CVE-2024-45793, CVE-2025-11345, CVE-2026-82329 | 0 critical CVEs in the period |
| Unified forge + registry auth | No — separate IAM | Yes — same token, same Gitea org |
| Installation time | 30-60 min (JVM, DB config) | < 15 min (single binary or Docker image) |
Deploy Gitea on a VPS and configure the registry
Provision the VPS
Choose a VPS with at least 2 vCPU and 4 GB RAM for a small team, 4 vCPU and 8 GB for an active team with large Docker layers. The preconfigured Gitea image in the ServOrbit catalog starts Gitea, PostgreSQL and an nginx reverse proxy with Let's Encrypt TLS in a single cloud-init command. Once the VM is up, point your domain (e.g. gitea.yourcompany.com) to the VPS IP.
Complete the Gitea installation
Go to https://gitea.yourcompany.com/install. Fill in the PostgreSQL connection (host localhost, database gitea, user gitea), disable public registration if your instance is internal, enable mandatory 2FA for administrators. Packages are enabled by default since v1.20 — no additional configuration needed.
Configure the npm, Maven or Docker registry
For npm: npm config set @YOUR_ORG:registry https://gitea.yourcompany.com/api/packages/YOUR_ORG/npm/ then add a Gitea token in ~/.npmrc. For Maven: add the repository in settings.xml pointing to https://gitea.yourcompany.com/api/packages/YOUR_ORG/maven. For Docker: docker login gitea.yourcompany.com and tag your images as gitea.yourcompany.com/YOUR_ORG/my-image:tag.
Secure network access
Restrict access to the packages API to your CI runner IP ranges (ufw rule or cloud security group). Enable forced HTTPS in app.ini ([server] REDIRECT_OTHER_PORT = true). Configure Gitea webhooks to notify your SIEM on every package publication. Enable automatic retention policy for old versions to avoid Docker layer accumulation.
Migrating your artifacts from Artifactory
Migration can be done gradually without cutting existing pipelines. Start with the least critical repositories — typically internal npm libraries or private Python packages. Publish new versions directly to Gitea Packages, then update the references in your lockfiles (package-lock.json, requirements.txt, pom.xml). For Maven, update the repository URL in settings.xml and run mvn deploy on your current snapshots. For Docker, retag existing images with docker tag and push them to the new registry with docker push gitea.yourcompany.com/ORG/IMAGE:TAG. Images are identical — only the registry FQDN changes in your docker-compose.yml files and Kubernetes manifests. Plan a one-to-two-week coexistence window: both registries run in parallel, letting you switch pipelines one by one and roll back if needed.
Post-migration check: run an SBOM scan (syft or grype) on artifacts published in Gitea to confirm no suspicious binary followed the migration. Test pip install, npm install, docker pull and mvn dependency:resolve from a clean environment pointing exclusively at the new registry. If all builds pass and the SBOM is clean, revoke access to the old Artifactory instance and remove its credentials from CI secrets.
