Kategorie

A malicious ChatGPT share link could run an attacker's code in the logged-in session of anyone who opened it, allowing them to read their private conversations, researchers at the security firm Parameter showed. The researchers reported the flaw through OpenAI's bug bounty program on October 18, and OpenAI fixed it eight days later and rated it P1, its most serious category.Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

Threat actors are launching about 8,226 network-layer distributed denial-of-service (DDoS) attacks per hour, Cloudflare revealed Thursday. The web infrastructure and security company said it autonomously mitigated 18.2 million network-layer (L3) DDoS attacks and 14.4 trillion HTTP DDoS requests in the third quarter of 2026. That amounts to 197,400 attacks per day, or one attack every 0.44 Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

An official extension for Anthropic’s Claude model was backdoored and threatened as many as 5,000 developers' machines, multiple sources reported Friday. Anthropic so far has yet to warn customers of the incident.

The compromised package was a VS Code extension available in the marketplace of Cursor, a maker of AI-assisted developer tools, the company said Friday. The malicious version, 2.1.313, subsequently affected “at most 5,000 users,” presumably when they either downloaded it or their systems automatically fetched and installed it. Anthropic pushed version 2.1.314 several hours after the previous version became available on Cursor, according to independent researcher Kevin Beaumont. Both Beaumont and the CTO and co-founder of security firm Phorian said that version 2.1.313 was distributed through Anthropic’s official account on Cursor. So far, neither Cursor nor Anthropic has explained how the attackers gained control of the account.

In search of cloud credentials

“It was a supply-chain compromise where the attacker gained access to the official distribution channel,” Phorian CTO and co-founder Luke Roberts told Ars. “The malicious version 2.1.313 was posted to the official Anthropic account, effectively superseding 2.1.312. Extensions auto-update in Cursor by default, but users can configure this in settings.” Phorian has more details here.

Read full article

Comments

Security researchers at Anthropic have developed an exploit for a critical Linux kernel vulnerability that allows unauthenticated attackers to remotely execute commands as root on servers running Multipath TCP (MPTCP) listeners. [...]

Chinese state-sponsored threat actors have been observed using a Go-based artificial intelligence (AI)-powered penetration testing framework called ARTEX in attacks aimed at high-value targets simultaneously. The activity has been attributed by CrowdStrike to a China-based "targeted intrusion adversary" it tracks under the moniker Vapor Panda (previously VexatiousTemper). First identified in Ravie Lakshmananhttp://www.blogger.com/profile/[email protected]

One of the great things about Apple device management solutions is that the market for them is growing. Another is that because no two enterprises are alike, there is scope to bring different offerings to the market. I spoke with Ben Greiner, co-founder and COO of Smplify, a new-to-market device management vendor, to find out what his company provides to IT.

Smplify, which just announced $1m in pre-seed funding, offers what could be described as a headless management tool: everything it does is available through the API and CLI. In use, that means you can build it and wield it from within the tools you already use, Greiner explained. 

He’s building the company with Preetham Gurram, known in device management circles for his work at MobileIron, SOTI, Automox, Addigy, Scalefusion, and Apple, where he contributed to Apple’s core MDM platforms and zero-touch enrollment at scale.

So, who needs this?

“Device management still assumes a person is watching,” said Greiner. “Admins already automate with scripts and pipelines, and now AI agents are showing up that can act on a fleet at machine speed.”

The challenge for IT is that AI is beginning to take actions, rather than suggest them. That means IT must put systems in place to manage and audit the actions AI takes. “Enterprises that win won’t be the ones with the smartest agents; they’ll be the ones that can say exactly what each agent is allowed to do and prove what it did,” he said.

That’s a fair assessment of how things stand. OneTrust’s 2026 AI-ready governance report found that 87% of organizations are encouraging the use of AI agents, but only 47% have clear governance and controls in place. That’s a problem waiting for a disaster.

A recent report from Gartner predicts that 40% of enterprises will demote or decommission autonomous AI agents in the coming months (“by 2027”) because of governance gaps detected only after incidents take place. Patching those gaps is expected to become a big business.

Who watches the watchmen?

Once agents can submit changes at lightning speed, who can approve them? How widely deployed can those changes be? The risk is “an agent with the right key can wipe thousands of laptops before anyone notices,” Greiner told me.

This is a matter of AI governance and is something I know is in the thoughts of leaders at other device management companies, including Jamf and Fleet.

“AI is happening whether organizations know it or not. That’s the problem. You can try to block it, but that’s very hard to do well. It’s far better to build visibility and governance around it,” Jamf CEO Beth Tschida told me earlier this year. Jamf launched its own AI Governance suite in July, focused on AI tool discovery, policy enforcement, and reporting.

The Smplify approach puts some of these decisions into the management workflow itself. “Preetham calls it the last-mile control plane: the final checkpoint between what an agent decides and what actually happens on a device,” Greiner said.

What are the risks of unmanaged AI? 

While most of the conversation is focused on the risk of data leakage or malware, the other risk is lack of accountability. What if an agent gets bad instructions or hallucinates an inappropriate solution to a problem, and then pushes a destructive change across the fleet? By then it’s too late to figure out why it happened and becomes a potentially costly damage limitation exercise.

Fleet CEO Mike McNeil pointed out that part of the risk lies in the difficulty and cost of recovery after an incident. “I’d frame risk by two things: how much privilege the code runs with and how hard recovery is,” he said, noting the risk of scripts running at root, which can take full control of the machine to the extent that reversion can’t undo what’s done.

Greiner thinks the way to minimize the impact of such damage is to create strong rules and boundaries, and to ensure any risky actions are held back pending human approval. The agent can see a problem and create a solution, but can’t apply that fix until IT gives it the go-ahead. It’s very like how human IT works, only now it’s the machine that must report to the boss. Every change is logged with who asked for it, the intent behind it, and the person or policy that approved it.

Creating the opportunity space

Smplify has built its own platform to help manage devices, including AI management. That platform leans into the native protocols of the platforms it supports, naturally including Apple’s Declarative Device Management (DDM). 

“Admins describe what should be true of their devices, and Smplify keeps it true. If a device drifts from that intent, because a setting changed or an update was missed, the platform notices and brings it back in line, automatically or with an admin’s approval, depending on the rules they’ve set,” Greiner said.

He explained how many IT teams use GitOps to “bring discipline” to device management: configuration lives in GitHub, changes go through pull requests, and there’s a history of what happened. It works, but it adds new layers to the management task. He claims his solution has that discipline (versioned intent, review, and approval, and a full history) built in.

Boundaries, Apple and DDM

In the end, I get the feeling that AI management will embrace some of the ideas put in place with Apple DDM. If you think about it, DDM lets IT define a state and leaves it to the tech to work within that definition, and that same sense of boundary setting may be part of the future for AI in IT. AI will be given agency within limited boundaries.

Greiner pointed out, “Apple has also been giving admins controls over Apple Intelligence features, and I expect that to keep expanding as businesses want a say in which AI runs on company devices. Apple’s privacy stance also suits governed AI well: do things on-device where possible and keep a clear line around what leaves it.”

There is one more thing. Because Smplify is an MDM platform while also being API-first, Greiner explained that software companies can offer native device management inside their own products, under their own name, using his company’s solution. 

Now please subscribe to my daily, human-curated Apple-related news headline feed at The Core, or follow me on BlueSky, LinkedIn, or Mastodon.

Hardware wallet device maker Trezor has received credible reports about a suspected hardware crypto-theft implant in a Trezor Safe 5 sold by its reseller CryptoBilis in Southeast Asia. [...]

TeamViewer has fixed a flaw that lets the machine being controlled in a remote session attack the computer that connected to control it. In a TeamViewer session, the computer that connects and takes control is the viewer, and the machine it controls is the host. A malicious or compromised host can exploit the flaw to crash the viewer's TeamViewer and, depending on the platform, may also run Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

A malicious version of Anthropic's Claude Code VS Code extension was distributed through Cursor's extension marketplace for approximately 11 hours on October 29, exposing up to 5,000 developers to malware designed to install persistent SSH backdoors. [...]

Threat actors have been observed attempting to exploit a high-severity security flaw in WordPress Core shortly after patches were released. The vulnerability, which does not have a CVE identifier, relates to a case of remote code execution impacting WordPress Core versions 4.7 through 7.1.3. It carries a CVSS score of 8.1 on the CVSS scoring system. Patches for the flaw were released on OctoberRavie Lakshmananhttp://www.blogger.com/profile/[email protected]

Flaws in SS7 and Diameter signaling protocols can allow attackers to track phone locations, intercept calls and SMS verification codes, and impersonate subscribers without compromising their devices. Cape explains how these attacks exploit trust between networks and how its security-focused mobile service helps defend against them. [...]

Attackers have started exploiting a maximum-severity GitLab vulnerability patched earlier this month, according to the US Cybersecurity and Infrastructure Security Agency (CISA). [...]

A Trezor Safe 5 hardware wallet bought from the reseller CryptoBilis has an extra circuit board that sends out the recovery phrase over a mobile network, a customer has reported. Trezor has not yet examined the device. It is telling everyone who bought a Trezor from CryptoBilis since March 2026 to move their funds to a new wallet with a new recovery phrase. Trezor said in a blog post&nbspRavie Lakshmananhttp://www.blogger.com/profile/[email protected]

The alert is critical. The fix is known. And the ticket sits in a queue for days. Security teams understand the risk, but the people who keep applications available need proof that the change won’t break anything.  Their concerns are practical. An IPS protection could block legitimate traffic. A configuration change could interrupt a service. An endpoint policy could affect an application [email protected]

Microsoft has resolved Always On VPN connection failures triggered after installing the September 2026 Windows 11 security updates. [...]

We talk to chatbots as if those conversations are private. But are they?

Most people are confused. A survey commissioned by DuckDuckGo and published in August asked 1,944 American adults about chatbot privacy, and more than half (53%) did not know whether their conversations were being used to train the bots. (They are.)

Only a quarter of respondents knew that chatbot conversations can be subpoenaed. (They can.)

Among self-described AI enthusiasts, 56% said they had confided to a chatbot something they had never told a close friend, parent, colleague, doctor, or therapist.

That’s especially true on Character.AI, a chatbot service where users can chat and form “relationships” with customizable characters, including ones they create and share with the community. On Character.AI, some users chat about thoughts of suicide and self-harm, and they surrender private details like mental health disclosures, ages, private chats and voice calls, deep fears, and relationship struggles.

Character.AI was all fun and games until earlier this month, when the company filed for bankruptcy and opened a court-supervised sale of its assets.

Nobody knows who will end up with the company, or how much of the data on its millions of account holders will be sold as well.

The most valuable asset for sale by the company may be its LLM, which has been substantially trained by users as they build and interact with characters.

Legally, a company can sell personal data about its users if its privacy policy permits the transfer. Character.AI’s privacy policy is spectacularly vague. It says the company may disclose “certain information” in the company’s sale. Nobody knows what that means.

The US Trustee Office, an arm of the Justice Department, wants the judge to appoint a consumer privacy ombudsman to advise the court on user privacy. The judge could restrict the sale of company “records,” including user data.

But here’s the part most people don’t understand: The Bankruptcy Code has no provision specifically addressing trained models. The legal status of LLMs and their training data has yet to be settled in law. That means it’s entirely possible that the data users fed into Character.AI will be sold to whoever buys it.

Character.AI is just one handy example. The larger risk is all the other AI companies out there.

More surprising facts about LLM privacy

The core question is this: Can personal or proprietary information shared in a chat end up inside an LLM, where anyone might coax it out?

The answer is a resounding “uh, maybe.”

First of all, it depends on the AI chatbot service. The companies vary wildly in how they handle chat data, and the differences boil down to four questions: whether training on chats is on by default, whether human reviewers read them, how long they are kept, and whether they feed advertising.

Major chatbot companies generally try to reassure users about privacy. They publish privacy controls, but their own policies admit that consumer chats may be used for training by default, read by human reviewers, or both, and the fine print shifts from company to company.

Tellingly, some of them offer enterprise or business accounts that handle chat sessions privately. For example, they don’t use chat sessions in training data. That business accounts get extra privacy features sounds to me like an admission that individual accounts aren’t private.

Some companies, such as OpenAI, let users opt out of having their chats tossed into the training data. But OpenAI’s help documentation says that turning off training does not delete the chats themselves.

There are three main ways chatbot user data can be exposed. The first is bugs. In March 2023, a bug lurking in an open-source library called “redis-py” let some ChatGPT users see other users’ chat titles and, possibly, the first message of new conversations. More than 1% of ChatGPT Plus subscribers active in a nine-hour window may have had their payment details exposed to other users: names, email addresses, payment addresses, card types, the last four digits of card numbers and expiration dates.

The second is sharing. Some chatbots offer sharing features, and those features can publish chats to the world, whether on purpose or by accident. Once these sessions are posted, search engines are likely to gobble them up and make them searchable. In 2025, Forbes reported that Google’s results showed more than 370,000 Grok conversations after users clicked “share,” and shared ChatGPT chats turned up in search results until OpenAI killed the option.

The third is the absorption of chat sessions into the training data.

Let’s take one simple example: an email address. People often paste in emails so that a chatbot will write the reply. These emails often contain names, email addresses and other information in the header, the signature, or both.

The question I often ponder is this: If emails addressed to one person get pasted into chats hundreds of times, can a stranger ask the chatbot for that person’s address and actually get it back?

In a 2022 study, GPT-Neo models given only a person’s name recovered the right email address no more than 1.24% of the time, but with the domain supplied, the rate climbed to 16.55%, and to 37.06% after five examples. Other factors, including how often an address appeared in the training data and whether surrounding email text came along with it, pushed the rate higher.

Deleting chat records isn’t a remedy, either. Several state attorneys general said deleting chat records may not undo their influence on trained models. And Common Sense Media’s Robbie Torney claimed that exporting or deleting your data “may not mean that that data is gone from model training.”

Note that people not only enter personal information about themselves during AI chats, but about their co-workers, friends, and relatives.

The main thing standing between your secrets and the world is company practice. We depend on the AI companies to keep our information private.

So what happens when those companies sell their assets?

When AI bubbles burst

Online chatter about the “AI bubble” bursting is pretty much constant.

In China, the AI bubble has already burst, according to Reuters. Over the past few months, Chinese AI stocks have been pummeled.

Reuters reported that Shanghai’s STAR50 index of tech stocks fell 40% from its July high in under four months, erasing about $480 billion in market value, and that the broader CSI300 is down about 20% from its June highs.

It’s not a total collapse, but it does put pressure on US stock prices and also provides an incentive to transfer ownership through sales or mergers (though this hasn’t happened in China yet).

Still, the future is unknowable. Which AI companies will go bust as Character.AI did, get sold off, or get hacked?

As for the chatbots themselves, their inner workings are also unknowable.

That’s why we should all listen to the most paranoid amongst us, and never put sensitive information into chatbots. We just can’t trust AI to keep our secrets.

Ahmad Umar Agha, a Syrian Electronic Army hacker known online as "Th3Pr0," has been sentenced by a U.S. federal court to 42 months in prison for his role in a hacking conspiracy that targeted Western news outlets. The conspiracy was organized and led by members of former Syrian President Bashar al-Assad's inner circle, including the commander of Syria's General Intelligence Swati Khandelwalhttp://www.blogger.com/profile/[email protected]

Drupal warned admins to patch a critical access bypass vulnerability in the Commerce Core module that attackers are exploiting in the wild. [...]

A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:

• Review the logs
• Identify the source of the activity
• Define filtering boundaries
• Choose filtering criteria
• Write a rule
• Check that the filter is robust

This post looks at how filter creation itself can be automated to reduce analyst workload.

Filter validity criteria

In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.

Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.

Problems in filter generation

We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.

Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.

Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:

• In the filter, use fields other than the file path.
• Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.

Filtering security alerts with an algorithm

Given the problems described above, automatically generating filters for security alerts should consist of the following steps:

1. An analyst receives a security alert that they assess as a false positive and uses the filter generator.
2. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
3. The generator selects the fields that are relevant to the filter.
4. The generator normalizes the strings.
5. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
6. The generator ranks the resulting combinations and offers the analyst the top three to choose from.

For example, consider an event described by the following JSON:

After generating and ranking the combinations, we got three filters based on file paths:

• processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")
• file_path:"*****/.pi\\agent\\bin\\fd.exe"
• processcmdline: "programfiles\\nodejs\\node.exe"

The last filter turned out to be too broad, but the analyst marked the other two as valid.

Pros and cons of the algorithmic approach

The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.

However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.

These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.

Filter generation with an LLM

The LLM-based filter generation looks like this:

The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.

Consider the following event in JSON format:

The LLM suggested three filter options that all contain the same command line fragment:

• file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"
• filecmdline: "Get-VM -Name kafka\*"
• filecmdline: "kafka*"

As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:

file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

Pros and cons of generating filters with an LLM

Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.

Using multiple AI agents

To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:

• Selector: selects the relevant fields.
• Generator: generates filters.
• Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
• Commentator: analyzes the output filters and explains which field values were used and why.

For the following JSON event, the agents produce three valid filters based on the file path.

The filters differ in the additional parameters that support the detection:

• file_path:"sysvol\\domain\\scripts\\logon.bat"
• file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"
• autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"

Pros and cons of the agent-based approach

LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.

Evaluating the filter generation system

To evaluate how well the filter generation system works, we use two main metrics:

• Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
  
• False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.

Below is a comparison of the three filter generation approaches by these metrics:

As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.

Takeaways

Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.

The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.

Binance, the world's largest crypto exchange, has linked the theft of about $6.3 billion in cryptocurrency to a DevOps engineer's compromised laptop. [...]