12 posts tagged with "Research"

Open a public Experience Cloud page, a help centre or an application form, and watch the network tab. The page talks to Salesforce through one endpoint, /s/sfsites/aura, as the site's guest user. Nothing about that endpoint knows whether the request came from the site's own components or from a script. Whatever the guest user is allowed to read, anyone on the internet can read.

That is not a theory. In 2023 an independent researcher found hundreds of public Salesforce sites exposing records such as Social Security and bank account numbers to anonymous visitors. In March 2026 Salesforce warned customers that threat actors were mass-scanning public sites through that endpoint and extracting data, and said the cause was customer guest user configuration, not a platform flaw. This post walks the path a leak takes, hop by hop, and where each hop can be closed.

A security scan of a mature Salesforce org rarely comes back short. Hundreds of findings is normal: permissions that are broader than they need to be, Apex that runs without sharing, a session setting nobody has looked at since the org was created. Every one of them is technically true. Almost none of them tells you what to do on Monday morning.

The question a security team actually has is narrower: which of these lets someone reach data they should not?

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.

"Paste the repo into the model and ask it to find the security bugs" has become a common first attempt at AI-assisted security review. It is easy to try, and the first run is often impressive: the model names a plausible injection, explains it well, and suggests a fix.

The trouble starts on the second run. And the third. And when somebody asks what it did not look at.

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.

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.

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.

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.

Supply-chain security is usually sold as a list problem: keep an inventory of your packages, match it against a vulnerability feed, patch what turns up. That works for the bug a maintainer shipped by accident. It did very little for the attacks of 2025, because in almost every one the malicious version was installed and running before any feed knew it existed.

The 2025 compromises were not vulnerabilities. They were programs. Each one read a credential, called a network endpoint, ran a shell command or republished itself, and each of those is a shape you can read in code without waiting for anyone to publish an advisory.

Most of the attacks that made the news in 2025 did not need anything clever. A package version that should not have been installed. An install script that read a token and sent it somewhere. An API that returned whichever record you asked for. A prompt template that read a field anyone on the internet could write. Each one ended in a headline, and each one started as a line of code or configuration that a check could have pointed at.

This post goes through twelve of them, from late 2024 to early 2026. For each: what happened, as the public source describes it, the weakness underneath, and the Vulkro check that flags that weakness. Every check id below is in the shipped catalogue, and the core of each mapping was run against a small reproduction of the weakness before it was written down.

For most of the last decade, a security scanner was something a software team adopted when it had the time, the budget or a nervous customer. Testing was good practice. Writing down the results was better practice. Neither was something a regulator, a court or a board could reliably hold you to.

That has changed, and 2026 is the year it became hard to ignore. Six EU laws now reach software teams, from the GDPR baseline to the new Cyber Resilience Act, and read side by side they share one demand: not that you are secure, which no law can define, but that you can show, at any moment, what you tested, what you found and what you did about 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.

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.