critical

CVE

CVE-2026-82329, CVE-2026-42018, CVE-2026-42016

CWE

CWE-287, CWE-863, CWE-400

Affected Surface

  • Self-hosted JFrog Artifactory instances on vulnerable branches that front Maven, npm, PyPI, Docker, Helm, or generic build-artifact flows
  • Developer workstations, CI runners, and internal package consumers that trust artifacts served by a compromised Artifactory instance
  • PyPI consumers that installed or imported `python-fork` versions `0.1.0` or `0.1.1` on 12 September 2026 before PyPI quarantine took effect

Welcome to Corgea’s weekly briefing. The briefing covers the most important security findings and research from the week.

This edition covers research published from Wednesday, 10 September through Sunday, 13 September 2026, excluding incidents that Corgea had already covered before this window opened.

Top Article

CVE-2026-82329, CVE-2026-42018, and CVE-2026-42016: active JFrog Artifactory exploitation turns package hubs into an admin foothold

The highest-signal change in the 10 to 13 September window is not a new package name landing on npm or PyPI. It is fresh public reporting that self-hosted JFrog Artifactory is under active exploitation across three flaws that matter to the same trust boundary package-security teams rely on every day.

Two exploit paths are now public. The first is CVE-2026-82329, where a forged cluster-join token can produce an admin credential through /access/api/v1/registry/join. The second is the CVE-2026-42018 plus CVE-2026-42016 chain, where an internal anonymous-user token leaks even when anonymous access is disabled and then reaches admin scope because token scope is not enforced. CISA’s 11 September KEV update and Wiz’s incident reporting are enough to move this from “watch the advisory” into the same response lane as a registry compromise. If your teams pull Maven, npm, PyPI, Docker, or Helm artifacts through Artifactory, that service is part of your software supply chain whether or not it lives inside your perimeter.

More news

python-fork on PyPI: a quarantined package with a malicious import path

The smaller package story in this window is python-fork, a PyPI package that went live on 12 September with versions 0.1.0 and 0.1.1 before PyPI quarantined the project. The public project page still shows both files and their hashes, plus the fact that they were uploaded with trusted publishing metadata through twine/7.0.0.

The machine-readable malicious-package record and the upstream analyst page both describe the same behavior in plain terms:

import python_fork
  -> fork bomb starts
  -> process count spikes
  -> system resources are exhausted

This is not the broadest supply-chain event of the month, but it is the sort of small package that can still hurt developer laptops, CI sandboxes, or build containers because the trigger is import-time execution instead of an obvious command-line action. There is no clean upgrade path here. The safe action is to block both versions, remove them from any environment that fetched them, and treat machines that imported the package as potentially unstable until you confirm the process table and service state are clean.

Other news

  • The requested Aikido, Socket, and Endor Labs feeds were still valuable in this run, but most of their latest September supply-chain coverage in this exact window was follow-up analysis on incidents Corgea had already published, especially earlier Shai-Hulud and package-worm activity.
  • We did not find a second new npm, PyPI, Maven, or Linux incident first disclosed in the 10 to 13 September window that cleared the same bar for a separate Corgea article without becoming duplicative.
  • If you are catching up on adjacent risk from the last two weeks, the most relevant carry-over remains the 8 September briefing, the 5 September briefing, and the recent stand-alone articles on StyleSmuggler and the Shai-Hulud return to npm.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References