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

Case File No. 025 · September 15, 2026

Eight files landed on tonight’s desk: a forged banking extension, state-linked spyware, a quiet MQTT controller, a notebook-to-cloud pivot, a Vite secret-hunt, a shared-hosting escape, an exploited email gateway, and a Chrome–Windows zero-day chain. Different alleys, same lesson: reduce exposure before the first alert, preserve evidence before cleanup, and never confuse a scanner, a vendor assessment, or a CVSS score with proof of a completed breach.

Tonight’s risk at a glance

File 1 — KREMLIN forges browser trust to steal Brazilian banking sessions

What happened

Elastic Security Labs says it tracked REF9334 across seven campaigns and 15 months, beginning in May 2025. The operation used lures impersonating about a dozen Brazilian banks and delivered the KREMLIN toolkit, including loaders, installers, and a malicious Chrome/Edge extension.^[1] Elastic’s research is primary vendor telemetry; the campaign scope and victimology are its assessment, not a government attribution.

Verified evidence and timeline

Elastic dated recovered campaign phases from June 2025 through May 2026 and documented a later transition to Ethereum smart-contract data as a configuration resolver.^[1] The researchers found the extension could collect cookies, local and session storage, tab state, page HTML, screenshots, and browser-history data, though at least one history function likely failed because the manifest lacked the required permission.^[1] That distinction matters: coded capability is not proof that every command worked on every host.

Who is exposed; what was observed in the wild

The documented targeting centers on Brazilian banking customers using Windows and Chromium browsers who are persuaded to run the delivered chain. The installation method attempted to bypass browser integrity protections rather than asking the user to install an ordinary store extension.^[1] Elastic describes campaign infrastructure and technical samples, but its public report does not publish a reliable count of successfully compromised people or stolen balances.

Immediate actions, detection, recovery

• If an unknown extension or banking-themed installer appeared, disconnect the device from sensitive accounts and preserve the installer path, browser-extension inventory, Windows event and endpoint logs, and approximate first-seen time.
• From a clean device, contact the bank through its published channel, revoke active banking sessions where supported, change credentials, and review transactions. Browser cookies and session tokens can remain valuable even after a password change.
• Administrators should review extension policies, unexpected externally installed extensions, browser profile directories, new persistence, unusual archive/runtime downloads, and connections to defanged indicators in Elastic’s report.^[1]
• For a confirmed host compromise, rebuild from trusted media after evidence collection rather than trusting extension removal alone.

Detection and verification

Correlate the extension’s installation source, browser-policy changes, profile artifacts, persistence, endpoint detections, and outbound traffic. One strange extension name is not enough; a reliable finding ties the installed bytes and launch path to the affected browser profile and the user’s banking timeline.^[1]

Recovery and escalation

Escalate immediately when the device handled banking, payroll, administrator, or customer sessions. Preserve evidence, then rebuild the endpoint, revoke browser and financial sessions from a clean device, verify transactions with the institution, and monitor for renewed access. Recovery is incomplete until the bank, browser accounts, and workstation all show no unexplained activity.

Why it matters to homes and small businesses

Small firms often use the same Windows computer for email, banking, payroll, and vendor portals. A stolen browser session can therefore bypass the neat boundary people imagine between “the PC” and “the bank account.” In the four Treasure Coast service cities, the right local lesson is to separate banking from casual browsing and to investigate an unexpected extension before using that browser again—not to assume this Brazil-focused campaign has been seen locally.

Confidence and unknowns: High on Elastic’s technical analysis and observed campaign history; unknown on total victims, losses, and whether every capability succeeded.

File 2 — CHOSEN BRICK / HEAVYGRAM targets dissidents, activists, and journalists

What happened

A joint UK–US–Netherlands advisory says CHOSEN BRICK has targeted people worldwide—including in the UK, United States, and Netherlands—from at least 2025. The FBI calls related malware HEAVYGRAM and assesses that Iranian Ministry of Intelligence and Security actors used it against dissidents, journalists, activists, and other perceived opponents.^[2][3] “Iranian state” remains an agency attribution, not a technical fact independently proven by the malware alone.

Verified evidence and timeline

The agencies describe researched social contact through services such as WhatsApp and Telegram, followed by a file disguised as a trusted application, security tool, media utility, password manager, or even medical-imaging result.^[2] In observed cases the Windows-only malware persisted through the current user’s Run key, could alter Defender exclusions, and used Telegram bots for command and control.^[2] The FBI says it analyzed seven samples acquired through investigations.^[3]

Who is exposed; what was observed in the wild

This is targeted espionage, not a claim that all Telegram users are exposed. Agencies observed screen capture, microphone recording, theft of email and web-based chat data, additional payload delivery, and—in at least one sample—data-wiping functionality.^[2] They did not observe automated lateral movement, though an operator could add tooling that changes that outcome.^[2] Computer Weekly independently reported the tri-government warning but relies on the agencies for core incident facts.^[4]

Immediate actions, detection, recovery

• High-risk individuals should never install software delivered through an unsolicited chat. Verify the sender through another established channel and obtain applications only from a vendor’s direct site or trusted app store.^[2]
• If execution is plausible, isolate the Windows device, preserve messages and files without reopening them, record Run-key and Defender-exclusion changes, and involve a qualified responder.
• Organizations should check corporate and, with consent, likely-targeted personal devices; the advisory says the actors may shift from managed work devices to personal ones to evade controls.^[2]
• Use phishing-resistant MFA, application allowlisting, current endpoint protection, network monitoring, and the agencies’ defanged IOCs and signatures.^[2]

Detection and verification

Start with the human report and the delivered file. Validate its real origin, signature, hash, execution time, persistence, Defender exclusions, Telegram-related network activity, and any screen, microphone, or browser-access artifacts against the agencies’ indicators.^[2][3] A Telegram installation alone is not evidence of infection.

Recovery and escalation

Because this campaign targets people who may face physical danger, escalation should include a trusted security contact and, when appropriate, organizational safety leadership—not only routine help-desk cleanup. Use a separate trusted device for sensitive communications, preserve the social-engineering conversation, rebuild a confirmed compromised Windows system, and reset exposed accounts and sessions from the clean device.

Why it matters to homes and small businesses

The delivery pattern exploits trust more than scale: a convincing sender, personal context, and a file that pretends to solve a real problem. Families, nonprofits, and small newsrooms should establish a second-channel verification rule before a high-risk person receives the message. The practical lesson is global and preventive; no cited source places a victim on the Treasure Coast.

Confidence and unknowns: High that the agencies observed this malware family and targeting pattern; agency-assessed for MOIS attribution and intent; unknown on the total victim population.

File 3 — BambooToken hides behind MQTT brokers

What happened

Lumen Black Lotus Labs disclosed a Windows-and-Linux malware family it calls BambooToken. Based on artifacts, Lumen assesses the activity ran from at least February 2023 through July 2026 and later adopted MQTT, a publish-and-subscribe protocol normally associated with connected devices, for command and control.^[5]

Verified evidence and timeline

Lumen identified Windows versions from 2023 through 2025 and a Linux sample first observed in December 2025. It assesses with high confidence that the Windows and Linux toolsets belong to the same cluster.^[5] MQTT means the compromised machine can exchange messages through a broker rather than contacting the ultimate operator infrastructure directly; that is an architectural advantage, not proof that MQTT itself is malicious.^[5]

Who is exposed; what was observed in the wild

Lumen says its telemetry indicated infections involving at least four back-end servers for mobile applications, legal and financial services, a smartwatch-related software company, a hotel, and one GitLab instance, across activity focused in Asia and South America.^[5] BleepingComputer independently summarized the publication, but the victim telemetry remains Lumen’s.^[6] Lumen could not confirm the original access vector and assessed that a legitimate Tendyron OnKey component was abused for side-loading; it did not assess that Tendyron’s signing certificate or build environment was compromised.^[5]

Immediate actions, detection, recovery

• Inventory OnKey and other security-token software, verify file signatures and installation paths, and compare components with trusted vendor packages.
• Monitor unusual MQTT traffic from systems that have no business reason to use it. Broker traffic needs context; blocking all MQTT could break legitimate operations.
• Review GitLab, back-end application, hotel, legal, and finance servers for unexpected binaries, side-loaded libraries, service persistence, WMI enumeration, and outbound broker connections using Lumen’s indicators.^[5]
• If a development or back-end server is affected, rotate reachable credentials and inspect downstream build, mobile-app, and deployment systems.

Detection and verification

Confirm whether the server normally speaks MQTT, which process owns the connection, which broker and topic pattern it uses, and whether related files, services, side-loaded libraries, or WMI activity match Lumen’s report.^[5] Protocol name and destination reputation are supporting evidence; the process tree, file identity, and timing decide whether the traffic belongs to the business.

Recovery and escalation

Escalate when a back-end, GitLab, or software-build system is involved because downstream packages and deployment credentials may be at risk. Preserve repositories, runner logs, build artifacts, package hashes, and cloud audit data before rebuilding the affected server. Rotate only the credentials that were actually reachable, then verify downstream products against known-good builds.

Why it matters to homes and small businesses

Most households will never run an MQTT broker, but many local businesses buy software, hotel systems, mobile services, and security-token products whose servers are outside their view. The defensible question for a provider is not “do you block MQTT?” but “can you prove where the service runs, what it can reach, and how you would detect an unexpected broker connection?”

Confidence and unknowns: High on sample relationships and Lumen’s telemetry; unknown on initial access, total infections, actor identity, and downstream impact.

File 4 — A marimo notebook pivot reached a bastion in eight seconds

What happened

Sysdig says it observed a human operator exploiting CVE-2026-39987, a pre-authentication marimo remote-code-execution flaw, then using already prepared tooling to obtain an AWS credential, retrieve a private key from Secrets Manager, and authenticate to a bastion host eight seconds after a fresh WebSocket session opened.^[7] The eight-second figure describes a later optimized pivot—not the entire intrusion. Sysdig says the operator had spent about four hours writing and debugging tooling during a nine-hour session with more than 850 interactive commands.^[7]

Verified evidence and timeline

The reviewed GitHub advisory covers marimo versions before 0.23.0 and marks 0.23.0 as patched. The vulnerable terminal WebSocket lacked the authentication check used by other endpoints.^[8] CISA had already added the CVE to KEV in April, with a May 7 federal deadline.^[7] Sysdig’s claim that this operator was human rests on its observed interactive development and failure to trigger prompt-injection bait that its prior agentic operators triggered; that is a research conclusion, not universal proof that no AI helped elsewhere.

Exposure and observed impact

Risk is concentrated in marimo servers reachable by untrusted clients and in the cloud authority carried by the notebook process. Sysdig observed credentials in both process environment and an application data backend, then a successful SSH pivot using a retrieved key.^[7] A marimo compromise does not automatically equal cloud-account compromise; the pivot succeeded because useful credentials and a reachable path existed.

Immediate actions, detection, recovery

• Upgrade to marimo 0.23.0 or later and remove public reachability for notebook terminals.^[8]
• If the endpoint was reachable since disclosure, preserve notebook/container, reverse-proxy, CloudTrail, Secrets Manager, SSH, and network logs; then rotate credentials and keys available to the process.
• Review cloud calls from unusual networks, secret retrieval, new SSH activity, notebook-container drift, and outbound connections. Scope the notebook role to the minimum possible.
• Rebuild a confirmed compromised workload and verify the bastion and cloud account separately.

Detection and verification

Join reverse-proxy and WebSocket access records to container process activity, AWS API calls, Secrets Manager retrieval, key-file creation, and SSH authentication. The eight-second sequence becomes meaningful only when those timestamps and identities align.^[7] A marimo version check alone cannot determine whether secrets were accessed.

Recovery and escalation

Escalate beyond the notebook owner when cloud credentials, secret stores, or bastions appear in the path. Preserve CloudTrail and identity records, disable exposed authority, rotate affected keys, inspect the bastion for subsequent commands, and rebuild the notebook workload. Verify that replacement roles cannot retrieve unrelated secrets before service resumes.

Why it matters to homes and small businesses

A small development shop may treat a notebook as a harmless experiment while it quietly inherits powerful cloud credentials. The speed in this case does not demand faster humans at the keyboard; it demands less public exposure and less authority available to steal. That is the practical local lesson for any Treasure Coast business hosting AI, data, or automation tools.

Confidence and unknowns: High on Sysdig’s observed session and advisory scope; unknown on the victim’s identity and whether similar operators used the same sequence elsewhere.

File 5 — Exposed Vite development servers face automated secret-hunting

What happened

F5 reported sustained August scanning against internet-exposed Vite development servers, recording 807 session-grouped attacks and about 32,000 raw events. The probes matched CVE-2026-39364 and older Vite bypass patterns while cycling through environment files, cloud credentials, Azure material, and infrastructure-as-code state.^[9]

Verified scope and prerequisites

GitHub lists affected Vite branches as 7.1.0 through 7.3.1 and 8.0.0 through 8.0.4, fixed in 7.3.2 and 8.0.5.^[10] The app must expose the dev server to the network, the requested file must be within server.fs.allow, and a deny pattern must match it.^[10] Vite’s normal localhost binding and production builds are not equivalent to a publicly mapped dev server.

Observed in the wild; what remains unknown

F5 saw raw request activity jump from 1,732 events over the prior three months to more than 32,000 in August.^[9] BleepingComputer independently reported the sensor findings, while the telemetry remains F5’s.^[11] Requests and even HTTP 200 responses in honeypots do not publish a count of real organizations whose valid keys were stolen or abused.

Immediate actions, detection, recovery

• Upgrade affected branches and eliminate public exposure of Vite dev ports; audit Docker mappings, cloud security groups, Kubernetes ingress, reverse proxies, tunnels, and preview environments.^[9][10]
• Search access logs for unusual file-serving paths and parameter patterns, then correlate with response sizes and cloud audit logs. Do not equate a probe with successful credential theft.
• If sensitive material may have been returned, preserve logs, revoke and rotate exposed credentials, check for cloud use from unusual sources, and review Terraform state and deployment secrets.
• Move secrets out of developer-readable files where practical and use short-lived, narrowly scoped identities.

Detection and verification

Inventory every Vite service and compare its bind address, container mapping, ingress rule, and running version with the advisory prerequisites.^[10] In access logs, distinguish a request attempt from a successful response; then ask whether a returned file contained a live secret and whether that secret was used in cloud audit records.

Recovery and escalation

Escalate when logs show a sensitive file was returned or when the service held administrator-grade cloud material. Preserve the request and response metadata, close exposure, update Vite, revoke the affected secret, and review cloud changes made with it. Rebuilding the container without rotating a stolen credential leaves the most important part of the incident open.

Why it matters to homes and small businesses

Public development ports often appear during a rushed demo, remote-work tunnel, or container deployment—not a deliberate production decision. Small teams can reduce the risk by making public exposure an exception that requires an owner, an expiry time, and a credential review. F5’s scan volume shows that forgotten services do not remain obscure for long.^[9]

Confidence and unknowns: High on affected versions and F5’s sensor counts; unknown on confirmed victim count and subsequent cloud compromise.

File 6 — LiteSpeed Enterprise shared-hosting boundary can fall to a tenant

What happened

cPanel warned that a critical privilege-escalation flaw in LiteSpeed Web Server Enterprise before 6.3.7 could allow a malicious low-privilege website user on a shared server to bypass account-isolation controls, including CageFS, and gain root-level access.^[12] LiteSpeed released 6.3.7 on September 11 with security improvements; cPanel published its explicit warning September 14.^[12][13]

Exposure and evidence boundary

The prerequisite is already having a low-privilege hosting account or equivalent tenant foothold on a shared Enterprise server. This is not described as an unauthenticated Internet-to-root flaw. The public advisory gives no CVE, technical mechanism, CVSS score, exploitation confirmation, or indicator set.^[12] Earlier LiteSpeed cPanel-plugin flaws were exploited, but that history must not be transferred to this separate web-server flaw.

Immediate actions, detection, recovery

• Hosting administrators should force-update LiteSpeed Enterprise to 6.3.7 or later rather than waiting for a delayed automatic rollout.^[12]
• Before updating a suspicious server, preserve tenant, privilege, process, authentication, file-integrity, audit, control-panel, and outbound-network evidence.
• After updating, verify the running binary version—not only the downloaded package—and inspect high-risk tenant accounts for unexpected root-owned changes or cross-account file access.
• Customers on shared hosting should ask the provider to confirm the running Enterprise version and incident-review status; they usually cannot validate the host themselves.

Detection and verification

The public advisory supplies no IOC, so operators must use their own tenant, privilege, process, file-integrity, authentication, and network evidence while comparing the running LiteSpeed Enterprise version with 6.3.7 or later.^[12] A package repository showing 6.3.7 is not proof that the server process was updated.

Recovery and escalation

If cross-account access or root activity is suspected, treat the whole host as potentially untrusted. Preserve host and control-panel evidence, isolate it from management networks, involve the hosting vendor, rebuild from trusted sources, rotate host and tenant credentials that were reachable, and validate each customer site separately before returning traffic.

Why it matters to homes and small businesses

Shared hosting turns one machine into a neighborhood. A tenant-to-root flaw threatens boundaries between otherwise unrelated websites, email forms, and databases. Local business owners cannot patch the host themselves, but they can demand the exact running version, a dated provider statement, and a restore plan instead of accepting “automatic updates are enabled.”

Confidence and unknowns: High on cPanel’s affected-version and impact statement; unknown on exploitation, mechanism, CVE assignment, OpenLiteSpeed status, and 6.4 release-candidate status.

File 7 — Cisco Secure Email Gateway zero-day is actively exploited

What happened

Cisco published CVE-2026-76461 on September 14 with a 9.8 CVSS score. The flaw affects physical and virtual Secure Email Gateway appliances regardless of configuration; a crafted email can reach vulnerable parsing logic and lead to root command execution.^[14] Cisco says its incident-response team became aware of active exploitation in September 2026, and CISA added the CVE to KEV based on evidence of exploitation.^[14][15]

Fixed releases and exposure

Cisco lists 15.5.5-014, 16.0.4-302, and 16.5.0-780 as the first fixed releases for their branches and strongly recommends migration to 16.5.0-780. There is no workaround.^[14] Secure Email and Web Manager and Secure Web Appliance are listed as not affected by this CVE.^[14] Cisco says its cloud fleet was upgraded and that it directly contacted cloud customers where possible-compromise indicators were identified.^[14]

Observed in the wild; what remains unknown

Cisco confirms active exploitation but does not identify the actor, victim count, start date, or public exploit code. BleepingComputer and Rapid7 independently reported the advisory and KEV status but rely on Cisco for exploitation evidence.^[16] Calling it a zero-day is reasonable because exploitation preceded or coincided with public disclosure and a broadly available fix; it does not mean the flaw was unknowable forever.

Immediate actions, detection, recovery

1. Preserve: retain mail logs from every cluster member, external firewall/network logs, configuration, version, and appliance access records. Root access may hide local evidence.^[14]
2. Patch: move to a fixed release; there is no workaround.^[14]
3. Hunt: review the vendor’s SQL-related log indicators and unexpected transfers or connections from the appliance; treat absence of one local indicator as insufficient.
4. Recover: Cisco recommends TAC engagement for suspected physical appliances and, for virtual appliances, secure restoration and renewal of credentials and cryptographic material as appropriate.^[14]

Detection and verification

Review mail_logs on every cluster member for Cisco’s SQL-related indicator, then cross-check firewall, proxy, DNS, and flow records outside the gateway for unexpected downloads, uploads, or management access.^[14] Cisco warns that root-level actors may remove local evidence, so a clean appliance log cannot close the case by itself.

Recovery and escalation

Suspected exploitation belongs with Cisco TAC and a qualified incident responder, not a routine “patch and watch” ticket. Preserve first, apply the fixed release, rebuild or restore securely as Cisco directs, renew exposed credentials and cryptographic material, and verify the mail path and connected identity systems before normal service resumes.

Why it matters to homes and small businesses

Most households do not own this gateway, but businesses may depend on one through an internal IT team or cloud provider. The device sits in the mail path and processes untrusted messages by design, so the practical question is whether the responsible provider can prove the exact fixed release and whether Cisco contacted it about possible compromise.

Confidence and unknowns: High on active exploitation and fixed versions; unknown on actor, campaign scale, and affected on-premises customer count.

File 8 — BlueMoon chains Chrome and Windows zero-days

What happened

Volexity says it observed UTA0560 and JungleBamboo independently using byte-for-byte identical exploit components on separate infrastructure against different targets beginning September 1. The chain combined Chrome V8 CVE-2026-85046, WebAssembly-related CVE-2026-87491, and Windows-kernel CVE-2026-85880.^[17] UTA0560 delivered GRIMWEDGE; JungleBamboo delivered a different loader and credential-stealing extension.^[17]

Zero-day and attribution precision

Volexity calls this a patch-gap zero-day: a fix for CVE-2026-85046 was visible in upstream Chromium source before it reached a released Chrome build. At the source-code level it was fixed; for Chrome users there was not yet a release carrying the fix during the observed operation.^[17] Volexity attributes both activity clusters to China-linked actors based on its intelligence. Identical exploit code suggests a shared supplier or broker, but does not prove the groups are one organization.^[17]

Who was exposed; observed in the wild

UTA0560 sent financial-themed spear-phishing to multiple NGO customers and abused a reflected-XSS weakness on a legitimate university site to redirect recipients. The chain filtered for Chrome on Windows; Volexity says the Windows privilege stage targeted older builds from Windows 10 1809 through 22H2, Windows Server 2022, and the initial Windows 11 release, rejecting builds above 22000.^[17] BleepingComputer, drawing on Volexity and Proofpoint, reported additional clusters targeting US aerospace and defense organizations and Vietnamese manufacturing, but those clusters should not be merged into UTA0560’s NGO victim set.^[18]

Immediate actions, detection, recovery

• Update Chrome and Windows fully, restart them, and verify the running versions. The practical lesson from a patch gap is speed after a release appears.
• Block and investigate validated campaign indicators from Volexity and Proofpoint; inspect memory, browser child-process behavior, unusual downloads, extension changes, and persistence when exposure is plausible.
• Preserve the phishing message, redirect chain, browser history, endpoint timeline, volatile memory where feasible, and network telemetry before wiping the host.
• For a confirmed compromise, isolate and rebuild the endpoint, rotate credentials and tokens used there, audit browser extensions, and inspect accessed services.

Detection and verification

Correlate the original email, legitimate-site redirect, browser version, Windows build, child-process and network behavior, downloaded files, persistence, and extension inventory. Volexity published cluster-specific indicators, but the decisive evidence is the local sequence around the click and the affected process tree.^[17]

Recovery and escalation

Escalate when the endpoint belongs to a journalist, NGO, defense, aerospace, manufacturing, or administrator role, or when browser and kernel exploitation is plausible. Preserve volatile and network evidence, isolate the host, update unaffected systems, rebuild the confirmed endpoint, revoke sessions and credentials used there, and investigate every service reached after the click.

Why it matters to homes and small businesses

The lure can pass through a legitimate but vulnerable website, so domain familiarity alone is not enough. Rapid browser and Windows updating, a full relaunch after installation, and endpoint monitoring matter more than asking a user to identify exploit code they cannot see. No reviewed source identifies a Treasure Coast target.

Confidence and unknowns: High on Volexity’s observed chains; vendor-research confidence for actor labels; unknown on exploit supplier identity, total victims, and wider adoption.

What homes and small businesses on the Treasure Coast should do

Do this tonight

1. Confirm Chrome, Edge, and Windows have installed current releases and have been restarted.
2. Check whether any Vite or marimo development service is reachable from the public internet; close exposure before investigating further.
3. Verify Cisco Secure Email Gateway and LiteSpeed Enterprise running versions against the fixed releases above.
4. Review browser extensions and recent installers on systems used for banking or sensitive messaging.
5. If compromise is plausible, isolate the system and preserve logs, messages, version data, cloud audit records, and the human timeline before cleanup.
6. From a clean device, revoke exposed sessions and credentials only after evidence preservation, then rebuild confirmed compromised hosts.

Do this this week

• Replace long-lived cloud keys on developer systems with short-lived, least-privilege identities.
• Document which provider patches each gateway, host, notebook, container, browser, and OS—and require version evidence.
• Baseline legitimate MQTT traffic and alert on new broker connections from servers that do not need it.
• Test a preserve-before-rebuild incident drill for one workstation and one cloud workload.
• Review high-risk employees’ personal-device support path and establish a trusted callback process.
• Verify backups and recovery procedures for website, email, cloud configuration, and endpoint data.

FAQ

Methodology and source note

The rendered Hacker News homepage was scanned for every genuine editorial item displaying September 15, 2026 in America/New_York. Eight qualifying items remained after excluding sponsored, vendor, webinar, and wrong-date cards. Each candidate article was opened for subject discovery; its structure and prose were not reused. Primary advisories and research were then fetched from Elastic, the NCSC/FBI/AIVD, Lumen, Sysdig, GitHub, F5, cPanel/LiteSpeed, Cisco/CISA, and Volexity. Independent reporting was used to corroborate publication and narrow facts without pretending repeated vendor claims were independent telemetry.

Exploit status is claim-specific: Cisco and marimo have confirmed in-the-wild evidence; Volexity observed the Chrome/Windows chain; F5 observed Vite scanning; cPanel did not claim the new LiteSpeed Enterprise flaw was exploited. “Could,” “assesses,” “observed,” “targeted,” “attempted,” and “unknown” remain attached to their evidence boundaries.

This defensive article omits live malware domains, payloads, exploit strings, and step-by-step offensive mechanics. It does not download or execute malware. The reporting cutoff is September 15, 2026, 7:57 PM EDT (September 15, 2026, 23:57 UTC).

AI-writer disclosure

This article was researched and drafted by Jennifer, an AI writer for The IT Guys, from the source artifacts listed below and subjected to claim-level and exact-byte review. Jennifer is not a human eyewitness, government official, vendor representative, or incident responder in any event described.

Sources

1. Elastic Security Labs — The extension you never installed: KREMLIN forges Chrome’s own integrity checks to steal banking sessions (September 14, 2026).
2. NCSC/FBI/AIVD — Iranian Cyber Targeting of Dissidents, Activists and Journalists (September 15, 2026).
3. FBI — Update on Government of Iran Cyber Actors’ Deployment of Telegram C2 to Push Malware to Identified Targets (September 15, 2026).
4. Computer Weekly — UK, US and Netherlands warn over Iranian state spyware campaign (September 15, 2026).
5. Lumen Black Lotus Labs — The banana stand: brokering and managing infections across Asia using MQTT (September 15, 2026).
6. BleepingComputer — BambooToken malware controls Windows and Linux systems via MQTT (September 15, 2026).
7. Sysdig — Machine speed, hold the AI: Hand-rolled marimo CVE-2026-39987 exploit (September 11, 2026).
8. GitHub Advisory Database — Marimo pre-auth remote code execution (published April 8, 2026; updated April 27, 2026).
9. F5 Labs — Cloud Takeover: Mass Scanning for Exposed Vite Endpoints (September 11, 2026).
10. Vite GitHub Advisory — server.fs.deny bypassed with queries (April 6, 2026).
11. BleepingComputer — Hackers target exposed Vite dev servers to steal AWS, Azure secrets (September 14, 2026).
12. cPanel — LiteSpeed Enterprise security advisory (September 14, 2026).
13. LiteSpeed — LiteSpeed Web Server v6.3.7 now available (September 11, 2026).
14. Cisco — Cisco Secure Email Gateway SQL Injection Vulnerability (September 14, 2026).
15. CISA — Adds CVE-2026-76461 to the KEV Catalog (September 14, 2026).
16. BleepingComputer — Cisco patches Secure Email Gateway zero-day exploited in attacks (September 15, 2026).
17. Volexity — Mind the (Patch) Gap: Multiple Chinese Threat Actors Chain 0-day Exploits in Chrome & Windows (September 9, 2026).
18. BleepingComputer — New “BlueMoon” kit exploited Windows and Chrome zero-day flaws (September 2026).
19. The Hacker News — KREMLIN Banking Malware… (candidate index, September 15, 2026).
20. The Hacker News — Iranian Hackers Use Telegram-Controlled Malware… (candidate index, September 15, 2026).
21. The Hacker News — BambooToken Malware Uses MQTT… (candidate index, September 15, 2026).
22. The Hacker News — Human Attacker Exploits Marimo RCE… (candidate index, September 15, 2026).
23. The Hacker News — Mass-Scanning Campaign Exploits Vite Flaw… (candidate index, September 15, 2026).
24. The Hacker News — LiteSpeed Enterprise Flaw… (candidate index, September 15, 2026).
25. The Hacker News — Cisco Secure Email Gateway Flaw… (candidate index, September 15, 2026).
26. The Hacker News — China-Linked Hackers Exploit Chrome-Windows Zero-Day Chain… (candidate index, September 15, 2026).

Prepared as Hacker Diaries Case File No. 025 for September 15, 2026. Text-and-image edition; no spoken edition or media player.