7 verified findings from 1 run · the settled record for this UTC day, in the classic brief order.
Criticality
Kind
Topic
Region
TL;DR · the day in one read
01A patched SMA 1000 is not evidence of eviction — Rapid7 observed the actor reverting the fix, and victims are now getting fake incident-response calls. Update to this pipeline's 2026-07-18 SonicWall SMA 1000 kill-chain entry. Rapid7's director of vulnerability intelligence told The Hacker News on 2026-08-03 that INC Ransom "has emerged as the dominant threat actor actively weaponizing this vulnerability chain" — a characterisation, not a new link, since Rapid7 first attributed the activity to INC on 2026-07-17. Two facts change defender behaviour. Rapid7 observed the actor rolling a newly applied patch back to a vulnerable state to keep access, so patch state has to be re-verified after remediation and an up-to-date version string is not evidence of eviction. And at the extortion stage victims are receiving unsolicited email and telephone contact from parties offering to help with their ransomware problem. Resecurity also widens the required credential-rotation scope well beyond passwords and MFA seeds. →
02The victim's statement lands, the widely quoted record figures are not victim counts, and the Dataverse path is a campaign-level hypothesis to sweep for. Update to the 2026-07-31 ExfilSquad entry. The Police National Legal Database, run by West Yorkshire Police, has now published its own statement: names, organisations and work email addresses of police officers, staff, criminal-justice professionals, government partners and customers were compromised and published on the dark web, with no evidence that passwords or credentials were taken. It adds a second affected service, Ask the Police, and gives no victim total — reporting notes the 108,429 figure in circulation is PNLD's registered user base, not a breach count. VenariX assesses the campaign-level access path as public Microsoft Power Pages portals granting the Anonymous Users role broad Dataverse table read permissions, reproduced live against one municipal portal, with no exploit and no malware — but no source has confirmed that path for PNLD specifically. →
03A targeted attack on Liechtenstein's beneficial-ownership register yielded a targeting dataset on the owners behind Swiss- and EU-administered structures. The Government of Liechtenstein disclosed on 2026-08-02 that an unknown actor gained unauthorised digital access to the Verzeichnis wirtschaftlich berechtigter Personen — the national beneficial-ownership register at the Amt für Justiz — overnight into 2026-07-30 and copied records for roughly 31,000 legal entities. Forensics released 2026-08-03 characterise it as a targeted attack on that register with no attacks found on other systems, but the government progressively took the eMWST VAT portal, the Lides reporting platform, the central account register and the Intax tax system offline as a precaution. No initial-access vector has been disclosed, no actor identified and no ransom demand reported; the breach is declared under GDPR Article 33. →
04Unit 42 shows three ways endpoint malware defeats Google synced passkeys without elevation, unlock or user interaction — and one of them cannot be revoked. Unit 42 published three attacks (2026-08-03) against Google Password Manager's cloud-synced passkeys in Chrome on Windows with a TPM, all requiring only unprivileged malware already on the endpoint. Pass-ta-key drives the TPM-wrapped device identity key through standard Windows CNG calls to sign a forged WebAuthn assertion with the User Verified flag unset, which succeeds against any relying party that does not validate that flag. Silver Pass-ta-key forces device re-enrolment and registers an attacker-generated user-verification key, because the cloud authenticator does not check attestation on new UV keys — producing reusable access that sets the flag. Golden Pass-ta-key dumps the 32-byte security domain secret from Chrome's memory during recovery and decrypts every synced passkey private key; Google has no way to rotate or revoke that secret. →
05Two national CERTs retract SQLite advisories because the CVEs describe bugs that do not exist, while the same records stay live downstream. On 2026-08-03 NCSC-NL revised advisory NCSC-2026-0268 to state that its SQLite CVE was hallucinated by an LLM, and BSI CERT-Bund retitled two SQLite advisories (WID-SEC-2026-2581, WID-SEC-2026-2604) to "MELDUNG ZURÜCKGEZOGEN". The originating research is JFrog's reproduction audit of a batch published through one new GitHub repository: 54 of 55 advisories were fabricated, and six SQLite entries (CVE-2026-51296, -51297, -51300, -51302, -51303, -51304) named functions absent from the claimed version, cited line numbers past end-of-file, and shipped proofs-of-concept that produce no crash. Retraction is propagating unevenly — GHSA still carried CVE-2026-51294 as an unreviewed record when this run checked on 2026-08-04, so scanner and SBOM pipelines are still being served records the CERTs have withdrawn. →
06Cisco's CVSS 10.0 Secure FMC authentication bypass finally has hot fixes — and a compromise check Cisco revised three times in four days. CVE-2026-20079 is a CVSS 10.0 authentication bypass in the web interface of Cisco Secure Firewall Management Center that lets an unauthenticated remote attacker execute script files and obtain root on the firewall management plane. Cisco disclosed it on 2026-03-04 with no patch and no workaround, added per-train hot fixes and a compromise check on 2026-07-31, and has revised that check three times since, most recently on 2026-08-03. Cisco reports no malicious use of this CVE, but VulnCheck built a working exploit and published the chain in March, and the same management interface carries the separate, KEV-listed and actively exploited static-credential flaw CVE-2026-20316 that Cisco says can be combined with other Secure FMC flaws to elevate privileges. →
The Verzeichnis wirtschaftlich berechtigter Personen (VwbP, "register of beneficial owners") exists because Liechtenstein implemented the EU's 5th Anti-Money-Laundering Directive: the VwbPG has been in force since 2021, and the register records the natural persons behind Rechtsträger — companies, foundations and trust arrangements. On 2026-08-02 the government disclosed that the register had been attacked and that "Datenkopien von rund 31'000 Rechtsträgern" ("copies of data on around 31,000 legal entities") were unlawfully taken (Regierung des Fürstentums Liechtenstein, 2026-08-02). The Record and SRF both carry the same figure (The Record, 2026-08-03; SRF, 2026-08-03).
The government's own timeline is worth reading as a benchmark, because detection was human and internal rather than telemetry-driven. Unauthorised digital access occurred overnight into 2026-07-30; irregularities were noticed at the Amt für Justiz during that day; the Amt für Informatik was brought in, secured the data and took the affected system off the network the same day; the government was informed on 31 July that the attack had potentially succeeded, and the first confirmed preliminary findings arrived on the afternoon of 1 August. A crisis unit convened that evening under Head of Government Brigitte Haas and Justice Minister Emanuel Schädler, was formally confirmed on 2 August, and a media conference was announced for 2026-08-04. The government states there is no indication that data in the system was altered or deleted, and the register is unavailable to external users through the LLV.li portal.
The forensic update on 2026-08-03 is where the operationally interesting tension sits. First findings characterise the event as a targeted attack on the VwbP at the Amt für Justiz, and "Weitere Angriffe auf andere Systeme konnten nicht festgestellt werden" ("no further attacks on other systems could be established") — yet the government kept widening the shutdown: the eMWST VAT portal and the Lides electronic reporting and data-exchange platform came off the network on 31 July, and on 3 August the central account register and the central tax system Intax followed, explicitly as precautionary measures with no indication of unlawful access (Regierung des Fürstentums Liechtenstein, 2026-08-03). Law-enforcement authorities are now engaged alongside the Amt für Informatik and external partners. No initial-access vector has been published, no actor named, and no ransom demand or criminal-market offering reported.
Triage: bulk read-out of a register by an external identity is a volumetric anomaly against a stable baseline, not an indicator match — a single external session enumerating tens of thousands of entities looks nothing like the handful of lookups a legitimate professional user performs, and it is detectable with no knowledge of the attacker's tooling. The benign lookalike is a sanctioned bulk export or an integrated partner system doing a scheduled sync; those are attributable to a known principal, run on a known schedule, and appear in change records, whereas this pattern is a single principal exceeding its own historical retrieval volume by orders of magnitude within one session.
Dabei wurden Datenkopien von rund 31'000 Rechtsträgern widerrechtlich abgegriffen.
Beim Angriff auf das VwbP handelt es sich um eine Verletzung des Schutzes personenbezogener Daten gemäss Art. 33 Datenschutz-Grundverordnung (DSGVO).
Weitere Angriffe auf andere Systeme konnten nicht festgestellt werden.
Am Montag, 3. August 2026, folgten zusätzlich das Zentrale Kontenregister sowie das zentrale Steuerfachsystem Intax. Es handelt sich um reine Vorsichtsmassnahmen.
Cisco Secure Firewall Management Center is the box that holds the policy, the rules and the credentials for a firewall fleet, and CVE-2026-20079 gives an unauthenticated caller root on it. Cisco describes the flaw as "due to an improper system process that is created at boot time", reachable by sending crafted HTTP requests, and scores it CVSS 3.1 10.0 (CWE-288) against Secure FMC Software and Cisco Security Cloud Control Firewall Management "regardless of device configuration" (Cisco PSIRT, 2026-08-03). What makes this worth acting on now rather than in March is the timeline: the advisory went out on 2026-03-04 with no fix and no workaround, and the per-train hot fixes plus the first compromise-check guidance only arrived with advisory version 2.0 on 2026-07-31, and Cisco has revised that check three times since — v2.1 and v2.2 the same day, v2.3 on 2026-08-03. For roughly five months the only available response was exposure reduction.
The mechanics explain why exposure is narrower than a CVSS 10.0 suggests, and why the detection guidance matters more than usual. VulnCheck built a working exploit and published the chain on 2026-03-26: a startup process leaves a partial csm_processes session in the sfsnort.sessions database, and if nobody authenticates after boot that session persists and can be upgraded using the hardcoded machine-user credential report:snortrules, yielding the sf_action_id request token; an arbitrary file write through the validateLicense bulk AJAX endpoint on sajaxintf.cgi drops a Cisco-format Makeself script to /var/tmp/license.tmp, and calling pjb.cgi with SF::UI::DataObjectLibrary::upgradeReadinessCall makes the appliance process that file as an upgrade package, executing it as root (VulnCheck, 2026-03-26). VulnCheck also found the precondition is fragile — dashboard interaction by a real administrator, cloud-managed session activity, or a periodic cleanup all clear the injected session — so in its assessment the realistic exploitation window is shortly after a reboot, or on appliances nobody logs into. That same source counts roughly 300 internet-facing FMC instances on Censys and between 600 and 700 on FOFA.
Cisco states it is "not aware of any public announcements or malicious use" of this CVE. The reason to treat it as out-of-band anyway sits on the same web interface: the separate static low-privilege credential flaw CVE-2026-20316 is CISA KEV-listed with exploitation Cisco says has been ongoing since July 2026 (covered here on 2026-07-30), and in that advisory Cisco raises the Security Impact Rating to High specifically because "this vulnerability can be used with other Cisco Secure FMC Software vulnerabilities to elevate privileges" (Cisco PSIRT, 2026-08-03). An attacker already using the exploited flaw for low-privilege read access is one documented step from the root path this CVE opens.
Detection, and the discriminator: both advisories key compromise assessment on the same artifact — a package_info.pl invocation against /var/tmp/license.tmp in /var/log/messages*, run as root via sudo from the www account. Legitimate FMC upgrades and licensing operations do run package_info.pl, so the file path is the signal rather than the command: a genuine upgrade references a package under Cisco's own upgrade directories, not a temporary file in /var/tmp. Because the injected session only survives while no administrator has authenticated, correlate any unauthenticated web-UI activity against appliance boot and uptime records — a request sequence reaching CGI endpoints with no preceding interactive login, minutes after a reboot, is the shape here. Hardening beyond the hot fix is exposure reduction; Cisco notes that "If the FMC management interface does not have public internet access, the attack surface that is associated with this vulnerability is reduced", and low-touch appliances that nobody logs into are precisely the ones that stay exploitable longest.
A vulnerability in the web interface of Cisco Secure Firewall Management Center (FMC) Software could allow an unauthenticated, remote attacker to bypass authentication and execute script files on an affected device to obtain root access to the underlying operating system.
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory.
Cisco has assigned this security advisory a Security Impact Rating (SIR) of High rather than Medium as the score indicates. The reason is that this vulnerability can be used with other Cisco Secure FMC Software vulnerabilities to elevate privileges.
Two European national CERTs pulled published SQLite advisories on 2026-08-03 for the same reason: the vulnerabilities are not real. NCSC-NL revised NCSC-2026-0268 to version 1.01, struck through its own description, and gave the reason in one line — "CVE is door een LLM gehallucineerd" ("the CVE was hallucinated by an LLM") — noting the retracted advisory had covered CVE-2026-51302 as affecting Red Hat's SQLite (NCSC-NL, 2026-08-03). BSI CERT-Bund retitled WID-SEC-2026-2604 and WID-SEC-2026-2581 to "MELDUNG ZURÜCKGEZOGEN" ("advisory withdrawn") and removed their CVE references (BSI CERT-Bund, 2026-08-03; BSI CERT-Bund, 2026-08-03).
The underlying work is a reproduction audit rather than an opinion. JFrog cloned sqlite/sqlite at the claimed tags, compiled the official releases in isolated containers, and fed each advisory's proof-of-concept SQL verbatim into the binaries under AddressSanitizer. Nothing reproduced, and the code references dissolve on inspection: CVE-2026-51302's claimed use-after-free runs through exprComputeOperands(), a function that did not exist in SQLite 3.41 and was added mid-2025, while the function it says does the freeing, sqlite3ReleaseTempReg(), only recycles register indices into an array and performs no heap deallocation at all. CVE-2026-51303 claims a fix in 3.51.3, but "a diff between 3.51.2 and 3.51.3 shows absolutely no changes to src/expr.c". CVE-2026-51296 cites lines 3555 and 3575 of src/json.c when, JFrog notes, "In version 3.41.0, src/json.c is only 2706 lines long". CVE-2026-51297 references jsonBlobEdit(), absent from the claimed release; CVE-2026-51304 gives a single-argument signature for a function that requires a database handle; CVE-2026-51300 cites a comment and a memory allocation as the vulnerable lines (JFrog Security Research, 2026-07-30). SQLite's maintainer reported the same wave independently on 2026-07-29 (SQLite User Forum, 2026-07-29).
The propagation path is the part that matters operationally, because every hop in it is one a defender's own tooling trusts. A newly created GitHub repository published the advisories; MITRE's public submission form performs no identity verification; NVD flagged them critical and CISA's Authorized Data Publisher enrichment agreed; Red Hat initially scored CVE-2026-51302 at 10.0 before downgrading it to 7.6; from there the records reached GHSA and the two national-CERT advisory streams that European public-sector vulnerability management actually reads. JFrog's diagnosis is structural: "Because no step in today's system actually requires a proof-of-concept or bug reproduction, a plausible-sounding fake advisory can slide right through the pipeline and end up in GHSA, downstream databases, and enterprise scanners." Retraction does not travel the same path in reverse — this run fetched GHSA-4r76-5xh9-qj36 — a use-after-free claim against SQLite 3.41 carrying CVE-2026-51294, from the same batch but not among the six JFrog reproduction-tested — and found it still live and marked "Unreviewed" on 2026-08-04, after both CERTs had withdrawn (GitHub Advisory Database, 2026-07-30).
A broader audit of 55 advisories published by the same GitHub account revealed that 54 were completely fabricated, while one contained a real bug wrapped in unverified CVE metadata.
Because no step in today's system actually requires a proof-of-concept or bug reproduction, a plausible-sounding fake advisory can slide right through the pipeline and end up in GHSA, downstream databases, and enterprise scanners.
CrowdStrike's Counter Adversary Operations team published its annual Threat Hunting Report on 2026-08-03, drawing on OverWatch managed-hunting and CrowdStrike Intelligence telemetry from what it describes only as "the past year" (CrowdStrike, 2026-08-03); reporting on the release puts that window at the 12 months to 30 June 2026 (SiliconANGLE, 2026-08-03). Only a few of its findings change a defender's decisions; those are the ones worth carrying.
The one that does most work is the exploitation-velocity measurement: "From January through June 2026, 88% of CrowdStrike-observed exploitation of vulnerabilities with a public PoC was conducted within 48 hours of the PoC's release." The named cases go faster still. China-nexus VAULT PANDA and GENESIS PANDA launched deliberate attacks within 24 hours of the public disclosure of a critical web-application flaw, and after the React2Shell disclosure OverWatch worked 800+ hunting leads across more than 80 victims in four days. For a Linux local privilege-escalation flaw disclosed on 29 April with a researcher PoC released the same day, OverWatch saw widespread exploit deployment the following day — roughly 94% of first-day events matching public PoC testing behaviour — and for the Belarus-nexus actor UMBRAL BISON, "They uncovered Belarus-nexus activity in just over 20 hours after public disclosure." CrowdStrike's own read is that this pattern predates frontier AI models but that those models are likely to compress the timeline further by accelerating vulnerability discovery and exploit development.
The practical consequence is a prioritisation input rather than a task: for an internet-reachable component, the arrival of a public proof-of-concept is the trigger, and waiting for a KEV listing or the next scheduled maintenance window puts the decision after the exploitation rather than before it. That reframing bites hardest on the exposure classes this constituency runs at the perimeter — the edge appliances, management planes and web applications that need no user interaction to reach.
On the software supply chain, the concentration figure is the useful one: "87% of identified software registry threats in the first half of 2026 involved npm packages", which CrowdStrike attributes to JavaScript's dependency-chain scale and automatic install scripts. The named activity adds tradecraft detail on a cluster this store already tracks under the name Sapphire Sleet, one of whose recorded aliases is CrowdStrike's STARDUST CHOLLIMA: the DPRK-nexus actor used stolen maintainer credentials in March 2026 to compromise the axios npm package and deliver platform-specific variants of its ZshBucket malware, and in June 2026 injected a malicious npm package as a dependency into at least 131 Mastra AI framework packages — which CrowdStrike reads as trusted AI building blocks becoming supply-chain targets. A separate financially motivated actor, ALTERED SPIDER, compromised more than 300 software dependencies in one day, harvested credentials and pivoted into cloud environments.
Three identity and AI observations complete the picture without carrying separate action, because the underlying tradecraft is already covered in this store's operational entries. Vishing intrusions in H1 2026 doubled against H2 2025, with CrowdStrike recording one case in which an eCrime operator moved from account takeover to SaaS data theft in under five minutes. Monthly device-code phishing attempts rose 15x over six months. And on the defender's side of the ledger, "AI agent-triggered detection leads now surface 2.5x more threat leads than manually driven activity", which CrowdStrike frames as making it harder to separate malicious activity from expected AI-driven behaviour — a triage-volume problem rather than an attacker capability gain. One LLMjacking campaign generated nearly 200,000 API requests in two minutes against a hijacked service.
From January through June 2026, 88% of CrowdStrike-observed exploitation of vulnerabilities with a public PoC was conducted within 48 hours of the PoC’s release.
They uncovered Belarus-nexus activity in just over 20 hours after public disclosure.
87% of identified software registry threats in the first half of 2026 involved npm packages.
the earlier entry recorded the Police National Legal Database as "affected" with a 135,000-record figure taken from third-party reporting while the Home Office declined to comment. Three things have changed, and one of them is a correction to the numbers.
The victim has now published its own statement. PNLD, operated by West Yorkshire Police, confirms that "Information including the names, organisations and work email addresses of police officers, staff and other criminal justice professionals, government partners and customers has been compromised and published on the dark web", that "There is no evidence to suggest that passwords or other security credentials have been compromised", that the incident was identified on Sunday 2026-07-26, that all affected organisations were contacted, and that it is working with the National Crime Agency and specialist cyber-security firms with the Information Commissioner's Office notified (PNLD, 2026-08-03). The statement adds a second affected service the earlier entry did not carry: Ask the Police, the public enquiry site PNLD hosts, from which names and email addresses of citizens who had previously submitted questions were also published. PNLD stresses what it is not — not the Police National Computer, not the Police National Database, not a crime-recording system, and holding no confidential material on victims, witnesses or offenders (The Hacker News, 2026-08-03).
On scope, the correction runs the other way from the usual pattern. PNLD's notice describes the exposed fields and gives no victim total at all, and as of 2026-08-03 it had not disclosed how many people were affected, when the intrusion began, how long access lasted or how much data was taken. The 108,429 figure circulating alongside this incident comes from PNLD's own 2025-26 annual summary of police registrations across all 43 Home Office forces — and the reporting is explicit that "That is a user-base figure, not a breach-victim count." Treat both that number and the earlier 135,000 as unconfirmed for scope purposes.
The access path is the transferable part, and it is a campaign-level finding rather than a PNLD root cause. VenariX reviewed data samples associated with 11 of the 15 organisations ExfilSquad listed and found the structure and field formatting consistent with Microsoft Dataverse exports across all 11 — @odata.etag, @OData.Community.Display.V1.FormattedValue and @Microsoft.Dynamics.CRM.lookuplogicalname artefacts across contacts, accounts, incidents, emails, annotations, leads, system users and business units. Its assessment is that the data came out of public Microsoft Power Pages portals configured to let anonymous visitors read Dataverse records, through the portal Web API /_api/<EntitySetName> route or a legacy /_odata feed. Crucially there is no exploit in the chain: "VenariX has not identified evidence of ransomware deployment, malware use, lateral movement, or exploitation of a software vulnerability." VenariX reproduced the condition once, against the City of Houston's public Power Apps portal serving Houston 311, which returned incident records without authentication in a form consistent with what ExfilSquad published (VenariX, 2026-07-29). VenariX is equally explicit about its own limit: the evidence does not confirm that every listed organisation was reached the same way, or through the same configuration issue. PNLD is not mentioned anywhere in that research at all, and the reporting that connects the two is explicit about the gap — as of 2026-08-03 neither PNLD's notice nor VenariX's report identified a PNLD-specific endpoint, permission setting, API route or supporting log, so "At this stage, the Power Pages link remains a hypothesis to test rather than an explanation of the PNLD breach" (The Hacker News, 2026-08-03). What is corroborated is only the platform: PNLD's 2023-24 annual summary states the database uses Microsoft Power Platform, and the breach-notice page references assets on Microsoft's content.powerapps.com domain.
This also revises the earlier entry's editorial line. That entry carried an assessment that ExfilSquad's 15-victim list was more likely fabricated than genuine. The correct current read is narrower and more useful: the individual claim still deserves base-rate scepticism, but the method is now evidenced — 11 structurally consistent Dataverse sample sets, one reproduced live, one listed company (Frontier Airlines) having already confirmed unauthorised access to a data storage account on 2026-07-09 without attributing it — so the method should be swept for locally regardless of whether any given listing is real.
Information including the names, organisations and work email addresses of police officers, staff and other criminal justice professionals, government partners and customers has been compromised and published on the dark web.
There is no evidence to suggest that passwords or other security credentials have been compromised.
Police National Legal Database
VenariX has not identified evidence of ransomware deployment, malware use, lateral movement, or exploitation of a software vulnerability.
the earlier entry reconstructed UTA0533's appliance-to-network kill chain against SonicWall SMA 1000 and told readers to treat an exposed, unpatched appliance as compromised rather than merely vulnerable. That direction stands. Four things have moved since, and two of them change what "remediated" means.
Who is on the chain. Rapid7's director of vulnerability intelligence, Douglas McKee, told The Hacker News that "More recently, INC Ransomware has emerged as the dominant threat actor actively weaponizing this vulnerability chain", and that the technical correlation with the pre-disclosure cluster "indicates that a single threat actor or coordinated group is responsible for discovering and exploiting this zero-day vulnerability" (The Hacker News, 2026-08-03). Two limits belong with that quote. Rapid7 attributed this activity to INC Ransom on 2026-07-17, hours before this pipeline's 2026-07-18 entry, which did not carry it (Dark Reading, 2026-07-17) — so the actor link is seventeen days old and the new element is only the dominance characterisation. And the overlap claim is Rapid7's alone: Volexity, which named the UTA0533 cluster, has published no INC link, so the wider framing that both firms made that connection is not supported.
A patch you applied is not necessarily a patch that is running. This is the finding with the most operational consequence, and no prior entry here has carried it. Rapid7's director of incident response, Brett Deroche, describes containment succeeding in most engagements but not all: "We observed the threat actor maintaining persistence and rolling the newly applied patch back to a vulnerable state to maintain access. A comprehensive forensic review of the firewall is required to ensure complete eviction." A root-level attacker resident on the appliance can undo remediation, which means the standard verification — check the version, close the ticket — reports success on a box that is still owned. Resecurity's DFIR work reaches the same conclusion from the artifact side: "Setuid binaries, Python injectors, modified init scripts, and NGINX Unit configuration changes can survive reboots and may persist after a superficial firmware upgrade if not remediated. A patched appliance that still contains ROOTRUN or KNUCKLEBALL remains compromised" (Resecurity, 2026-08-01).
The rotation scope is wider than passwords and MFA seeds. Rapid7 reports that the attacks used the appliance foothold to extract high-value credentials, active session databases and TOTP multi-factor-authentication seed configurations (The Hacker News, 2026-08-03) — stolen session state and MFA seeds keep working after a password reset, which is why the rotation list matters more than it looks. The earlier entry told readers to reset account passwords and TOTP seeds. Resecurity's list of what the appliance processed or stored, and therefore what has to be replaced, extends to SMA administrator passwords, directory-service bind credentials for LDAP, RADIUS and Active Directory, user passwords for every account that authenticated during the exposure window, certificates and API keys configured on the appliance, and TOTP tokens and seeds. Bind credentials are the item most often missed, and they are the ones that grant standing directory access independent of the appliance. Where compromise is confirmed, Resecurity's guidance is to factory-reset, reimage on patched firmware and restore configuration from a backup pre-dating the vulnerable branches — a constraint SonicWall states independently in its own product notice, which limits usable backups to those predating 12.4.3-03245 and 12.5.0-02283 (SonicWall, 2026-07-14).
A new pressure layer at the extortion stage. Resecurity, which has run incident response for several victims, reports that "many of the new victims received emails, as well as phone calls from unknown organizations claiming to assist with ransomware issues", using infrastructure registered shortly after the intrusion. Whether this is the same operation or opportunists reading the leak site, the effect is the same: inbound offers of help with a ransomware problem the organisation has not made public are adversary contact, and the people receiving them are often outside the security team.
On victim geography, hold the claim loosely. Resecurity reports that INC's leak-site listings between 2026-07-17 and 2026-08-01 "include private sector and government organizations from Australia, the US, UAE, Colombia, Switzerland, and other countries", and SecurityWeek relays that INC "has emerged as the most active one" among actors chaining the two CVEs (SecurityWeek, 2026-08-03). No organisation is named, no victim or authority has confirmed any listing, and Resecurity does not state that any individual listing was reached through this exploit chain — the country list and the chain are separate claims in the same report. Treat it as an unverified criminal claim rather than evidence of a Swiss compromise.
More recently, INC Ransomware has emerged as the dominant threat actor actively weaponizing this vulnerability chain.
We observed the threat actor maintaining persistence and rolling the newly applied patch back to a vulnerable state to maintain access. A comprehensive forensic review of the firewall is required to ensure complete eviction.
Setuid binaries, Python injectors, modified init scripts, and NGINX Unit configuration changes can survive reboots and may persist after a superficial firmware upgrade if not remediated. A patched appliance that still contains ROOTRUN or KNUCKLEBALL remains compromised.
many of the new victims received emails, as well as phone calls from unknown organizations claiming to assist with ransomware issues
The new victims listed on INC Ransomware's DLS between July 17, 2026 and August 1, 2026 include private sector and government organizations from Australia, the US, UAE, Colombia, Switzerland, and other countries.
Passkeys remove the shared secret, which removes phishing, replay and credential stuffing from the attacker's toolkit. Unit 42's research, published 2026-08-03, is about what replaces them: three attacks that leave the cryptography intact and instead abuse the trust a cloud-synced passkey system places in the client device, its onboarding flow and its recovery flow. The scope is specific — Google Password Manager in Chrome on Windows on machines with a TPM — and the precondition is unremarkable: malware already running as the logged-in user, with no elevation (Unit 42, 2026-08-03).
Reconnaissance. Chrome stores synced passkeys as proto-encoded WebauthnCredentialSpecifics records in its sync database under %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, and Unit 42 states plainly that "Accessing these records does not require elevated privileges." Reading them tells an attacker which services the victim protects with passkeys, the associated usernames and credential identifiers, and the encrypted private key — a target list before any authentication is attempted.
Pass-ta-key — forging the assertion. Chrome proves device possession to Google's cloud authenticator with a hardware-backed identity key, and the way Chrome handles that key is what the attack turns on. Chrome creates the TPM key without a name so it is never persisted inside the TPM, then exports it as an NCRYPT_OPAQUE_KEY_BLOB — encrypted by a TPM-resident key — and stores the result as wrapped_identity_private_key in the passkey_enclave_state file. Malware reads that blob from disk or Chrome's memory and re-imports it through the ordinary Windows CNG interfaces (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign whatever it likes on the same physical TPM. Unit 42's own framing of the consequence: "Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges." The attacker opens a WebSocket handshake with the cloud authenticator, signs the handshake hash together with the assertion request using the stolen identity key, receives a valid assertion, and replays it to the relying party.
The single bit that decides whether that works. The cloud authenticator issues a valid assertion whether the request was signed with the identity key or with the user-verification key; the only difference is the User Verified flag in the authenticator data, which is 0 for the identity key. A relying party that requires user verification and checks the flag rejects the forged assertion — a passkey-protected GitHub login did. A relying party that sets userVerification to required but never inspects the returned flag accepts it, and multi-factor authentication collapses to possession of one device key: "In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag." Unit 42 demonstrated this against eBay, which has since fixed its validation. Because many relying parties set the parameter to preferred rather than required for device-compatibility reasons, the population this variant works against is not small.
Silver Pass-ta-key — becoming the verification key. Rather than trying to reach the UV key, the attacker deletes it. Nothing protects the passkey_enclave_state file from removal (or the attacker issues a device/forget command with the identity key it already controls), which forces Chrome to re-onboard the device on next passkey use. Windows onboarding completes only on the second passkey use, so the device sits in a uv_key_pending state in between — Chrome defers creating the UV key to avoid stacking a Windows Hello prompt on top of the Google Password Manager recovery-PIN prompt. In that window the attacker generates its own key pair and sends device/add_uv_key with its public key, and it is accepted: "The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware." From then on the attacker mints assertions with the UV bit set, from its own infrastructure, without the victim's device being online — reusable access that satisfies even correctly implemented relying parties.
Golden Pass-ta-key — taking the master key. Synced passkey private keys are encrypted under a 32-byte security domain secret (SDS) that is supposed to stay inside the cloud authenticator, with only a wrapped copy on the client. Unit 42 found it in plaintext in Chrome's own FIDO device log, and while Google removed it from logging after the report, the underlying flow is unchanged: "Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory." So the attacker forces a fresh onboarding using the Silver technique, watches for passkey_enclave_state to be recreated, dumps Chrome's process memory at that moment, extracts the SDS, and decrypts every record in the sync database. The result is exportable passkey private keys, usable from anywhere, for every current and future passkey on the account — and there is no remediation: "In Google's current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key." Re-enrolling the device evicts the Silver variant; nothing evicts this one.
Triage: the telemetry classes are process and file access, not network. In process and module telemetry, the discriminator for the assertion-forging step is process identity — Chrome itself calling CNG to sign with the device identity key is the legitimate flow that happens on every real passkey login, whereas a non-browser process importing an NCRYPT_OPAQUE_KEY_BLOB and calling NCryptSignHash after reading passkey_enclave_state or the sync LevelDB is not a flow the product produces. For the Silver and Golden variants the sequence is the signal rather than any single event: deletion or modification of passkey_enclave_state, followed by a device re-onboarding the user did not initiate, followed by cross-process memory reads of chrome.exe. Legitimate re-enrolment happens, but it is user-initiated and rare, and it is not preceded by something removing the local state file. Hardening beyond the relying-party check follows Unit 42's own list: restrict access to Chrome's sync database and local passkey state files to the browser process through platform access controls, and monitor for repeated or unexplained re-triggering of onboarding and recovery flows.
Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges.
The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware.
In Google’s current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key.
In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag.
From an unauthenticated browser session, request /_api/contacts, /_api/accounts, /_api/incidents, /_api/emails, /_api/annotations and /_odata against every externally-reachable Power Pages or Power Apps portal your organisation operates, and treat any 200 response returning record bodies as a live data exposure to close today by removing table permissions from the Anonymous Users web role.
Search your vulnerability-management, ticketing and dependency-scanning systems for CVE-2026-51294, CVE-2026-51296, CVE-2026-51297, CVE-2026-51300, CVE-2026-51302, CVE-2026-51303 and CVE-2026-51304 and close any SQLite finding raised from them — the advisories behind them have been withdrawn, but at least one was still live in GHSA on 2026-08-04, so an unattended pipeline may re-raise it.
On every SMA 1000 you remediated for CVE-2026-15409/-15410, re-verify the installed firmware version now and alert on any later regression — Rapid7 observed the actor rolling an applied patch back to a vulnerable state, so the version you installed is not necessarily the version running.
Widen the rotation already performed on any exposed SMA 1000 beyond account passwords and TOTP seeds to the full set the appliance handled: SMA administrator passwords, directory-service bind credentials for LDAP, RADIUS and Active Directory, every user account that authenticated during the exposure window, and all certificates and API keys configured on the appliance.
On every relying party your organisation operates that accepts passkeys, set userVerification to required AND verify the User Verified bit in the returned authenticator data before accepting the assertion — this is the one control the relying party owns, and it closes the base Pass-ta-key variant outright.
Install the Cisco Secure FMC hot fix matching your release train (7.0 → GB-7.0.9.1-3, 7.2 → HL-7.2.11.1-4, 7.4 → HG-7.4.7.1-3, 7.6 → CY-7.6.5.1-2, 7.7 → AM-7.7.12.1-2, 10.0 → P-10.0.1.1-2). There is no workaround, and no configuration makes an FMC non-vulnerable.
Run Cisco's revised compromise check on every FMC that has been network-reachable since 2026-03-04: in expert mode, zgrep "package_info.*license" /var/log/messages* — a hit naming /var/tmp/license.tmp means the chain reached the package-install step, and Cisco directs those cases to TAC rather than to self-remediation.
2026-08-04T0411Z-intel· Claude Opus 5 · window 26 h · 7 entries published
Verification & coverage notes
Window: 26 h derived from a 24 h gap to the previous fire (2026-08-03T0409Z-intel), standard window class. That run's publish_status was ok, so no carried-over publishing failure. No intel/ drop directories in window, so no closed-source intake agent was spawned.
Two research agents were terminated mid-run by a model-specific content classifier, and both were recovered. The S2 (home region) and S4 (incidents) agents each died twice on Sonnet with an API safeguards error, in both cases early in the run shortly after loading the dedup context. Re-spawning them on a different model with the lean keys-only dedup index instead of the full-summary index worked first time, and both returned complete: S2 ran 19 minutes and returned four items, S4 ran 10 minutes and returned four. No coverage was lost — every source in both slices was attempted — but the run's own telemetry records the two agents as Opus rather than the definition's Sonnet pin, which is why their model lines differ from S1 and S3. Worth an operator note because the trigger looks like accumulated breach and exploitation content in the agent's context rather than anything in the spawn message, and the lean-index mitigation is cheap enough to consider as the default for these two domains.
A finding was corrected against its own primary source during the pre-publication deep read. S1 reported that Cisco shipped the first permanent hot fixes for CVE-2026-20079 on 2026-08-03 and that the same-day sibling advisory newly documented the chaining relationship. Re-reading both advisories in full shows neither claim holds: the hot fixes and the compromise-check guidance were added in advisory version 2.0 on 2026-07-31, the 2026-08-03 revision (v2.3) only updated the indicator-of-compromise CLI command, and the Security Impact Rating note about chaining was present in the sibling advisory from its initial release on 2026-07-29. The published entry states the correct dates and does not claim the fix or the chaining note as in-window news; the in-window development it rests on is the revised compromise check, and the reason the item is published at all is that a CVSS 10.0 authentication bypass on this product had never been covered here while its 5.3 sibling was.
Two further claims were corrected in the PNLD update. The researching agent's summary presented per-department figures (108,429 police registrations plus CPS, Home Office, NCA and MoD counts) as quantified breach scope; the cited reporting states explicitly that the 108,429 figure is PNLD's registered user base, not a victim count, and that PNLD has published no victim total at all. The same agent's framing had the Power Pages / Dataverse path as the PNLD access route; the reporting is explicit that it remains a campaign-level hypothesis with no PNLD-specific endpoint, permission setting, API route or log identified. The entry carries both corrections, and also revises the earlier entry's "probably fabricated" read on the ExfilSquad victim list to the narrower position the new evidence supports.
Every evidence[] quote was literal-substring-checked against the re-fetched page before the entry was written, with tag stripping replacing tags with the empty string rather than a space so the check ran against an uncorrupted copy. The fetched bodies were working scratch and are deliberately not committed — around 3 MB of raw advisory and article HTML has no forensic value once the quotes are verified, and the standing rule is to drop raw page text after extraction. That check was not as complete as first recorded here, and the verifier caught the gap: it covered the frontmatter quotes and a selected set of body quotations, not every quoted fragment in every body. Two body quotes drifted and were fixed in remediation — a Cisco sentence that pulled the word "because" inside the quotation marks, and the BSI advisory title transliterated as "MELDUNG ZURUECKGEZOGEN" where both cited pages render "MELDUNG ZURÜCKGEZOGEN". The lesson for the next fire is to run the literal check over every quoted span in the body, not only over evidence[].
borderline-drop: PaperCut NG/MF CVE-2026-8793 / CVE-2026-8794 (CERT-FR AVI-0959, 2026-08-03) — a missing brute-force limit and a login timing oracle, both CVSS 4.0 6.9, no code execution, no reported exploitation, fixed by upgrading to 26.0.3. Heavy public-administration, education and healthcare deployment argued for it, but a normal patch cycle handles it and the inclusion bar for a vulnerability is action beyond that cycle.
borderline-drop: ShinyHunters leak-site listings naming Alcon (Swiss-domiciled) and Questel (France), with a stated leak deadline of 2026-08-04 — a criminal claim and nothing more. No statement from either organisation and no high-reliability journalism on either listing could be found, so it cannot be reported as fact however well the claim shape matches this actor's confirmed activity. Worth a re-check next fire now the stated deadline has passed.
borderline-drop: Garante per la protezione dei dati personali fines TIM EUR 9,516,000 over unlawfully acquired telemarketing consents (2026-08-03) — a real enforcement action in a profiled sector, but a consent decision with no intrusion, no telemetry and nothing a Tier 2/3 responder would do differently this week.
borderline-drop: leak-site listings of CEN and CENELEC (coinbasecartel, 2026-08-01) and of the Mairie de Rinxent (krybit, 2026-08-02) — unconfirmed claims with no victim statement and no high-reliability reporting. The European standards bodies would be materially notable if confirmed; carried forward for a re-check.
out-of-window: unmaintained cJSON — CERT Polska's unpatched integer-overflow-to-heap-overflow advisory for CVE-2026-16554 (2026-07-27) plus a researcher's 33-issue disclosure relayed to OSS-Security (2026-07-30), primary sources outside window_hours=26. This one deserves the operator's attention rather than a quiet drop: cJSON is vendored into ESP-IDF and a great deal of embedded firmware, there is no maintainer and no patched version to point at, and the exposure lands in the device layer of energy, water, transport and building-automation estates. It is absent from all 129 entries in the 14-day index and fell into the gap between successive 24 h windows rather than being assessed and rejected. Handed to the next weekly for its periodic sweep.
out-of-window: ACN / CSIRT Italia operational summary for H1 2026 (2026-07-24) — an unprocessed periodic national-authority report squarely in region and sector, eleven days outside the window. Also handed to the weekly. Its most transferable findings are that NIS2 notifications inflate reported event counts without inflating threat, and that new CVE volume rose 54% year on year.
out-of-window: Atlassian Jira CVE-2022-37601 and CVE-2026-42581, both rated 9.8 by CERT-FR (CERTFR-2026-AVI-0934, 2026-07-27); Ransom-ISAC's "Weaponizing Exposed Data" analysis of extortion groups indexing and pricing stolen data before publication (2026-07-31); CISA BOD 26-04 on risk-based update prioritisation (2026-06-10, and a US federal mandate rather than a Swiss or EU obligation). All absent from prior coverage; recorded so they are recoverable.
Completeness sweep ran over all four findings files including every item the agents marked borderline, plus their own post-review drop lists. Nothing genuinely relevant fell out for any reason other than failing the gate or the recency rule; the two out-of-window items with real merit are named above with an explicit hand-off rather than dropped silently.
The seven fabricated SQLite identifiers are deliberately absent from the frontmatter cves[] of the entry that reports them: no cve_status value describes a withdrawn record, and populating a record's type, vector and auth fields would assert a flaw class that does not exist. They are instead recorded in state/cves_seen.json, which carries only an id, a title and a source URL, each titled as fabricated and pointing at the retraction so that a scanner lookup or a future run resolves the id to the correction. That reasoning was too confident about the index being unfalsifiable, and the verifier proved it: the free-text title on one of those records asserted that JFrog had reproduction-tested the id when JFrog never mentions it, so the state index briefly contradicted the entry it was written alongside. The title has been rewritten. A field with no schema is still a field that can carry a wrong claim. The ATT&CK mapping on that entry is empty and stays empty: the finding is a vulnerability-data-integrity failure with no attacker behaviour to map, and bolting on a technique to clear the warning would be exactly the invention the mapping rules forbid. This is the run's one surviving warning and it is deliberate.
The confirmation pass earned its keep — it found a real coverage miss, and the miss was ours twice over. Iteration 3 (Opus, the confirmation pass after iteration 2's CLEAN) refused to confirm and flagged in-window reporting this run had not assessed at all: The Hacker News, SecurityWeek and SC Media all covered Resecurity's SonicWall SMA 1000 research on 2026-08-03, on a CVE pair this store has carried since 2026-07-14. A scoped follow-up research agent verified it, and its conclusions reshaped the entry substantially from the verifier's own framing of the lead: the actor attribution is not new (Rapid7 named INC Ransom on 2026-07-17, published by Dark Reading the same day, hours before this pipeline's 2026-07-18 entry, which missed it), and the Swiss-victim element is a single-vendor characterisation of criminal leak-site postings with no named organisation, no confirmation and no stated link between any individual listing and the exploit chain. So the entry ships as a tightly-scoped escalation delta whose defender value is elsewhere: Rapid7 observed the actor rolling an applied patch back to a vulnerable state, which means version-checking is not an eviction test, and the required credential-rotation scope is wider than the 2026-07-18 entry stated. The Swiss claim is recorded as unverified and drives neither the framing nor the regions field. Two process points for the operator: the follow-up also caught Resecurity overstating the attribution chain ("Volexity and Rapid7 have since linked…" — Volexity has published no INC link at all), and it noted that the 2026-07-18 entry cites its Rapid7 source by last-modified rather than first-publication date, a cosmetic artefact on an immutable record.
Deliberate non-update decision: the CrowdStrike Threat Hunting Report entry shares the entity actor:sapphire-sleet with the 2026-07-30 Amazon DPRK-attribution entry, and the gate rightly asks whether that should have been a delta. It should not. The two are different stories: the earlier entry is Amazon's medium-confidence attribution of the axios, debug and chalk compromises to that cluster; this one is a newly published annual report whose own subject is exploitation velocity and supply-chain concentration, and which happens to add one new tradecraft detail on the same actor (the June 2026 injection into 131+ Mastra AI framework packages). The report is covered once as its own annual-report entry per the periodic-report rule and referenced thereafter. The actor is named in the body only to stop a reader treating CrowdStrike's STARDUST CHOLLIMA cryptonym as a new adversary — it is already an alias on the existing record.
Coverage gaps: cert-pl (essential tier — advisory discovery through the tracked /en/news/ path is dark; the working path is now recorded on the record); cert-at (tracked news paths return no dated rows; homepage recipe recorded); google-tag, claroty-team82, recordedfuture-insikt (listings carry no publication dates or resolve to the wrong feed — recency unverifiable this run); prodaft (reader hydrates the listing but renders no dates); siemens-productcert-csaf (CSAF directory 403s every UA and no fresh Siemens ICS CVE surfaced to supply an ssa- id); depthfirst (homepage teasers carry no dates); chrome-releases (feed returned 0 items, cross-checked against the blog — no Stable Channel security release in range, so the empty feed hid nothing).
Watchlist: products checked=0, hits=0; suppliers checked=0, hits=0 — no product or supplier watchlist is configured in the organization profile, so both sweeps are no-ops and the general coverage rules applied unchanged. No entry this run carries watchlist_hit.
Essential-coverage: all 15 essential-tier records were attempted across S1 and S2 and all returned content on some transport rung; fetch_failures[] is empty because nothing was unreachable on every rung. tools/source_health.py probed 174/174 sources in 96 s with zero UNSOLVED flags, so no repair order was outstanding this run.
Two of the five live jina reader credentials returned HTTP 402 balance-exhausted on every call, with automatic rotation to a working key each time. No fetch was lost, but the pool has less headroom than its aggregate balance suggests; both S2 and S3 flagged it independently.
One source-record duplication was caught and reverted before commit: the S2 agent proposed ACN / CSIRT Italia as a new candidate on the basis that Italy had no record in the source list, which was wrong — csirt-acn-it already existed, demoted since 2026-06-20 for having no readable transport. The health probe surfaced the collision. The duplicate was removed and the existing record recovered to active instead, carrying the working per-publication-slug recipe this run verified. VenariX took the single candidate slot.