The Hacker Diaries — Featuring Jennifer Hudsen: Case File No. 002

CoSnitch: the consumer Copilot case

Verdict: a serious one-click hosted-service chain, now fixed; consumer Copilot Personal/Web is the supported scope, not Microsoft 365 Copilot.

What happened

Varonis researchers demonstrated that a signed-in user opening a prepared Copilot link could cause an attacker-supplied prompt to run inside the user’s consumer Copilot session. The prompt could retrieve information that Copilot already held or could reach through previously authorized consumer connectors, then use ordinary URL-fetching behavior to send data outward. The chain did not grant a new OAuth permission or enlarge the underlying account’s authorization; it exploited the concentration of access the user had already approved.

The researchers also described a separate persistent-memory route. If a user asked Copilot to summarize attacker-controlled web content, indirect instructions in that content could influence memory and later sessions. That matters during recovery because changing a password or revoking a session does not necessarily remove content stored in an assistant’s memory.

Verified evidence and timeline

Varonis says it reported the findings in December 2025. Independent reporting says Microsoft disabled the useful prefilled-query behavior in February 2026, with broader fixes arriving August 18. Microsoft’s advisory for CVE-2026-24301 lists Copilot Web as an exclusively hosted service, rates it Critical with CVSS 8.8/High, and says it is fully mitigated with no customer action needed to apply the fix. The exact mapping between all three Varonis findings and the single CVE remains unclear.

Who was exposed; what was observed in the wild

The demonstrated exfiltration path required a user signed into Copilot Personal/Web, a click on the prepared link, and useful data in Copilot or an already authorized Outlook.com, OneDrive, Gmail, Google Drive, Calendar, Contacts, or similar consumer connector. The memory path instead required summarizing attacker-controlled content. Varonis reported no wild exploitation; Microsoft marked exploited “No”; CISA SSVC said exploitation “none”; and CVE-2026-24301 was absent from CISA KEV catalog version 2026.08.18. Those are strong current signals, not proof that nobody ever tried it.

What succeeded, failed, or remains unknown

The lab chain succeeded at using an authenticated assistant and existing connector access. User interaction was required, and the attack did not magically acquire permissions the user had never granted. It is unknown whether Microsoft retroactively removed suspicious memories written before the fix. It is also uncertain whether every demonstrated technique belongs under the CVE. Do not import Microsoft 365 Copilot’s tenant audit and Defender controls into this consumer product narrative; the products and administrative boundaries differ.

Why it matters at home and in a small business

Homes and small offices may connect mail, storage, contacts, calendars, invoices, and recovery messages to one consumer identity. That turns the assistant into a privileged data broker. Keep connections few, purposeful, and reviewed.

Immediate actions, detection, and recovery

• No software update is needed for this fixed hosted flaw. Review consumer Copilot connectors and disconnect those no longer needed.
• Treat links that open an AI assistant with a prefilled request as untrusted, whether delivered by email, chat, QR code, or a website.
• Review Copilot memory for unfamiliar entries and connected-service account histories for unexpected access. Unexpected bulk retrieval or odd URL fetching is a triage clue, not a unique IOC.
• If behavior before August 18 looks suspicious, preserve the link, chat, timestamps, browser history, connector list, and memory screenshots. Delete unfamiliar memories manually, inspect connected accounts, and rotate only secrets plausibly accessed—from a clean device.

Direct sources: CoSnitch: When Your AI Assistant Becomes Its Own Whistleblower; Microsoft Copilot Information Disclosure Vulnerability; Connecting Microsoft Copilot to other services.

The “mind virus” experiment: a laboratory warning, not an outbreak

Verdict: a v1 preprint demonstrated persistent prompt propagation under controlled conditions. It did not establish successful self-sustaining spread in production networks.

What happened

Researchers affiliated with the Anthropic Fellows Program, EPFL, and Anthropic evolved persuasive natural-language instructions that encouraged agents to preserve instructions in editable files and convince another agent to copy them. The central security condition was architectural: an editable file such as SOUL.md was injected into the next session as trusted system-prompt content, while agents had messaging, filesystem, memory, and sometimes shell tools. This was not a conventional malware exploit and should not be described as one.

Verified evidence and timeline

The paper was submitted to arXiv on August 10, 2026 at 20:37:57 UTC as version 1. In later-hop attempts, 88% came from agents infected through SOUL.md, and 55% infected the target; ordinary-file attempts were fewer and less successful. A favorable 20-hop test reached hop 20 only after other state was wiped and transmission was forced through the trusted file—a stress test, not a field event. A defensive warning stopped the initial comparison, and after 15 optimization generations and more than 150 candidates, none propagated beyond one hop. Encouraging, but not a permanent boundary.

Who or what is exposed; what was observed in the wild

The relevant exposure is a multi-agent system where untrusted messages can modify persistent control files, those files are automatically trusted in later prompts, and agents hold consequential tools. Idle agents with weak task or identity structure generally proved more susceptible. The authors’ rough archive analysis filtered about 1.4 million Moltbook posts, retained around 2,000 candidates from about 400 unique authors, and found attempts at self-propagating behavior—but likely no successful mind-virus propagation. A local social-network clone also failed to produce a pure prompt that infected at hop two.

What succeeded, failed, or remains unknown

Persistence worked in carefully constructed chains, especially when malicious instructions reached the automatically trusted file. Some model/setup combinations resisted; one Sonnet 4.6 agent removed the content and warned its peer. Model capability alone did not predict resistance. No independent replication was identified by the cutoff, and results depend on model version, prompts, topology, task load, tool rights, and LLM-judge thresholds.

Why it matters

Developers, MSPs, and businesses increasingly run assistants with repository, shell, ticket, or cloud access. The practical finding is that an editable, automatically trusted memory file is control-plane configuration: if untrusted content can rewrite it, persuasion can become persistence.

Immediate actions, detection, and recovery

• Make system instructions immutable or signed. Require human or deterministic approval for persistent prompt and memory changes, with author, timestamp, provenance, and diff.
• Keep retrieved content and peer messages out of control-plane files. Apply least privilege to shell, filesystem, network, and credential tools; block destructive operations outside the model.
• Hunt for unexpected changes to bootstrap or memory files, repeated instruction blocks across agents, unrelated persistence language, new files, unapproved installers, and abandonment of assigned work.
• For a suspected event, stop cross-agent messaging and dangerous tools, snapshot sandboxes and transcripts, diff every persistent file, map every recipient, and clean all affected agents together. Partial cleanup may permit recolonization.

Direct source: Mind Viruses: Self-Propagating Ideas in Multi-Agent LLM Systems.

MLflow CVE-2026-64849: scanning, attempts, and the missing proof of success

Verdict: patch urgently. Researcher telemetry supports broad scanning and attempts to reach cloud metadata, but not a disclosed victim count or independently verified successful credential theft.

What happened and who is exposed

MLflow before 3.15.0 could be abused through webhook behavior when a reachable Tracking Server used the relevant model-registry webhook functions, commonly with a SQL-backed store, and allowed outbound access. Validation covered the first destination but not every subsequent redirect or connection-time resolution. The vulnerable test behavior could return upstream content, creating a full-read server-side request forgery risk. Default unauthenticated webhook endpoints made an internet-reachable open-source server especially attractive.

Verified evidence and timeline

The fix shipped in MLflow 3.15.0 on July 31; 3.15.1, released August 3, was current at the cutoff. The CNA record, published August 17 and updated August 18, gives CVSS 9.3 and the affected range below 3.15.0. An older GitHub advisory package-range field remained stale, so the later CNA and release metadata are the safer version authorities.

What was observed in the wild

watchTowr reported broad scanning and malicious requests against cloud-hosted MLflow systems intended to reach metadata and obtain credentials. That is meaningful attempted exploitation, not merely a proof-of-concept on a researcher’s desk. Still, public evidence did not disclose a production victim, successful use of stolen credentials, or a denominator. CISA’s August 18 SSVC enrichment said exploitation “none,” and MLflow was not in KEV version 2026.08.18. The likely explanation is timing or criteria; neither signal should erase newer researcher telemetry.

What succeeded, failed, or is unknown

The vulnerable primitive and metadata-targeting attempts are established. Successful theft and later account use are not. There is no public victim count. A scan finding your server proves exposure and adversary interest, not compromise; a successful request can expose short-lived workload credentials even if no malware ever lands on the MLflow host.

Why it matters locally

A temporary MLflow experiment may remain public while its cloud role can reach storage, datasets, secrets, or deployment systems. One forgotten dashboard can become an organization-wide incident.

Immediate actions, detection, and recovery

Order matters: if compromise is plausible, preserve application, proxy, DNS, and cloud evidence before changing the deployment. The bullets below are defensive workstreams, not a substitute for that sequence.

• Upgrade to 3.15.0 or later; prefer 3.15.1, current at the cutoff. Remove direct public reachability and enforce authentication and authorization.
• Restrict egress and access to cloud metadata, loopback, link-local, and private management services. Use least-privileged workload identities.
• Review proxy and MLflow logs for unusual unauthenticated webhook creation/testing, new destinations, and bursts. Correlate MLflow process DNS and flow logs with metadata or internal-service access.
• Check cloud audit logs for role use from unexpected networks, regions, agents, or sessions. If access is plausible, preserve logs and rotate role credentials, API tokens, webhook secrets, and reachable internal secrets from a clean admin system.
• If unauthorized cloud actions or command execution are found, inspect for persistence and rebuild affected hosts or containers from trusted images. Patching does not revoke credentials already copied.

Direct sources: Unauthenticated full-read SSRF in MLflow webhook delivery: _validate_webhook_url bypassed via unvalidated HTTP redirects (and DNS rebinding); MLflow 3.15.1.

FUXA CVE-2026-25895: an attempted write is not confirmed code execution

Verdict: malicious scanning and an attempted arbitrary file write were observed. The disclosed request used junk, not an RCE payload, and successful compromise was not established.

What happened and who is exposed

FUXA 1.2.9 and earlier exposed an unauthenticated upload path that could write outside the intended location. For code execution, a consequential file had to be overwritten and later loaded or executed with sufficient service permissions. The advisory says setting secureEnabled=true did not remove the flaw. Any remotely reachable HMI/SCADA management host running an affected version deserves immediate attention, particularly where the service account can write application or startup paths.

Verified evidence and timeline

The fix arrived in 1.2.10 on January 25, 2026. The advisory was published February 4 and updated February 9; the CNA record rates it CVSS 9.5. Version 1.3.4, released August 12, was current at the cutoff.

What was observed; what succeeded or failed

VulnCheck reported one source broadly scanning on August 18 and trying to overwrite main.js with junk. About 60 installations were publicly visible in its intelligence view, but visibility is not a count of affected versions, victims, or compromises. No RCE payload was seen. It is also important that “New KEV” in the researcher’s social post did not mean CISA KEV: FUXA was absent from CISA’s catalog snapshot.

Why it matters

FUXA may sit near equipment, controllers, engineering workstations, and operational credentials. A successful write can poison application or startup code, so this is more than a website error.

Immediate actions, detection, and recovery

Order matters: if file modification or compromise is plausible, preserve HTTP logs, filesystem metadata, process evidence, and OT audit records before patching or rebuilding. The bullets below are defensive workstreams.

• Upgrade to 1.2.10 or later; prefer 1.3.4. Remove the interface from the public internet and require an authenticated VPN or jump host with restrictive allowlists.
• Run the service with minimum OS and filesystem rights; make code/startup paths read-only where operations permit. Segment the HMI host from controllers and safety-critical networks.
• Search HTTP logs for unauthenticated uploads, traversal-like path elements, odd target filenames, or bursts from automated clients. Verify hashes and timestamps of main.js, startup scripts, configuration, and every service-writable consequential file against trusted release artifacts.
• Hunt for child shells, unexpected processes, service restarts, scheduled tasks, new accounts, and outbound connections. In OT, inspect configuration and set-point audit trails.
• If arbitrary write succeeded or integrity cannot be proved, preserve logs and metadata, rebuild from trusted media, rotate reachable credentials, validate controller logic and operator accounts, and only then reconnect.

Direct sources: FUXA Unauthenticated Remote Code Execution via Arbitrary File Write in Upload API; v1.3.4.

Ray CVE-2025-62593: what CISA’s KEV label does—and does not—prove

Verdict: CISA added the flaw to KEV, whose standard includes attempted exploitation. The detailed public RondoDox attempt was ineffective; public evidence reviewed does not confirm a successful real-victim compromise through this exact CVE.

What happened and who is exposed

Ray before 2.52.0 could be reached through a browser DNS-rebinding chain in the advisory’s Firefox and Safari scope. A user had to visit attacker-controlled content, while a Ray Dashboard or Jobs API was reachable from that browser on the local host or private network. The browser could then become a confused deputy against an unauthenticated control service. Direct internet exposure is not required, although it is still dangerous. Merely having the package installed without a running reachable dashboard is not the same exposure.

Verified evidence and timeline

Ray 2.52.0, released November 21, 2025, fixed the issue and introduced token authentication, but that authentication is disabled by default. The advisory and CVE were published November 26. CISA added CVE-2025-62593 on August 17, 2026 and gave federal civilian agencies an August 20 due date; ransomware use was “Unknown.” Ray 2.57.0, released August 11, was current at the cutoff.

What was observed in the wild

BitSight saw RondoDox attempt this CVE on November 24, 2025. Its implementation used a User-Agent beginning with Mozilla, causing Ray to return HTTP 405, so that observed attempt failed. CISA defines active exploitation broadly enough to include attempts against honeypots or non-vulnerable systems, while excluding scanning alone. CISA may also hold evidence it has not published. Both extremes are wrong: KEV does not prove named victims were compromised, and one failed public attempt does not prove every attempt failed.

ShadowRay 2.0 is not corroboration for this CVE. That campaign exploited CVE-2023-48022, a different Ray flaw. It illustrates the danger of exposed unauthenticated Ray APIs but cannot be used to claim successful CVE-2025-62593 exploitation.

Why it matters

Ray often joins source code, models, cloud keys, data, and expensive compute. A malicious page can target a private service through a developer’s browser even when port 8265 was never public.

Immediate actions, detection, and recovery

Order matters: if attempted or unauthorized jobs are plausible, preserve Ray, DNS, browser-adjacent, process, container, and cloud evidence before changing the cluster. The bullets below are defensive workstreams.

• Upgrade every head node, worker, container, pod, and developer environment to 2.52.0 or later; prefer 2.57.0. Confirm old replicas are actually gone.
• Explicitly enable and test token authentication where supported. Do not assume the upgrade enabled it. Restrict Dashboard, Jobs API, port 8265, and other control-plane ports at host, cloud, Kubernetes, and load-balancer layers.
• Review Dashboard and Jobs logs for unapproved submissions, unusual origins, rapid DNS changes, suspicious POSTs, HTTP 405 responses, and odd Host, Origin, Referer, or User-Agent patterns.
• Inventory jobs, runtime environments, worker processes, entry points, and artifacts. Hunt cluster-wide for shells, miners, new keys, accounts, credential access, persistence, and unexplained outbound traffic.
• If unauthorized jobs ran, preserve logs and cluster state, rebuild affected nodes, inspect the whole cluster for lateral movement, and rotate cloud, repository, SSH, registry, model, and data-store credentials from clean systems.

Direct sources: Critical RCE Vulnerability against Ray Devs exploitable via Browser (Safari & Firefox) due to DNS Rebinding Attack; CISA Adds One Known Exploited Vulnerability to Catalog; RondoDox Botnet: From Zero to 174 Exploited Vulnerabilities. See The IT Guys’ dedicated Ray advisory for a focused patch checklist.

Ransom Busters: the “rescuer” who already knows the crime scene

Verdict: GuidePoint observed a follow-on operation contacting ransomware victims with inside knowledge and demanding $20,000–$60,000. Claims of controlling broad ransomware infrastructure and decryptors remain actor claims.

What happened

After several ransomware incidents, an operation presenting itself as an independent recovery service approached victims before the events were public. It knew the same stolen data as the ransomware affiliate and offered to recover data or solve the problem for a second payment. GuidePoint compared two environments in detail and found recurring artifacts supporting a moderate-confidence assessment that one affiliate operated across multiple ransomware-as-a-service programs, including incidents associated with DragonForce, Settra, and Anubis.

Verified evidence and timeline

The public disclosure arrived August 18; individual incident dates were withheld. Cross-case evidence included the repeated attacker-controlled hostname DESKTOP-BBETH6K and a recurring combination of SoftPerfect Network Scanner, s5cmd, and Remotely RMM. These behaviors are useful hunting pivots when validated in context. They are not a public census of everyone contacted.

Who is exposed; wild activity

The target is already a ransomware victim or an organization whose data was exfiltrated. Confidential knowledge makes the unsolicited offer credible. Several incidents are observed, but only two received the disclosed forensic comparison. The operation’s claim that it had three years of access to ransomware panels, controlled “almost all” infrastructure, possessed keys, and could erase every backup was not independently verified.

What succeeded, failed, or is unknown

The approach succeeded at proving access to victim-specific knowledge and creating a plausible second extortion channel. There is no disclosed total for contacts, payments, decryptions, deleted data, or victims. Payment cannot establish that every copy was destroyed; once data has been stolen, neither the original ransomware operator nor a purported rescuer can offer a technically verifiable deletion guarantee.

Why it matters

Exhaustion after ransomware makes a polished rescue pitch persuasive. Verify the responder through an insurer, counsel, established provider, or law enforcement—not the channel that appeared after the breach.

Immediate actions, detection, and recovery

• Preserve the message, headers, call details, wallet/payment instructions, and timestamps. Do not negotiate or pay an unsolicited recovery operation.
• Notify the existing incident-response lead, counsel, cyber insurer where applicable, and law enforcement. Verify every “helper” using a number obtained independently. The IT Guys’ known-number callback tip explains the habit.
• Correlate DESKTOP-BBETH6K and the uncommon tool combination across endpoint, cloud-storage, and remote-management logs. Revisit the first intrusion for surviving accounts, sessions, scheduled access, or overlooked persistence.
• Before rebuilding systems, revoking sessions, or rotating credentials, preserve relevant endpoint, cloud, remote-management, identity, process, account, and persistence evidence. Coordinate destructive containment steps with the incident-response lead.
• Assume exfiltrated material may exist in multiple hands. Contain and rebuild affected systems, revoke sessions, rotate exposed credentials, meet notification duties, and monitor for re-extortion.

Direct source: Beware the Ransomware Rescuer: Ransom Busters.

TWINLOOT: one recovered investigation, many dangerous capabilities

Verdict: Ontinue recovered a sophisticated Python implant in one disclosed July investigation. The evidence does not establish a victim count, a known operator, widespread compromise, or ransomware deployment.

What happened

The intrusion started with an external Microsoft Teams contact impersonating IT support and persuading a user to run attacker-supplied content. No Microsoft software vulnerability is established. The recovered TWINLOOT build used an attacker-owned SharePoint tenant for tasking, Microsoft Teams TURN infrastructure for interactive traffic, and headless Edge to make Graph traffic originate from a trusted browser process. Recovered functionality included a credential-capture interface, network pivoting, persistence options, and command execution.

Verified evidence and timeline

An aged domain was re-registered June 7; a second was acquired June 21; a joint certificate linked them July 21; the recovered build was compiled July 24; continuous configuration heartbeats appeared July 27–30; and Ontinue disclosed the investigation August 18. That is one recovered build and one public investigation. “Campaign” describes connected activity, not a proven worldwide victim population.

What was observed versus capability

SharePoint tasking, Teams relay traffic, browser-mediated Graph access, credential capture, pivoting, and persistence were present in the recovered material. Arbitrary commands and broad movement were capabilities, not automatically successful outcomes. A blockchain configuration fallback was unused in this build. Ransomware was not observed in it. Similarities to other operations were treated as parallels, not attribution; operator identity remains unknown.

Who is exposed; why it matters

External Teams contact plus broad trust in Microsoft-hosted traffic creates an opening, but a user still had to run content. Python, browser debugging, broad federation, and local admin rights can turn one support impersonation into a durable foothold.

Immediate actions and detection

• Restrict unnecessary Teams external access and teach staff that legitimate IT will not ask them to run surprise content. Verify support through a known internal channel.
• Alert on python.exe or pythonw.exe in user-writable/nonstandard locations, Edge headless or remote-debugging use on ordinary workstations, and endpoint-originated administrative traffic outside the user’s role.
• Monitor managed devices contacting unfamiliar external SharePoint tenants. Endpoint, proxy, and CASB evidence matters because victim Entra logs may not show authentication inside the attacker-owned tenant.
• Ontinue published infrastructure including kerteransens.sharepoint.com, th2ch[.]com, lpi-web[.]com, and 193.24.211[.]221. Validate against current vendor intelligence and local business context before blocking.

Recovery and escalation

Isolate endpoints showing the suspicious Python/Edge combination. Preserve process, browser, proxy, Teams, SharePoint, and identity telemetry. Reset credentials entered into a fake lock interface from a clean system, revoke sessions and refresh tokens, remove every persistence point, and rebuild when integrity cannot be established. Move priority users to phishing-resistant FIDO2 or passkey authentication. If data or regulated systems may have been reached, engage counsel and incident response promptly.

Direct source: Living Off the Cloud: A Python Implant Hiding Its Entire C2 Inside Microsoft 365 & Azure. If an M365 mailbox may already be compromised, use The IT Guys’ Microsoft 365 containment guide.

City-Forum: public portals, private-looking data

Verdict: Reco tied guest-user scraping against Salesforce and ServiceNow portals to one infrastructure/tool cluster. Event volume is not record count, and neither is a victim count.

What happened

Unauthenticated portal activity used the persistent guest identity to enumerate or scrape information through Salesforce Experience Cloud and ServiceNow Service Portals. Reco linked activity to 158.220.87.79, the user agent Go-http-client/1.1, and city-forum[.]com infrastructure. The core weakness was excessive guest authorization or misconfiguration, not a demonstrated product vulnerability.

Verified evidence and timeline

Passive DNS placed the infrastructure at the same IP from March 2025. That proves infrastructure tenure, not the campaign’s start. Activity was ongoing and increasing at Reco’s August 12 disclosure. One ServiceNow investigation grew from tens to hundreds of requests per day. A reported Salesforce target recorded more than 560,000 events. Events are requests or telemetry entries—not 560,000 records and certainly not 560,000 victims.

Who is exposed; what was observed

Organizations whose public portals give guest users unnecessary access to records, search sources, object fields, APIs, or knowledge content are exposed. Reco saw activity across telecom, finance, enterprise software/security/privacy, and government organizations worldwide, but named no victims and published no unique-organization or record total. It observed anonymous guest enumeration and scraping, not authenticated-user activity, though it could not rule the latter out.

What succeeded, failed, or remains unknown

The endpoints appeared to function as configured while returning information at machine cadence. Shared IP, domain, and user-agent patterns support one tool/infrastructure cluster but not a human identity or a connection to another named group. Unknowns include the actual campaign start, records retrieved, unique affected organizations, downstream use, and operator.

Why it matters

A portal can display a login button while guest APIs remain open. Permissive defaults, copied profiles, and forgotten tests persist; an administrator’s logged-in spot-check misses the anonymous view that matters.

Immediate actions, detection, and recovery

• Before changing access, export the guest profile, authorization, portal, and relevant object/search configuration and preserve server, event-monitoring, transaction, identity, proxy, and cloud logs.
• Test every public Salesforce and ServiceNow portal in a clean private browser as an anonymous user and determine what records were retrievable during the exposure window. Then reduce guest permissions to least privilege; disable guest public-API access and self-registration where unnecessary, and verify denial anonymously.
• In Salesforce, inspect AuraRequest and Sites Event Monitoring for the IP, user agent, LWR data-service path family, and nonhuman volume.
• In ServiceNow, inspect syslog_transaction for guest REST searches, machine cadence, the source/user-agent pair, and unusually large responses. Use vendor documentation before operational blocking.
• Assess notification obligations and rotate secrets or tokens that were mistakenly stored in readable records. Continue monitoring the preserved evidence for access that returns through another portal path.

Direct source: The “City-Forum” Campaign – An advanced attacker is targeting Salesforce and ServiceNow instances worldwide.

StubMaker RubyGems: sixteen names, seventeen publication events

Verdict: malicious typo-named gems crossed the install-time execution boundary and a Windows stealer was recovered. Downloads are not installations, victims, or proof of successful theft.

What happened

Malicious RubyGems packages abused installation-time native-extension behavior to execute hostile code. Every supported platform sent a platform beacon; the documented information-stealer chain continued on Windows. Static analysis found functions for collecting browser credentials and session cookies, saved payment-card data, wallet and seed material, Telegram data, and host information. Researchers did not identify direct transaction signing, fund transfer, or persistence in the recovered build.

Verified evidence, timeline, and the count

OpenSourceMalware found the activity August 15. Initial versions appeared and were yanked; names were later republished or reclaimed, and primary research appeared August 16. The sixteen unique names are ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler, and brundlef. The primary researcher’s seventeen-gem wave counts publication events because brumdler appeared in both waves. Sixteen and seventeen are different units, not contradictory victim totals.

Who is exposed; what was observed in the wild

A developer, build runner, image builder, or automated system had to install a malicious package. Windows was required for the recovered stealer stage; macOS and Linux installs still ran installation logic and beaconed. Researchers saw hundreds of registry downloads, but a download may be a scanner, mirror, cache, failed install, or researcher. Unique installations, exfiltration, financial loss, and the sameness of every downloaded build are unknown.

What succeeded, failed, or remains unknown

The packages were published, installation logic executed, and the Windows collection capability is supported by analysis. Public versions were yanked, which reduces new exposure but does not cleanse lockfiles, private mirrors, caches, containers, or developer images. Worse, yanking did not reserve every typo namespace permanently; one name could be republished from another account. No public total establishes credentials or funds actually stolen.

Why it matters

A developer laptop or build runner may bridge source code, deployment secrets, browser sessions, and money. Package-manager trust must mean more than “the command completed.”

Immediate actions, detection, and recovery

• Search lockfiles, manifests, build logs, package-proxy records, caches, images, SBOMs, and endpoint software history for all sixteen exact names and versions. Block future resolution internally even though public copies were yanked.
• Alert on Ruby/RubyGems making network connections during extension installation, dummy native-extension builds paired with traffic, Ruby spawning downloaded executables, and rapid access to multiple browser, wallet, and Telegram stores.
• Published defensive network clues include 193.70.34[.]101:20099 and dresslee[.]com:20027; use the primary researcher’s hashes for EDR matching and validate context before blocking.
• If installed, isolate the host. Before revocation or rebuilding, preserve package and build records, disk and memory evidence when feasible, process/network/EDR telemetry, and relevant identity and cloud logs. Then, from a clean device, revoke browser and Telegram sessions, rotate exposed browser-stored credentials, replace saved payment cards, and treat any recovery phrase stored on that machine as stolen.
• Move crypto to newly generated wallets on a trusted device. Rebuild developer and CI systems where integrity cannot be proved, then rotate repository, registry, signing, and deployment credentials and verify clean versions, sessions, jobs, and outbound traffic.

Direct sources: StubMaker RubyGems Campaign Delivers a Windows Infostealer; StubMaker: RubyGems `extconf.rb` typosquats delivered a Windows infostealer.

SafePal: confirmed order exposure, not confirmed key exposure

Verdict: SafePal confirmed unauthorized access to order information for about 39,798 customers. It says cryptographic wallet secrets, balances, and payment data were not exposed.

What happened and who is exposed

An authorization flaw in an order-tracking plug-in allowed external unauthorized access to names, email addresses, phone numbers, shipping addresses, and purchase details. SafePal says affected customers were notified by a specific August 16 email and can use its official status-check/support process. The affected records relate to orders placed from March 2, 2025 through April 11, 2026. That is an order-date range, not a proven exploitation window.

Verified evidence and timeline

The first report consistent with the issue arrived in early May, according to the incident FAQ chronology. SafePal reviewed and rebuilt the broader order pipeline in July, notified customers August 16, and updated its notice August 18. The company acknowledged claims that data was being sold but said it could not verify authenticity. No actor, plug-in vendor, affected version, CVE, or count of unauthorized parties was disclosed.

What was observed; what was not exposed

External unauthorized access to the order subset is confirmed. SafePal says seed phrases, private keys, wallet passwords, wallet addresses and balances, bank details, card numbers, and government identification were not exposed. There is no confirmed wallet compromise, fund theft, physical attack, or independently authenticated criminal-forum dataset in the frozen evidence.

What succeeded, failed, or remains unknown

The privacy breach succeeded at linking identifiable people and home addresses to hardware-wallet purchases. That is enough for highly tailored email, phone, postal, fake-support, refund, firmware-update, replacement-device, or malicious-delivery approaches. It is not enough to move cryptocurrency without another deception or compromise. The actual exploitation start/end, actor count, discovery method, flaw details, sale-claim authenticity, and attributable losses remain unknown.

Why it matters at home

A home address linked to a hardware-wallet purchase raises fraud and personal-safety concerns. Never confirm ownership, holdings, devices, schedules, or household details to an unexpected caller or visitor.

Immediate actions, detection, and recovery

• Never reveal a recovery phrase, private key, or wallet password. Treat messages, calls, packages, refunds, firmware updates, and “replacement devices” referencing the purchase as suspicious.
• The reported legitimate notice used security@safepal.com and the subject “[Important] Your SafePal Order Information Has Been Affected,” but sender and subject can be spoofed. Manually type SafePal’s official domain; do not trust message links.
• Preserve suspicious messages, phone details, envelopes, labels, and packaging. Watch for brand impersonation across email, SMS, voice, postal mail, and lookalike domains.
• SafePal says funds do not need to move solely because order data was exposed. If a phrase or key was ever entered, spoken, photographed for a stranger, or placed into an untrusted app, treat that wallet as compromised and move remaining assets to a newly generated wallet from a trusted device.
• Report losses promptly to the relevant exchange, financial institution, law enforcement, and support channel while preserving transaction and communication evidence.

Direct source: Unauthorized Access To A Subset Of Customer Order Information.