01Two dormant JFrog Artifactory bugs, patched weeks ago, are now confirmed chained into full admin takeover. Wiz Research documents in-the-wild exploitation, running 15 August–8 September 2026, of two distinct JFrog Artifactory flaws, CVE-2026-42018 (an unauthenticated caller can obtain an internal anonymous-user token) and CVE-2026-42016 (that token's scope is not validated when exchanged for a new one), chained into an unauthenticated-to-admin escalation in two HTTP requests, in some cases reaching a created administrator account in under five minutes. Both CVEs were disclosed and patched by JFrog in July and August, weeks before this exploitation was reported; six weeks after disclosure, 59% of organizations running Artifactory remained vulnerable to CVE-2026-42016, and CVE-2026-42018 fell only from 69% to 62% over four weeks. →
02GitLab's maximum-severity file-read flaw went from patch to in-the-wild probing in about 24 hours. GitLab shipped 19.3.2, 19.2.6 and 19.1.8 on 2026-09-10, fixing CVE-2026-85706 (CVSS 10.0): improper path confinement and missing authentication enforcement in the repository commits API let an unauthenticated user read arbitrary files from the GitLab server. Every self-managed CE/EE install from 18.7 up to those releases is affected; watchTowr's global honeypot network recorded behavioral exploitation probes against the flaw within roughly a day of disclosure, and CISA added it to its Known Exploited Vulnerabilities catalog on 2026-09-11. →
03ConnectWise patches a ScreenConnect flaw Huntress had already watched turn every infected connection into the next one's launch point. CVE-2026-84869 (CVSS 9.9) lets file-transfer actions inside an already-active ConnectWise ScreenConnect remote session run without the authorization or Host-confirmation step the product is meant to require. Huntress documented exploitation from 20 August 2026, over two weeks before ConnectWise's 8 September patch (26.6.5), in which a modified ScreenConnect client automatically pushes the same infection chain to every newly connected Host session, giving the bug a worm-like spread across an MSP's or IT department's own remote-support connections. →
Japan's Digital Agency confirmed on 2026-09-11 that Government Solution Service (GSS) (the shared PC, network and authentication environment it provisions to government ministries, independent administrative agencies and their contractors) suffered an intrusion that may have exposed personal data on roughly 246,000 individuals (Jiji Press, 2026-09-11): about 236,000 names, 231,000 email addresses, 94,000 phone numbers and 1,000 addresses, with duplication across fields (Piyolog, 2026-09-11). The agency states no National ID, bank-account or pension data was involved, and no general citizen data, only GSS-using-agency staff, associated public servants, and contracted businesses (Rocket Boys Security Measures Lab, 2026-09-11). No secondary misuse has been confirmed as of the disclosure date (Piyolog, 2026-09-11).
The root cause was a third party exploiting a vulnerability in an externally-facing VPN appliance used for maintenance access, gaining a foothold from around late May 2026 (Piyolog, 2026-09-11). The intrusion was not detected from the VPN compromise itself: on 25 June, the agency detected suspicious access from the account of a system maintenance administrator, and only through the subsequent investigation confirmed on 9 July that an external party had repeated unauthorized access since late May (Jiji Press, 2026-09-11). The agency disabled the account and cut the compromised device's external connectivity the same day, then patched the VPN appliance as an initial response (Piyolog, 2026-09-11); roughly two and a half months of investigation with an external forensics firm preceded the public announcement.
At the 2026-09-11 press conference, Digital Minister Matsumoto stated the exploited vulnerability was already known to the agency before the intrusion, rated at around "Medium" severity in the vulnerability assessment published at the time, and was being remediated on a severity-based schedule when it was exploited ahead of that fix being applied (Digital Agency Q&A, relayed by Piyolog, 2026-09-11). The agency stated it will review its vulnerability-management approach as a result, without disclosing specifics on what will change (Rocket Boys Security Measures Lab, 2026-09-11).
The agency said it detected suspicious access from the account of a system maintenance administrator on June 25. It then began investigating the incident and found on July 9 that an external third party had repeated unauthorized access since around late May.
"We take it seriously that the incident occurred despite our operations under multi-layered security measures and a 24-hour-a-day, 365-day-a-year surveillance system," Chief Cabinet Secretary Minoru Kihara said at a press conference
The Digital Agency said that in the vulnerability assessment published at the time, the Common Vulnerability Scoring System rated the severity at around "Medium", and explained that it was exploited before a fix or patch had been applied (translated from Japanese)
The confidence this entry conveyed in its Admiralty rating was too high, and the reason matters for how a reader weighs it. Every fact here traces to one disclosure: the Digital Agency's 2026-09-11 press release and the accompanying press conference. Jiji Press, Piyolog and Rocket Boys Security Measures Lab each report that announcement; none of them examined the intrusion. Independent corroboration means a second party that observed or assessed the thing, not a second outlet that republished the first, so the credibility number is 2 (probably true, not independently confirmed) rather than 1. Nothing factual in the entry changes, the figures, the scope and the agency's statements were re-verified against the same sources and hold. What changes is that a reader should treat the account as the Digital Agency's own, still awaiting outside confirmation: the VPN vendor, the product, the CVE and whether the flaw was known and patched before the intrusion all remain undisclosed by any party.
The Digital Agency's statement on the flaw's severity is narrower than this entry first rendered it. Piyolog's account of the 2026-09-11 press conference reports the agency saying that the Common Vulnerability Scoring System rated the severity at around "Medium" in the vulnerability assessment published at the time, and that the flaw was exploited before a fix or patch had been applied (Piyolog, 2026-09-11). The qualification matters: the agency described the rating as it stood when first published, not as a settled assessment of the flaw.
ConnectWise's own disclosure describes a client-side condition in ScreenConnect Support and Access sessions where file-transfer actions could be processed through an active remote session "without proper authorization or Host confirmation," letting files be transferred to and executed on the Host system, including through elevated execution paths (ConnectWise, 2026-09-08). ScreenConnect servers are not affected, only client versions before 26.6.5, the release that fixes CVE-2026-84869 (CWE-862 Missing Authorization, CWE-269 Improper Privilege Management, CVSS 9.9).
Huntress had been tracking the exploitation for two and a half weeks before any advisory existed. Starting 20 August 2026, its SOC found rogue ScreenConnect clients deployed via social engineering (a fake tech-support Quick Assist session in one case, a phishing-driven MSI in another) that immediately spawned four chained VBScript stagers via wscript.exe. The stagers profile the host (existing ScreenConnect install, installed security-product names, available RAM to rule out a sandbox), then pull an AES-encrypted payload bundle keyed to that profile from Dropbox. Depending on the profile, the final PowerShell stage installs a ScreenConnect backdoor client concealed as a hidden Windows service, its registry Uninstall entry removed and a restrictive service security descriptor applied, builds a UAC-bypass helper via a hijacked ms-settings: protocol handler routed through ComputerDefaults.exe, sets AmsiUtils.amsiInitFailed = true to blind AMSI, adds all of C:\Users as a Defender exclusion, and disables Defender reporting, notifications and Hypervisor-Protected Code Integrity, the last of these via a vulnerable WinRing0 kernel driver dropped alongside the payload (Huntress, 2026-09-03). The broadest observed variant then drops a wstunnel tunneling tool disguised as Themes.exe and an XMRig cryptominer disguised as SearchIndex.exe.
The installed backdoor client is what turns the bug into a worm: it continuously inspects ScreenConnect's own connection-status collection for newly established Host sessions and, on each new connection, packages the same four VBScript stagers into a ScreenConnect file-transfer message flagged to auto-run, the exact abuse path CVE-2026-84869 patches. A technician's ScreenConnect client that has been infected this way silently re-infects every subsequent host it connects to, independent of the original social-engineering vector (Huntress, 2026-09-03). No named threat-actor cluster is attributed by any source; CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-09-11 with a three-day remediation deadline (CISA KEV, catalogue version 2026.09.11).
A condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ScreenConnect servers are not impacted.
This creates a worm-like behavior: propagating infections over new ScreenConnect connections. Connecting to an infected ScreenConnect client can cause the server-side Host system to receive and execute the same four-stage VBScript chain.
In late August, our Security Operations Center (SOC) sent out three critical incident reports for what looked like malicious ScreenConnect installation and unexpected process execution.
GitLab's own patch-release notes name the root cause plainly: "improper path confinement and missing authentication enforcement in the repository commits API" let an unauthenticated caller read arbitrary files from the server (GitLab, 2026-09-10). The vulnerability, CVE-2026-85706 (CVSS 10.0, scope-changed, no privileges or user interaction required), affects every self-managed CE/EE release from 18.7 up to 19.1.8, 19.2.6 and 19.3.2, the versions GitLab shipped on 2026-09-10; GitLab.com was already running the patched version, and GitLab Dedicated customers need no action. Depending on file permissions and deployment layout, an exposed file can include configuration data, secrets, tokens, SSH keys and database credentials, turning a file-read primitive into a foothold on the CI/CD and source-control plane GitLab manages (watchTowr, 2026-09-11). The flaw was reported through GitLab's HackerOne bug-bounty program by researcher s3ntago (GitLab, 2026-09-10).
watchTowr reproduced the vulnerability and validated exposure across client environments within roughly a day of GitLab's patch, and by 2026-09-11 its Attacker Eye honeypot network was already recording behavioral probes against the endpoint, meaning attackers had independently reverse-engineered a working exploit within roughly 24 hours of disclosure (watchTowr, 2026-09-11). CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-09-11 with a three-day remediation deadline (CISA KEV, catalogue version 2026.09.11), and NCSC Switzerland's own advisory, published earlier that same day, still recorded exploitation status as "unknown", illustrating how fast the status moved within a single day (NCSC Switzerland, 2026-09-11). The same release also fixed CVE-2026-87719 (CVSS 9.9), an insecure GraphQL-subscription deserialization issue that lets an authenticated user with Duo Chat access obtain Advanced Search configurations and credentials (GitLab, 2026-09-10); it is not KEV-listed, and NCSC Switzerland's advisory has since recorded it as exploited too (see the 2026-09-16 update below), though on materially thinner evidence than CVE-2026-85706's own KEV listing and honeypot corroboration.
GitLab has remediated an issue that, under certain conditions, an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API.
GitLab
watchTowr Intel is already seeing behavioral probes for this vulnerability against Attacker Eye, our global honeypot network, meaning attackers have already successfully reverse engineered and reproduced the vulnerability and the countdown to indiscriminate, in-the-wild exploitation is on.
Defenders should also hunt through log files for HTTP POST requests to “/api/v4/projects/{id}/repository/commits/” URIs containing “file.path” parameters to identify potential exploitation attempts.
NCSC Switzerland's own advisory, published 2026-09-11, independently confirms CVE-2026-87719 (CVSS 9.9, GitLab EE only) alongside CVE-2026-85706 in the same posting. GitLab's own release notes describe the flaw: "GitLab has remediated an issue that, under certain conditions, could allow an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument to bypass serialization and perform server object lookup" (GitLab, 2026-09-10). Affected versions are EE only, 18.3 up to the same 19.1.8/19.2.6/19.3.2 fixed releases already named in this entry; no exploitation is confirmed for this CVE. The same release also fixed CVE-2026-88765 (CVSS 8.5, GitLab EE only, sourced from GitLab's own release notes alone with no independent confirmation found): "GitLab has remediated an issue that, under certain conditions, could allow an authenticated user to achieve remote code execution by importing a specially crafted Git project export to overflow the Unicode conversion buffer used in Advanced Search indexing" (GitLab, 2026-09-10). This flaw's affected-version floor, EE 12.3, is substantially older than the other two flaws in this release, so any EE instance that has deferred upgrades for a long period carries the largest exposure window for this specific remote-code-execution path.
Audit logs for GraphQL subscription requests with abnormal argument shapes targeting Advanced Search, and for an Advanced Search reindex operation immediately following a Git project import from an external or untrusted source, are the discriminators for these two additional flaws.
NCSC Switzerland's Cyber Security Hub posting for this advisory was edited twice more inside this window. On 2026-09-14 the posting's own edit-history record states "CVE-2026-87719 is known as actively exploited" (NCSC Switzerland, 2026-09-14), moving the GitLab EE deserialization flaw from patch-available-only to exploited; that same-day posting carries no further detail on this CVE specifically (no campaign, no named cluster, no second source, and CISA's KEV catalog does not list it) so this status rests on NCSC Switzerland's own brief statement alone rather than the broader corroboration CVE-2026-85706 already carries. On 2026-09-15 the same posting was updated again, its status field now reading "Actively exploited, Proof of Concept available" for CVE-2026-85706 (NCSC Switzerland, 2026-09-15), and linking a public working proof-of-concept published the same day (guneykabel, 2026-09-15). No new affected-version information accompanies either update; GitLab 19.3.2/19.2.6/19.1.8 remain the fixed releases for both CVEs.
Any self-managed instance still unpatched should now be treated as likely already probed on both fronts: the file-read path with a public exploit script circulating, and, for any instance with Duo Chat-enabled accounts, the Advanced Search credential-exposure path CVE-2026-87719 opens.
ENISA confirmed on 2026-09-11 that the CRA Single Reporting Platform has deployed its initial operating capability, resolving the open point the prior update recorded. A Bitkom survey, relayed the same day by heise online, finds only 29% of German firms understand what the CRA means for their organization and that manufacturers could not register or test their reporting process before the platform went live with the reporting obligation itself.
The open point above is resolved: ENISA confirmed on 2026-09-11 that "the EU Agency for Cybersecurity (ENISA) has deployed the initial operating capability of the Single Reporting Platform (SRP)"
(ENISA, 2026-09-11),
manufacturers and, from 11 December 2027, open-source software stewards submit once through the platform and the receiving CSIRT disseminates the notification to every other Member State CSIRT where the affected product is available, simultaneously to ENISA.
A Bitkom survey of 1,003 German firms, relayed the same day by heise online, found only 29% know what the CRA means for their own organization and a further 38% have heard of it but cannot assess the impact; Bitkom specifically criticizes that manufacturers could not register on the platform or test their reporting process before today, "because the platform only went online with the start of the reporting obligation" (translated from German)
(heise online, 2026-09-11).
For a Swiss manufacturer or distributor placing networked products on the EU market, or a Swiss public-sector body procuring from an EU-regulated manufacturer now subject to this clock, the practical takeaway is that the 24-hour/72-hour/14-day-or-1-month reporting chain is a live obligation rather than a target date, and a first submission may hit friction precisely because pre-launch registration and testing were not possible.
Hunt.io names a first confirmed victim of the wider mass-exploitation wave against this same CVE, the Borough Council of King's Lynn and West Norfolk (UK local government), and reconstructs a technique distinct from UTA0533's earlier targeted intrusion: operators ran a standalone Linux build of Impacket's secretsdump directly on compromised SonicWall appliances against internal Windows hosts, reaching full DCSync replication in 5 of 250 targeted environments. This is reported as a materially broader, opportunistic wave, not attributed to UTA0533 or INC Ransom.
Hunt.io's analysis, relayed at length by Security Affairs, links the 17 July 2026 cyberattack on the Borough Council of King's Lynn and West Norfolk (UK local government) (with moderate confidence) to a wider mass-exploitation campaign against CVE-2026-15409, materially broader than the UTA0533-attributed targeted intrusion the earlier updates above describe (Security Affairs, 2026-09-11). Hunt.io's AttackCapture system crawled an operator's own unauthenticated open directory the same day the council disclosed, recovering the complete toolchain and campaign scope: 250 target appliances, 168 with LDAP configurations exposed (534 Active Directory accounts across 160 domains), 9 environments losing SAM/LSA secrets, and 5 losing their entire domain database via full DCSync replication against 7 domain controllers, with confirmed credential theft in France, India, Italy and the US and a broader target list spanning the UK, Canada, Germany, Sweden, Poland, Hungary, South Korea and Hong Kong. OffSeq's Threat Radar, an AI-generated summary tracker, carries the same campaign statistics in its own posting on the report (OffSeq Threat Radar, 2026-09-10), a repost rather than independent verification, since it traces to the same Hunt.io findings rather than a separate observation.
The technique this wave adds: operators ran a standalone Linux build of Impacket's secretsdump directly on the compromised SonicWall appliance itself against internal Windows systems, extracting SAM and LSA secrets and, where the harvested LDAP credentials lacked sufficient privilege to run DCSync directly, falling back to pass-the-hash DCSync replication using machine-account NTLM hashes recovered from those LSA secrets (Security Affairs, quoting Hunt.io, 2026-09-11). Running the credential-theft tooling from the appliance's own operating system, rather than from a foothold on a monitored Windows or Linux host, is the operative choice: "By 16 July 2026, two days after SonicWall disclosed CVE-2026-15409, a threat actor was using modified, multithreaded tooling to identify vulnerable SMA 1000 appliances, extract and decrypt LDAP credentials, and automate follow-on credential theft against internal Active Directory environments" (Hunt.io, quoted by Security Affairs, 2026-09-11). Scripts recovered from the directory carried extensive Chinese-language comments, which Hunt.io states is insufficient on its own for attribution; no link to UTA0533 or to INC Ransom is asserted in this reporting, treat it as a separate, broader post-disclosure scanning wave rather than the same operator.
Defender takeaway (delta only): organizations typically have far less process, file and network visibility into a VPN/firewall appliance's own operating system than into EDR-monitored Windows and Linux hosts, this wave specifically exploited that gap by running its credential-theft tooling on the appliance itself. Triage: where forensic capability allows inspecting the appliance's own filesystem and process history (not just its network logs), an unexpected standalone binary or interpreter process on the appliance (distinct from its normal service processes) run against internal LDAP/AD infrastructure is the signature this wave adds to the existing detection guidance above.
JFrog disclosed the two flaws separately and weeks apart, on 2026-07-27 and 2026-08-12, labelling each only "High" without a numeric score (JFrog, 2026-07-27). CVE-2026-42016 (CWE-863 Incorrect Authorization), disclosed 27 July 2026, is a privilege-escalation bug in Artifactory's token handling: the platform validates a token's signature and issuer but not the token's scope (JFrog, 2026-07-27). Wiz describes the consequence: a low-privileged token can be escalated to admin scope (Wiz Research, 2026-09-10). CVE-2026-42018 (CWE-287 Improper Authentication), disclosed 12–13 August 2026, is narrower but supplies the missing first step: Artifactory returns an internal anonymous-user token to a caller who never authenticated, even when anonymous access is disabled (JFrog, 2026-08-13). Neither flaw alone grants administrative control. Wiz Research states that the anonymous token from CVE-2026-42018 and the scope-validation gap in CVE-2026-42016 "together... can turn an unauthenticated request into an admin-scoped token in two steps" (Wiz Research, 2026-09-10).
Kill chain, as Wiz reconstructed it from real intrusions (initial access, T1190). An unauthenticated POST /access/api/v1/aws/token/ (with the trailing slash, since the bare path returns 401) returns HTTP 200 with a JWT scoped to Artifactory's internal anonymous identity, exploiting CVE-2026-42018 (Wiz Research, 2026-09-10). The operator then exchanges that JWT for a new one via POST /access/api/v1/tokens, which returns HTTP 200 carrying admin authority despite the request originating from the anonymous identity, exploiting CVE-2026-42016's missing scope check (T1550.001, forging elevated authority onto an application access token) (Wiz Research, 2026-09-10). The escalated token still shows token:anonymous as its actor in logs, and Wiz treats the internal anonymous identity, or any low-privilege identity, minting tokens, enumerating users or touching plugins as the anomaly to hunt (Wiz Research, 2026-09-10). Wiz observed actors reach a created administrator account in under five minutes from the first request in some cases (Wiz Research, 2026-09-10). CISA added both CVEs to its Known Exploited Vulnerabilities catalog on 2026-09-11 (CISA KEV, catalogue version 2026.09.11).
Post-exploitation observed across the chained cases. Operators create persistent administrator accounts via PUT /api/security/users/<username> or /access/api/ui/users/<username> (T1136.001); deploy malicious Groovy plugins through Artifactory's own extensible plugin framework to gain arbitrary code execution (T1505, abusing a legitimate server extension mechanism for persistence); and run ad-hoc shell commands through the plugin-execution endpoint (GET/POST /api/plugins/execute/<plugin>), used for reconnaissance and file enumeration (T1059) (Wiz Research, 2026-09-10). Across multiple cases Wiz observed a custom Rust-based backdoor with command-and-control capability dropped to disk as a further persistence layer (Wiz Research, 2026-09-10).
Wiz's own patching-velocity data is the second half of the defender-relevant finding: at first disclosure, 67% of organizations running Artifactory had at least one instance vulnerable to CVE-2026-42016, and a similar 69% for CVE-2026-42018; six weeks after CVE-2026-42016's disclosure, 59% remained vulnerable, and CVE-2026-42018 fell only from 69% to 62% over four weeks. The separately disclosed CVE-2026-82329 (an authentication bypass under default configuration, disclosed 28 August 2026) dropped from 67% to 49% within two weeks of its own disclosure (Wiz Research, 2026-09-10). Wiz attributes that faster remediation to CVE-2026-82329's critical severity rating, which likely drove more urgent attention from security teams (Wiz Research, 2026-09-10). The two high-rated flaws in this chain stayed unpatched for longer, and the exploitation Wiz reports began inside that window.
Contradiction: JFrog's CVE-2026-42018 table names 7.111.20, 7.117.27, 7.125.19, 7.133.28 and 7.146.8 as the patched builds, while its affected ranges on the last four branches end at those same builds (for example 7.117.0 to 7.117.27) (JFrog, 2026-08-13). Wiz corrected its fixed versions for this CVE on 2026-09-11 and lists 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20 (Wiz Research, 2026-09-10). Take the higher build. For CVE-2026-42016 JFrog names 7.133.11 as the only fixed build, so Wiz's 7.111.21, 7.117.28 and 7.125.20 remain inside JFrog's affected range for that flaw (JFrog, 2026-07-27).
Triage: the highest-confidence signal is behavioral rather than a single request: a 401 on the bare token path (/access/api/v1/aws/token without the trailing slash) followed by a 200 on a variant of it, such as the trailing-slash form, from the same client in a short window. That is an operator confirming the vulnerable variant before relying on it, and a normal client does not produce it (Wiz Research, 2026-09-10). Correlate any resulting anonymous-identity token activity against later user-creation, plugin-execution or credential-enumeration calls.
Wiz Research has identified active, in-the-wild exploitation of three critical and high-severity vulnerabilities affecting JFrog Artifactory: CVE-2026-42016, CVE-2026-42018, and CVE-2026-82329. Attackers are chaining these vulnerabilities to bypass authentication, escalate privileges, and gain administrative control over vulnerable Artifactory instances.
Between August 15 and September 8, 2026, we observed multiple actors chain CVE-2026-42018 and CVE-2026-42016 against self-hosted Artifactory instances. Across multiple cases we observed a custom Rust backdoor with C2 capabilities being dropped. Wiz Research is not aware of any prior public reporting of in-the-wild exploitation involving those two CVEs.
JFrog Artifactory (Self Hosted) versions before 7.133.11 are vulnerable to a privilege escalation attack due to a validation check of the token signature/issuer and not the token's scope.
Take the higher fixed build for CVE-2026-42018. JFrog's table names 7.111.20, 7.117.27, 7.125.19, 7.133.28 and 7.146.8 as the patched builds, while its affected ranges on the last four branches end at those same builds (JFrog, 2026-08-13). Wiz corrected its fixed versions on 2026-09-11 to 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20 (Wiz Research, 2026-09-10). CVE-2026-42016 is fixed only from 7.133.11, so an instance on the 7.111, 7.117 or 7.125 branch needs 7.133.11 or later to close CVE-2026-42016, on a build that also carries that branch's CVE-2026-42018 fix (JFrog, 2026-07-27). An instance that shows exploitation needs its Access token signing key and certificate reset as well as an upgrade, because a stolen key keeps forging valid tokens after patching (Wiz Research, 2026-09-10). JFrog's advisory page rates both flaws High and gives no numeric score (JFrog, 2026-07-27). The CVSS 8.1 and 7.5 figures shown earlier are not on that page and are no longer shown. A log hit counts as successful exploitation when both requests returned HTTP 200, as in every case Wiz observed (Wiz Research, 2026-09-10).
Upgrade every internet-facing SonicWall SMA1000 (6210/7210/8200v) to platform-hotfix 12.4.3-03453 or 12.5.0-02835 now; active exploitation is vendor-confirmed and both CVEs are KEV-listed; SMA100-series and firewall-hosted SSL-VPN are not affected, so scope the emergency change to SMA1000 only.
Treat any SonicWall SMA 1000 that was internet-exposed and unpatched before the hotfix as compromised, not merely vulnerable: re-image rather than patch in place, then reset all account passwords and TOTP seeds, UTA0533 established on-appliance persistence and captured cleartext LDAP credentials, so stolen secrets and implants survive the patch.
On every SMA 1000 you remediated for CVE-2026-15409/-15410, re-verify the installed firmware version now (Rapid7 observed the actor rolling an applied patch back to a vulnerable state) and widen the credential rotation beyond account passwords and TOTP seeds to directory-service bind credentials for LDAP/RADIUS/Active Directory and every certificate and API key configured on the appliance.
Upgrade every self-hosted JFrog Artifactory instance to a build that closes both CVEs: 7.133.11 or later for CVE-2026-42016, which JFrog names as its only fixed build, and the CVE-2026-42018 fix for the branch, where Wiz's corrected builds (7.133.29, 7.146.38, 7.161.20) sit above JFrog's table. Wiz's 7.111.21, 7.117.28 and 7.125.20 are below 7.133.11, so instances on those branches remain vulnerable to CVE-2026-42016 and must move to 7.133.11 or later.
On any Artifactory instance that was internet-reachable and unpatched since 15 August 2026, search access logs for an unauthenticated POST to /access/api/v1/aws/token/ (trailing slash) followed within minutes by a POST to /access/api/v1/tokens from the same client. That two-request sequence is the chain's signature. Where found, treat the instance as compromised: revoke all tokens, reset the Access token signing key and certificate, audit /api/security/users and /access/api/ui/users for administrator accounts you did not create, remove any Groovy plugin you did not deploy, and restart the JVM to clear an in-memory implant.
Upgrade every ConnectWise ScreenConnect on-premise client to 26.6.5 now; where an immediate upgrade is blocked by a change window, remove the TransferFiles role permission from every session group in the interim (Administration > Security > Roles); ScreenConnect servers themselves are not affected, only clients.
Treat any pre-26.6.5 ScreenConnect client that shows a second, unfamiliar RMM tool (UltraViewer, Quick Assist) or an unexplained ScreenConnect connection ID as compromised, not merely vulnerable: reimage rather than patch in place; the worm mechanism means a technician's own session can already have propagated the infection to every host that client actively connected to.
Upgrade every self-managed GitLab CE/EE instance to 19.3.2 / 19.2.6 / 19.1.8 now; GitLab.com is already patched and GitLab Dedicated needs no action. Assume any files a low-privilege or attacker-scripted request could reach (CI/CD credentials, SSH keys, database connection strings, application secrets) may have been read, and rotate them if the instance was internet-reachable and unpatched since 2026-09-10.
For any instance with a Duo Chat-enabled account, hunt for anomalous GraphQL subscription requests targeting Advanced Search configuration retrieval (CVE-2026-87719, which NCSC Switzerland now reports as exploited) and rotate any credentials the Advanced Search configuration stores if evidence of access is found.
2026-09-12T0409Z-intel· Sonnet 5 · window 26 h · 4 entries published
Verification & coverage notes
Coverage window: standard (gap_hours=23.98 since 2026-09-11T0410Z-intel, window_hours=26). No outage-backfill duty.
Mechanical KEV sweep (v4.8), all 4 in-window additions dispositioned.tools/kev_window_diff.py found four CISA KEV additions dated 2026-09-11 uncovered by the store: CVE-2026-42016 and CVE-2026-42018 (JFrog Artifactory), CVE-2026-84869 (ConnectWise ScreenConnect), CVE-2026-85706 (GitLab CE/EE). All four published as new entries this run. CVE-2026-42016/-42018 were confirmed via JFrog's own advisory to be distinct root causes, disclosure dates and affected-version ranges from the already-tracked CVE-2026-82329 (2026-09-01 entry) (not a same-flaw re-numbering) so they ship as a separate entry with references[] pointing at the existing one, per the single-report-covers-three-CVEs judgment call the researching sub-agent flagged; the two entries are not merged.
2026-09-12/cve-2026-85706-gitlab-unauth-path-traversal-file-read (vulnerability, high), patch-to-honeypot-probe in ~24h, KEV 2026-09-11.
2026-09-12/jfrog-artifactory-cve-2026-42016-42018-token-chain-takeover (vulnerability, critical, deep dive, category supply-chain, not used in the last 30 days), confirmed wide-scale admin-takeover chain against two previously-patched, low-attention CVEs, with backdoors already dropped and the majority of installs still vulnerable six weeks post-disclosure; raised from high to critical on iteration-2 verifier calibration flag, consistent with store precedent (the 2026-09-01 CVE-2026-82329 entry, same product, same admin-takeover outcome, critical). Single-source (Wiz Research is the sole assessor of the exploitation claim; JFrog's own advisories corroborate only the underlying flaws, not the exploitation).
2026-09-12/japan-digital-agency-gss-vpn-breach-maintenance-account (incident, notable), clears the PD-11 breach gate on limb (b): a materially transferable lesson (detection via anomalous maintenance-account file-access volume rather than the initial exploit; a shift from CVSS-severity-based to risk-based patch prioritization after losing the race to an exploit on a bug rated only "Medium") on a structurally close foreign analogue (a national government's own shared multi-agency IT-services platform).
Updated entries (2):
2026-08-29/eu-cra-reporting-obligation-ncsc-fi-checklist, update, floats updated_at. ENISA confirmed 2026-09-11 the CRA Single Reporting Platform has deployed initial operating capability, resolving the prior fire's open point; a same-day Bitkom survey (via heise) adds a preparedness data point.
2026-07-14/sonicwall-sma1000-ssrf-cve-2026-15409-actively-exploited, update, floats updated_at. Hunt.io (via Security Affairs; OffSeq's AI-generated Threat Radar reposts the same figures, not an independent source) names a first confirmed victim of a materially wider, distinct mass-exploitation wave against the same CVE (UK council; secretsdump run directly on the compromised appliance reaching DCSync in 5/250 environments), explicitly not attributed to UTA0533 or INC Ransom.
Borderline drop:Anthropic's "distillation attacks" report (hydra-cluster fraudulent-account networks used by DeepSeek/Moonshot/MiniMax to scrape Claude), substantive primary technical research (Anthropic's own telemetry) with a transferable fraudulent-account-network detection technique, but the underlying subject is an AI-industry IP/competitive dispute under an active US-China export-control policy backdrop, with no direct Swiss public-sector nexus beyond a generic account-fraud/API-abuse technique-class analogy. Relevance doubt resolved toward drop per PD-11/v4.2 calibration. Not registered to the entity registry.
Single-source / carve-out items:jfrog-artifactory-cve-2026-42016-42018-token-chain-takeover (single-source, reliability B / credibility 2; Wiz Research is the sole assessor of the active-exploitation chain; sourcing_note explains why BSI/ENISA's same-day postings are not counted as independent corroboration).
Coverage gaps: inside-it-ch (whole-host "Vercel Security Checkpoint" 429 on specific article bodies, the long-carried Insel Gruppe/ServiceNow backlog row plus two further articles this run, a 14th+ consecutive fire unable to read this class of article; RSS and general listing access stayed healthy throughout); cert-pl (/en/posts/ news listing 403'd this run; its vuln-advisory RSS feed, the source's primary recipe, was not re-tried as duplicative of S1's own essential-tier coverage of the same source, covered_anyway: true); cert-at (reachable, no in-window items, latest post dated 2026-08-26, outside the 26h window).
Coverage backlog: all 11 open rows in state/coverage_backlog.md re-checked this run (S1–S4); every one carries a 2026-09-12 dated note, no change on any, no row struck.
No contradictions found this run. No product/supplier watchlist configured (sweep is a no-op per the profile). No closed-source intake (no intel/ drops in-window).
Verification loop, 8 iterations, fail-open at the cap (never reached a confirmed CLEAN). The loop ran the full 8-iteration cap: iteration 1 NEEDS_FIXES (truth 3, editorial 6), 2 NEEDS_FIXES (3+2), 3 NEEDS_FIXES (4+1), 4 NEEDS_FIXES (2+0), 5 CLEAN, 6 (the confirmation pass) NEEDS_FIXES (3+1), restarting the chain per decision rule 2, 7 NEEDS_FIXES (1+3), 8 NEEDS_FIXES (0+1). Every iteration's findings were genuine and were remediated (see verification.iterations[] above and work/2026-09-12T0409Z-intel/verification.iter{1..8}.md); no finding was declined without a stated reason. Per the cap fail-open rule, this run publishes on iteration 8's NEEDS_FIXES verdict with verification_residual_count: 1 (one small, evidenced missing-citation finding, fixed) rather than a ninth iteration. This is an unusually long loop for what were, in aggregate, narrow and progressively smaller defects (import citation gaps, one inverted causal clause, one unsupported given name, a few CVSS/date sourcing gaps), every one caught by a genuinely independent cold read finding something the previous seven passes missed, which is the loop working as designed rather than a sign the content is unsound. The one substantive editorial judgment call (raising jfrog-artifactory-cve-2026-42016-42018-token-chain-takeover from priority: high to critical on iteration 2's flag) was independently sanity-checked by iteration 3 and not contested by any later iteration.