Daily Cybersecurity News – August 15, 2026

What happened

Jamf Threat Labs identified a new multi-stage Rust-based macOS infostealer called AmnesiaStealer being distributed via ClickFix social engineering lures that impersonate a GitHub download page.

Victims are tricked into pasting a base64-decoded command into Terminal that silently fetches and runs a self-deleting dropper script. The payload harvests credentials from Apple Notes, Telegram, keychains, and browsers while muting system sound for stealth. A second-stage module then grants operators remote interactive control over cloned Chromium-family browser profiles (Chrome, Brave, Edge, Arc, Opera, Vivaldi, Chromium) to steal live authenticated sessions and cookies without visible prompts.

Who is affected

macOS users who fall for ClickFix lures, particularly those visiting counterfeit download pages. The malware includes OS version-branched logic targeting various macOS releases and has been observed in the wild alongside overlapping tactics from families like Atomic (AMOS) and MacSync.

Why it matters

Browser session hijacking enables immediate account takeover and lateral movement without needing to crack passwords later. Stealth features such as TCC prompt avoidance, sound muting, and ad-hoc signing make detection harder on endpoints that rely on user-initiated actions or signature-based tools.

Operators gain persistent live access to authenticated sessions, amplifying the value of stolen data far beyond static credential dumps.

How it could have been prevented

Train users never to copy-paste Terminal commands from web pages or error messages, even if framed as convenient installs. Enforce application allow-listing, monitor for unexpected osascript/Finder activity and base64-decoded curl|bash patterns, and deploy EDR with behavioral detections for keychain access and browser profile cloning.

Keep macOS updated, restrict Terminal usage where possible via MDM, and treat any unexplained password prompts as suspicious.

What happened

Threat actors began exploiting an unpatched SQL injection vulnerability in GeoServer’s jsonArrayContains filter function within hours of its public disclosure by researcher q1uf3ng.

The flaw improperly sanitizes user-supplied arguments when querying JSON array fields with PostGIS (and Oracle JDBC) data stores, enabling unauthenticated SQL injection that can escalate to remote code execution under certain database configurations. WatchTowr observed hundreds of exploitation attempts from a small set of IPs shortly after disclosure; GeoServer maintainers later released fixes in versions 3.0.1, 2.28.5 and 2.27.6 (advisory GHSA-mqjf-5f49-2fjh, CVSS 9.8).

Who is affected

Organizations running internet-facing or exposed GeoServer instances that use the vulnerable jsonArrayContains functionality with PostGIS 12+ or compatible data stores. GeoServer is widely deployed for sharing geospatial data across government, agriculture, telecom, transit and other sectors.

Why it matters

GeoServer has a history of rapid large-scale exploitation once flaws become public, with prior issues landing in CISA’s KEV catalog. Successful RCE on geospatial servers can expose sensitive mapping, infrastructure or operational data and provide a foothold into connected enterprise networks.

The speed of weaponization underscores how quickly unauthenticated web flaws in popular open-source platforms become scanning and attack targets.

How it could have been prevented

Immediately upgrade GeoServer to 3.0.1, 2.28.5, 2.27.6 or later patched releases. Identify and inventory all GeoServer instances, restrict public internet access via firewall or reverse-proxy controls, and monitor logs for anomalous OGC filter queries or unexpected database activity.

Apply network segmentation around geospatial services and track the official GeoTools/GeoServer advisories for any additional mitigations.

What happened

The Netherlands’ National Cyber Security Centre (NCSC) warned that attackers are actively exploiting CVE-2026-65400, a critical authentication bypass in macOS Screen Sharing (VNC over TCP 5900), after public exploit code appeared.

Apple addressed the issue (CVSS 9.8) on August 6 in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9 by improving state management so network attackers can no longer authenticate without valid credentials. In observed attacks against systems with port 5900 exposed, adversaries obtained root access and deployed Monero cryptocurrency miners.

Who is affected

macOS systems (Tahoe, Sequoia, Sonoma and earlier unpatched releases) that have Screen Sharing enabled and port 5900 reachable from the internet or untrusted networks. Any organization or individual leaving remote desktop services open is exposed.

Why it matters

Pre-authentication access to Screen Sharing grants full remote desktop control, allowing attackers to run applications, access files, alter security settings and install persistent payloads such as miners that consume CPU and electricity.

Even after the initial access, root-level compromise makes cleanup difficult and opens the door to further data theft or ransomware. Public PoCs accelerate opportunistic scanning of exposed Macs.

How it could have been prevented

Update immediately to macOS Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9. If patching is delayed, disable Screen Sharing entirely via System Settings > General > Sharing unless it is absolutely required.

Block inbound TCP 5900 at the firewall or network edge, require VPN for any remote access, and monitor for unexpected VNC connections or high CPU processes indicative of mining.

What happened

Kaspersky GReAT researchers discovered an upgraded variant of the CoolClient backdoor used by the HoneyMyte APT group (also known as Mustang Panda). The new version deploys a signed kernel-mode rootkit driver that hides malicious processes, files, registry objects and network connections from security tools and analysts.

In observed campaigns the actors first deploy PlugX, then use DLL sideloading of a legitimate Sangfor binary renamed as defender.exe, establish persistence via scheduled tasks and services, inject into synchost.exe, and load the rootkit that communicates with user-mode components via IOCTL. Victims include organizations and government entities in Myanmar, Mongolia, Pakistan, India and Russia.

Who is affected

Primarily government and organizational targets in Asia and Russia that have been compromised by HoneyMyte/Mustang Panda. Windows systems reachable by the group’s initial access vectors (often PlugX) are at risk of the upgraded CoolClient payload.

Why it matters

Kernel-level rootkits dramatically increase stealth and persistence, allowing the backdoor to evade many EDR and forensic tools while maintaining full remote control, keylogging, credential theft and plugin extensibility.

The signed driver and living-off-the-land techniques (sideloading, service installation) make detection and remediation far harder, extending the dwell time of a well-resourced APT focused on espionage.

How it could have been prevented

Hunt for known CoolClient/HoneyMyte indicators including anomalous Sangfor binary usage, synchost.exe injection, unexpected Windows services or scheduled tasks mimicking Defender, and kernel driver loads. Enforce application control and block known sideloading paths.

Maintain robust EDR with kernel-level visibility, monitor for PlugX as a precursor, rotate credentials after any suspected compromise, and apply least-privilege and network segmentation to limit lateral movement.

What happened

SOCRadar analysis of the TeamPCP supply-chain campaign showed that more than 95% of the roughly 2,500 organizations previously linked to the malicious LiteLLM PyPI packages were actually first exposed by the earlier compromise of Aqua Security’s Trivy scanner.

TeamPCP poisoned Trivy releases and Docker images starting around March 19; the worm-like malware harvested credentials, tokens and secrets from CI/CD environments and used them to push further malicious packages, including two short-lived LiteLLM versions on March 24 that contained a .pth file executed on Python startup. Data collection timestamps for 2,085 of 2,188 examined organizations ended before the LiteLLM packages appeared.

Who is affected

Organizations that ran compromised Trivy versions or images (or downstream packages influenced by the worm) in CI/CD pipelines across GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI and Buildkite. Impact spanned multiple countries, with high secret exposure including JWTs, AWS keys, API tokens and private keys; headline figures cite 2,500+ organizations and hundreds of thousands of pipelines.

Why it matters

Compromising a widely used security scanner turns a trusted defensive tool into an attack vector that automatically executes in build environments rich with secrets. The cascading worm behavior and credential reuse rapidly expanded the blast radius far beyond any single package.

Stolen secrets are already being brokered, creating long-term risk of secondary breaches even after the original malicious packages were removed.

How it could have been prevented

Immediately audit and rotate all secrets, tokens, API keys and credentials that could have been present in CI/CD environments during the March 19–24 window, especially those used with Trivy or LiteLLM. Pin and verify package hashes, enable dependency review and artifact signing, and restrict CI/CD token scopes to least privilege.

Scan historical build logs for anomalous network callbacks or .pth file drops, rebuild clean environments from known-good sources, and treat any project that consumed the affected Trivy releases as potentially fully compromised.

What happened

UK CRM provider Beacon disclosed that attackers downloaded customer database backups after obtaining a compromised AWS access key that was likely exposed in publicly available JavaScript build artifacts.

Malicious activity began on or around July 27–28; Beacon assessed that the threat actor exported essentially all data stored in the system. The data was encrypted at rest but attackers may have decrypted it. Multiple affected charities confirmed the incident impacts Beacon’s entire customer base of more than 1,000 organizations. No financial payment card or bank details were stored, but personal supporter information was exposed.

Who is affected

More than 1,000 charities and non-profits that use Beacon’s CRM platform to manage donors, supporters, volunteers and fundraising. Personal data such as names, phone numbers, email addresses and postal addresses of supporters may have been compromised. The UK Charity Commission is monitoring the situation.

Why it matters

Charities hold large volumes of supporter PII that can be abused for phishing, identity fraud or further social-engineering attacks. A single exposed cloud key granted bulk access to every customer’s data, illustrating how one credential leak in a SaaS provider can cascade across an entire vertical.

Even without payment data, the reputational and regulatory impact on non-profits is significant, and the data may surface later on criminal markets.

How it could have been prevented

Never embed long-lived AWS access keys (or any cloud credentials) in client-side JavaScript or publicly reachable build artifacts; use temporary credentials, IAM roles and secrets managers instead. Regularly scan public repositories and build outputs for accidental secret exposure and enforce automated secret scanning in CI.

Apply least-privilege IAM policies, enable CloudTrail logging and anomaly detection on data-export activity, rotate keys immediately upon any suspicion of exposure, and require multi-factor authentication plus network restrictions for administrative access.

What happened

A free new service called DecryptAds (decryptads.com) has launched that scrapes and correlates publicly available ad-tech disclosure files to map who is authorized to run ads or collect data on websites and mobile/TV apps.

It aggregates ads.txt, app-ads.txt, buyers.json and sellers.json, cross-references them, and surfaces details such as the number of ad partners, registered data brokers, collection of geolocation or device fingerprints, and “geo-risk” partners based in higher-risk countries. The tool is aimed at privacy researchers, security teams hunting malvertising, and anyone wanting transparency into the advertising supply chain.

Who is affected

Anyone who visits websites or uses apps that participate in programmatic advertising; security and privacy professionals investigating ad supply chains, malicious ads or data-broker exposure; publishers and advertisers seeking visibility into their own declared partners.

Why it matters

Ad-tech ecosystems are opaque and frequently abused for malvertising, data harvesting and fraud. Individual disclosure files are hard to interpret in isolation; DecryptAds makes the relationships and risk signals immediately usable for threat hunting, privacy audits and identifying unexpected or high-risk trackers.

It also highlights the growing regulatory pressure (state data-broker registration laws) that is forcing more of this information into the open.