20 posts tagged with "Research"

Between late 2024 and the summer of 2026, attackers took customer records out of a long list of Salesforce orgs. The coverage made it sound like one breach of one platform. It was not. Salesforce said, case after case, that no vulnerability in its platform was involved, and the FBI's alert on the two main groups describes social engineering and stolen tokens, not an exploit.

What the attackers used instead was trust the orgs had already granted: to an employee, to an integration, or to the anonymous visitor of a public site. Read as a findings list, each org involved probably looked unremarkable. Read as attack paths, the same three shapes repeat. The FBI's September 2025 alert describes both 2025 campaigns in those terms: voice phishing that got a malicious connected app authorised, and OAuth tokens stolen from a third-party integration.

A supervisor reviewing a bank, an insurer or a large utility will eventually ask four questions about the systems that hold its customer data. Who can export every customer record? Which third parties hold a token into it? What changed in it last quarter, and who approved the change? When was it last tested, and what did the test find?

For a growing share of European companies, the honest answer starts with "it is in Salesforce". That does not move the question to Salesforce. The provider runs the platform; the profiles, permission sets, connected apps, installed packages and Apex inside your org are yours. NIS2 and DORA both make that explicit, and both expect you to show your work.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

Most Salesforce security reviews start with people: who is an administrator, who has MFA, who logged in from where. The data thefts of 2025 and 2026 mostly did not go through people's logins. They went through OAuth tokens, held by connected apps, acting as users who were never asked again.

The FBI's September 2025 alert explains why that matters: "Authorizing a malicious connected app bypasses many traditional defenses such as MFA, password resets and login monitoring, and because OAuth tokens are issued by Salesforce itself, activity coming from the malicious app can look like it's from a trusted integration." This post is about that surface: what a connected app is allowed to do, which settings decide how far a stolen token reaches, and how to review them.

Salesforce data theft did not stop when 2025 ended. In the first half of 2026 there was a mass scan of public Experience Cloud sites in March, a run of extortion claims through the spring, and in June another third-party integration whose OAuth tokens were used against customer orgs.

The pattern from last year held. In each case where Salesforce made a statement, it said its platform had not been breached. What attackers used was configuration that customers own: what an anonymous site visitor may read, what an employee account can reach, and what an integration's token is allowed to do.

This post sticks to what has been confirmed by Salesforce, by the affected companies or by a regulator, and says so when a claim comes only from the attackers. Then it lists what to check in your own org.

The org your last security review described no longer exists. Since then an administrator granted a permission set "for the migration" and never took it back. A connected app was approved so a vendor could run a trial. A session timeout was relaxed because an integration kept dropping. The guest profile was edited the week a new Experience Cloud page launched. Each change was reasonable on the day. None of it is in your repository, and none of it was reviewed.

That is configuration drift, and in Salesforce it is the normal state of things. The platform is designed to be changed in Setup, by people who are not developers, without a deploy.

A Salesforce security audit for a client is skilled work done with weak tools. The consultant knows what to look for: who holds Modify All Data, which classes a guest user can call, which connected app still has a refresh token from a vendor that left two years ago. But the method often lives in a spreadsheet and in the memory of whoever ran the last engagement. Two consultants auditing two orgs check different things, and the client cannot compare this year's report with last year's.

A repeatable method fixes that. The same scope, the same access, the same checks in the same order, and a report the client can hold you to. This post sets out the method we see work for Salesforce partners and consultancies, and where Vulkro for Salesforce fits into each step.

An advisory lands for a library inside a product you sell. By lunchtime there are reports that it is being exploited. Until this autumn, the next question was a business one: how fast do we patch? Since 11 September 2026, if that product is sold in the EU, there is a legal one first. The Cyber Resilience Act gives the manufacturer 24 hours from becoming aware of an actively exploited vulnerability to send an early warning to its national CSIRT and to ENISA, 72 hours to send the full notification, and a fixed window for the final report.

The report itself is short. Answering it is not, unless you already know what is in every version you ship and whether the vulnerable code can be reached. This post covers what the regulation asks of software teams, which dates matter, and what evidence to have on disk before you need it.

This is a plain-language summary of EU law for software teams, not legal advice: check the official text and your counsel before you rely on it.

An MCP server is a program your AI assistant starts on your machine, with your environment, your files and whatever tokens you put in its config. It is installed by name, often re-downloaded on every launch, and its tool descriptions are read by a model that does what text tells it to. In most teams nobody reviewed any of that. It was one line in a JSON file, pasted from a README.

In 2025 attackers noticed. Each of the incidents below is public, each one is small, and together they describe the whole surface: the package, the transport, the tool and the agent's own reach.