Applicant Data Is the Softest Target You Own

On 23 September the FBI published a statement about its recruiting website that I think every small-business owner should read twice. A criminal group had claimed it broke into FBIJobs.gov and took data on agents and on people who had applied to work there. The bureau did not confirm the claim. What it said, as quoted by Cybersecurity Dive, was this:

“While the point of breach is still undetermined — whether a third-party or the FBI’s enterprise — we are actively and aggressively investigating this matter and working closely with those third-party providers that support FBIJobs.gov to mitigate any and all risk.”

That is the Federal Bureau of Investigation, with its own cyber division, two days into an incident, unable to say whose system failed. Six days after the claim, the applicant portals were still offline.

I’m not piling on the FBI here. It is simply the most honest description I have seen of where most employers actually stand with their hiring stack. A careers page from one vendor. Applicant tracking from another. Background checks through a third, payroll and benefits somewhere else, and a folder of résumés in somebody’s inbox. If one of those leaks tomorrow, how long would it take you to work out which one, and who was in it?

We wrote the employee-side guide on Saturday, for the people whose data is in the file. This one is for the people who hold the file.

Seven questions to answer about your applicant data this week

None of these needs a consultant. Most of them need a login and about twenty minutes.

1. Which systems hold applicant data? List them all, including the unglamorous ones: the careers inbox, the shared drive where hiring managers save résumés, the background-check portal, the spreadsheet somebody built in 2021. The FTC’s first rule for businesses is “Take stock”, and it comes first for a reason.
2. Who owns each one? A named person with a login. In a lot of small companies HR bought the applicant tracking system, IT never touched it, and the admin password belongs to someone who left.
3. How far back does it go? Open the oldest candidate record you can find. If it predates anyone’s memory of the role, you are storing risk you get nothing for.
4. Is any of it self-hosted? If you or a provider run hiring or HR software on your own servers, find out what version it is and when it was last patched. That is where this particular campaign got in.
5. What does each vendor contract say about breach notice? How fast they have to tell you, what they have to tell you, and whether they keep logs long enough to answer the question “was this person in it?”
6. Who can export everything? Count the accounts that can download the full candidate database in one go. Turn on phishing-resistant sign-in for those first.
7. Who would you call? Write down the vendor’s security contact, your insurer’s claims line and your breach counsel, if you have one, on paper, somewhere you can find it when email isn’t trustworthy.

What happened at the FBI, sorted by who is saying it

Breach coverage tends to blur three different kinds of statement together, so it is worth pulling them apart.

What the FBI has said. On 22 September it told TechCrunch it was “aware of claims regarding unauthorized activity affecting FBIjobs.gov and is currently investigating,” and at the time the jobs site read “currently down for maintenance”, with the special agent applicant portal offline as well. The longer statement on the 23rd added the line about third-party providers. For the first week, that was the whole of the confirmed record.

What has changed since. On Tuesday 29 September the FBI and the Dutch National Police arrested a suspected member of the group, CBS News reported; FBI Director Kash Patel described the person as “one of the alleged leaders.” The bureau now refers to “the cyber incident involving FBIJobs.gov” and says it is “in regular communication with anyone who may be impacted — including multiple Bureau wide communications within 24 hours of public reporting.” CBS also relays a New York Times report that an internal FBI email acknowledged that personal information of some employees had been stolen. The group, for its part, now says it “would never publish this data”, which I would not plan around. What still has not been said publicly is where the breach happened, or how many applicants are in it.

What the group says. ShinyHunters, the extortion crew behind the Canvas attack in May, told TechCrunch it was “very confident we have data on mostly all of FBI” and that “a substantial amount of applicants data [is] involved as well.” According to the reporting TechCrunch relayed, the way in was an Oracle PeopleSoft server used for HR and recruitment, followed by a pivot into an Amazon-hosted government cloud. Help Net Security lists further systems the group says it reached, including background-check and medical-records applications. All of that is the group’s account.

What is uncertain even to specialists. Cybersecurity Dive noted that it is unclear whether the PeopleSoft flaw the group used was a brand-new one or the one Oracle disclosed in June, CVE-2026-35273. The group’s stated motive is not money at all: it wants the FBI to retract parts of a May advisory describing how it pressures victims.

The part of this that transfers to a 40-person company has nothing to do with the FBI being the FBI. The target was the hiring side. The system was a widely used HR product. And the owner of the data could not say, on day two, whether the failure was theirs or a supplier’s.

Figure 01 · From a June patch to a September breach claim ScamDrill

Dates per Mandiant (11 June and 25 September 2026), The Hacker News (June 2026), TechCrunch and Cybersecurity Dive (22–23 September), Help Net Security (28 September) and CBS News (29 September). Amber marks the attacker’s move, red a loss, blue the fix.

One character past the firewall

The technical story behind the campaign is short enough to explain to a non-technical owner, and it carries the most useful lesson in the whole episode.

In late May, ShinyHunters started exploiting a flaw in PeopleSoft’s Environment Management Hub, a component with the unlovely internal name PSEMHUB. According to The Hacker News’ June report, the zero-day window ran from 27 May to 9 June, the flaw scored 9.8 out of 10, and it needed no login and no user interaction. More than 100 organisations were notified, 68% of them in higher education, figures that match Mandiant’s own June write-up. Oracle published a security alert on 10 June.

Plenty of organisations did what busy teams do with an alert like that. Instead of patching PeopleSoft, which means change windows and testing on a system payroll depends on, they put a rule in front of it: block any web request whose path contains /PSEMHUB/. Quick, reversible, and it looked like it worked. For what it’s worth, Mandiant had already warned in June that “relying solely on Web Application Firewall (WAF) body-inspection rules is insufficient, as these controls can be bypassed.” That warning was about a slightly different kind of rule, but it pointed the same way.

On 25 September, Mandiant and Google Threat Intelligence published a follow-up. The group had changed one character. It started requesting /%50SEMHUB/ instead. %50 is simply the web-encoded form of the letter P. In Mandiant’s words, “Many WAF and reverse proxy rules match the literal path before URL decoding, while the PeopleSoft application server decodes the request and routes it to the vulnerable servlet.” The filter saw a string it didn’t recognise and waved it through. The server behind it read the same request as the one it was supposed to be protected from.

Figure 02 · How one encoded letter got past the firewall ScamDrill

Mechanism and quotation: Mandiant and Google Threat Intelligence, “ShinyHunters Renewed Mass Exploitation Campaign Targeting Oracle PeopleSoft,” 25 September 2026.

Mandiant says the renewed wave targeted “organizations that implemented WAF rules but did not patch the vulnerability,” with web shells on dozens of systems across higher education, technology, IT services, healthcare, agriculture, transportation and government. What it says was taken is a list any HR manager will recognise: HR records, payroll data, student records. Its first remediation line is blunt enough to print: “WAF rules and path-based blocking are not a substitute for patching.”

Did this bypass get the group into the FBI? Nobody has confirmed that. Mandiant’s report does not mention the FBI at all. Vectra has argued that the bureau relied on the firewall rule alone, but that is Vectra’s inference, and I would treat it as one. It doesn’t change the lesson, though. If you took a workaround in June and never came back for the patch, you are exactly who the September wave was built for.

Most small businesses do not run PeopleSoft. That is fine. Swap in whatever you do run: the self-hosted HR box a provider set up for you, the on-premises payroll server, the VPN appliance your hiring manager uses from home. The question is the same. Where did you accept a mitigation in place of a fix, and has anyone written down that you still owe the fix?

Why the hiring side is the soft side

A hiring system has an awkward brief. It has to face the internet, because candidates arrive from anywhere. It has to accept uploads from strangers, because that is what a résumé is. It usually lets people create accounts with nothing more than an email address. Nearly every design choice that makes it good at recruiting also makes it easier to attack.

Then there is ownership. In most companies I talk to, the applicant tracking system was chosen by HR, paid for on a card, and set up by a vendor’s onboarding team. Security reviews it once, if at all. Nobody patches a SaaS product, and that is one of the good things about SaaS, but somebody still has to own the configuration: who has admin, whether multi-factor sign-in is enforced, how long records are kept, which integrations are allowed to pull data out. That somebody is frequently nobody.

And the data is unusually good. A marketing database gives an attacker email addresses. A hiring database gives them names tied to home addresses, phone numbers, employment histories, and for roles that need a background check, dates of birth and Social Security numbers. The June wave shows what that can look like at scale: data reported from one UK university breached in the campaign ran to roughly 455,000 unique email addresses, with passport numbers and details about ethnicity and disabilities, per The Hacker News.

Verizon’s latest breach research points the same way from a different angle. The 2026 Data Breach Investigations Report found that 31% of breaches now start with vulnerability exploitation, which Verizon says is the first time in 19 years that it has overtaken stolen credentials. It also found that breaches involving a third party account for 48% of all breaches. An internet-facing HR product run by a supplier sits squarely in both of those numbers at once.

The people you never hired

This is the part I would push hardest on, because it is the cheapest risk to remove and the one almost nobody removes.

Every applicant who did not get the job is somebody you owe very little and hold a lot about. If your hiring system has been running for five years and nobody has changed the retention settings, it may well contain everyone who has ever applied, with whatever they uploaded. When a system like that leaks, the breach notice goes to people who may barely remember applying, from a company whose name they now associate with having their Social Security number stolen. You would not have chosen that as a first impression.

There are real minimums, and you should keep to them. Under the EEOC’s recordkeeping rule, most employers covered by federal anti-discrimination law must keep application forms and other hiring records for one year from the date the record was made or the personnel action taken, whichever is later, and longer if a discrimination charge or lawsuit is pending. Some employers, and some states, face longer periods. Ask whoever handles your employment law what applies to you, then write it down as a number.

But that is a floor. The FTC’s guidance for businesses puts it flatly: “If you don’t have a legitimate business need for sensitive personally identifying information, don’t keep it.” For an applicant who was turned down three years ago, it is hard to write the business need down with a straight face.

A few specifics worth doing:

• Stop collecting Social Security numbers at the application stage. You need one to run a background check and to put someone on payroll. You don’t need one from all 200 people who applied. Move it to the offer stage, or to the background-check vendor’s own form, so it never lands in your applicant tracking system at all.
• Turn on automatic deletion, and set it to your written number. Most modern applicant tracking products have a retention or anonymisation setting. Find it. If yours has none, that is a question for the vendor, and a data point for the next renewal.
• Treat background-check reports as their own category. If you use consumer reports to screen candidates, the FTC notes you may be subject to its Disposal Rule, which is about destroying them properly when you are done.
• Clean out the shadow copies. The résumé forwarded to a hiring manager, the interview scorecard in a shared drive, the export somebody made for a board meeting. The system’s retention setting will not reach any of those.

I’d be lying if I said this is quick for a company that has never done it. The first pass takes a few afternoons, and it involves at least one uncomfortable conversation about who has been keeping what. After that it runs itself.

Your system, or your vendor’s?

Go back to the FBI’s sentence one more time. “Whether a third-party or the FBI’s enterprise.” Two days in, with every resource you could want, the answer was still open.

For a small business the practical version of that question arrives as an email from a vendor you haven’t thought about in months. It says there was “unauthorised access to a limited subset of customer environments”, that the investigation is ongoing, and that they will update you. Then you wait, and your employees and former applicants start asking you things you can’t answer.

You cannot fix that on the day. You can fix a lot of it now. The FTC’s line on service providers is short: “Put your security expectations in writing in contracts with service providers. Then, don’t just take their word for it — verify compliance.” For a hiring or HR vendor, the expectations I would put in writing are these:

• How many days they have to tell you about a security incident affecting your data, and what the notice has to include.
• How long they keep access logs, and whether they can tell you, per candidate, whether a record was viewed or exported.
• Which subcontractors process your data, and whether they will tell you before that list changes.
• Whether they support single sign-on and enforced multi-factor sign-in for your admin accounts, on the plan you are actually paying for.
• For anything installed on your side or run by a managed provider: who applies security patches, and within how many days of release.

A vendor that won’t answer those questions in writing has still told you something useful.

One more thing, because it bit a lot of organisations in June. Your IT provider or managed service provider may be the one who applied the “temporary” mitigation. Ask them directly whether any security alert in the past year was handled with a workaround rather than a patch, and ask for the list. We made a similar point in the medtech supplier playbook: the supplier is often the way in, and the supplier is frequently you.

What comes after a hiring-data breach

The data theft is only the first event. The FBI’s May advisory on this same group is unusually specific about what came next for its earlier victims: extortion emails signed ShinyHunters, and “threatening text messages and phone calls to victims and their family members, and in some cases, swatting.” That is the extreme end. The more common aftermath of an HR or applicant leak is quieter, and it runs through your people.

Extortion aimed at leadership. A message to the owner or a senior manager claiming to hold the data, sometimes with a sample attached, and a deadline. The FBI’s advice in that advisory is not to pay or respond to the demands, and to report it. Call your insurer and counsel before anyone replies to anything.

Phishing that already knows your org chart. A leaked hiring file tells an attacker who your managers are, who just joined, what your job titles look like and which roles you recruit for. That is the raw material for a very convincing “HR update” email, or for a fake recruiter writing to the candidates you turned down using the exact role they applied for. The job-seeker side of that is covered in our fake remote job playbook, which is worth forwarding to your recruiters.

Payroll and direct-deposit requests. The employee-record half of an HR system holds exactly what someone needs to impersonate a staff member asking to change their bank details. It is the payroll diversion play, with a better script.

Calls to your help desk. Name, date of birth, employee ID and home address are the things many help desks still use to confirm who is calling. After a leak, all of those are in someone else’s hands. If your password-reset process relies on knowledge rather than a callback, change it now rather than after the first reset goes to the wrong person.

Your own hiring, used against you. A detailed picture of what your successful applicants look like is useful to anyone trying to get a fake candidate through your process. We have written about deepfake candidates and fake remote hires; a stolen applicant pool makes that easier to tailor.

If your HR vendor calls with bad news

This is not legal advice, and breach-notification duties vary by state and by what was taken. But the first two days tend to go the same way, and a little order helps.

1. Get the facts in writing. Which systems, which date range, what categories of data, whether it is confirmed or suspected, and who at the vendor is your contact. Ask the per-record question early: can they tell you which of your people were affected?
2. Call your insurer before you spend money. Many cyber policies require notice within a set period and have preferred response firms. Paying for your own forensic firm first can complicate the claim. Our cyber insurance compliance page covers what underwriters tend to expect.
3. Cut the paths back in. Rotate the admin passwords and any API keys the vendor’s product uses to talk to your other systems, and review which accounts can export in bulk. Mandiant’s own remediation list for this campaign includes rotating every credential the compromised application could read.
4. Warn your people before the scammers reach them. The FBI says it sent bureau-wide communications within 24 hours of the public reporting, which is a fair bar for a company of any size. A short internal note: what happened, what is known and not known, the one phone number that is really HR, and a promise that HR will never ask for bank changes or passwords by email. Send employees the household guide so they can freeze their credit and lock their Social Security numbers the same evening.
5. Work out who else is in the file. Former employees, rejected applicants, dependants on the benefits plan. Your notification obligations may well extend to all of them, and they are the people most likely to hear about it from a scammer first.
6. Write the timeline as you go. Who knew what, when, and what you did about it. You will need it for the insurer, for regulators, and for your own post-mortem. Our incident response guide has a template.

What to do now

If you only do two things this month, make them these. Put a name and a retention number next to every system that holds applicant data. Then ask each vendor, and your IT provider, the five contract questions above and file the answers.

The third thing is slower. After a hiring-data leak, the attacks that follow are almost all aimed at people: the email from “HR”, the recruiter who knows too much, the caller who has the employee ID. Your staff will see those in their inboxes on an ordinary Tuesday, halfway through something else, and whether they stop and check is a habit rather than a piece of knowledge. Small firms get picked precisely because nobody has practised that habit.