Cloud

Bullhorn, whose cloud applicant tracking and customer relationship management (CRM) software is used by more than 10,000 staffing and recruitment firms, disabled access to its platform on October 17 after detecting what it called "a cyber incident on the Bullhorn Platform." For about two days, recruiters could not reach candidate records, job boards stopped updating and integrations that call the Bullhorn API returned errors.

Service has mostly come back, but the investigation has not finished. Bullhorn says it has not yet determined whether customer data was taken. If your firm uses Bullhorn, or you hire through an agency that does, there are credentials to rotate and a phishing wave to prepare for this week. The same steps apply to any SaaS vendor that goes dark.

What happened, day by day

The first sign came on October 16, when Bullhorn's status page reported sync problems with its CRM and customers saw job posting fail. At 08:04 EDT on October 17 it reported "a system-wide outage affecting the Bullhorn platform", and that afternoon it confirmed the cyber incident and said it had "temporarily disabled access to our systems to contain the activity."

Bullhorn brought in CrowdStrike, and its chief information security officer, Owen Meehan, told Staffing Industry Analysts that Kroll is also involved. Access returned region by region over the weekend, across Australia, EMEA/UK and the US, with Cyber Daily recording services back shortly before 17:00 on October 19. Bullhorn now says the incident is contained.

Recovery has been uneven. As of October 20, The Register listed automation tools, Talent Platform, Onboarding365 and Time and Expense as still degraded, plus problems with single sign-on (SSO), password resets and customisations. Bullhorn Back Office (BBO), the payroll and billing product, stayed down for most of the week; customers were told to plan for it to be unavailable until the weekend, and the status page reported access restored on the evening of October 23. In that same update, Canvas reporting inside the applicant tracking system (ATS) was still unavailable.

What is still unknown

Sources disagree on which products the attack actually touched. BleepingComputer's report lists the ATS, CRM, automation and back-office tools as disrupted. Bullhorn's own statements say the incident affected ATS/CRM and that it has "no indication" Bullhorn Automation, Sourcebreaker or VMS Sync were affected. Both can be true: a product can be unaffected by the intrusion and still be unusable while the platform it depends on is offline. "No indication" is also not the same as "confirmed clean."

Bullhorn has not said how the attackers got in, who they are, or whether ransomware was involved, and no group has claimed the attack. Its FAQ says the forensic investigation is ongoing, that it has "not yet determined whether customer data was exfiltrated", and that it will contact affected customers and meet its notification obligations.

A separate event muddied the week. On October 21, the PHP2Shell vulnerabilities in PHP led several vendors, BambooHR among them, to take services offline as a precaution, and some Bullhorn products were paused for upgrades too. Bullhorn says that work is unrelated to the cyber incident. If you see a second wave of Bullhorn maintenance notices, that may be why. Our PHP2Shell post covers the PHP fixes.

Why the reset matters

A staffing platform connects to more than the people who log in to it. Recruiters sign in either through your identity provider over SSO, or with a password stored at Bullhorn. Job boards, careers-site plugins, payroll, background checks and timesheet tools connect through the API using a dedicated API user and OAuth client credentials, and they keep running whether anyone is watching or not.

Bullhorn's resets follow that split. Every user who does not sign in through SSO must set a new password on next login, with two-factor verification. API user passwords have been expired, so integrations stop working until someone updates the stored credentials. That covers integrations you host yourself and those run by a third party on your behalf. SSO users were not on the reset list, because their password lives with the customer's identity provider.

If an attacker reached the platform, anything that authenticates there could be exposed, so the vendor invalidates what it can. What the vendor cannot rotate is what you hold: the same password reused elsewhere, a client secret sitting in a partner's config file, an export of candidate data on someone's laptop.

What to do this week

1. List every integration. From Bullhorn's user administration, list the API users and match each one to a system and an owner: job board feeds, website plugins, payroll, onboarding and any middleware. One API user per integration makes the next step much easier.
2. Rotate API credentials and update every consumer. Bullhorn has already expired API passwords. Set new ones, update them in each connected system, and ask any third party that hosts an integration for you to confirm in writing that they have done the same. Rotate the OAuth client secret for each integration when Bullhorn opens that option, and confirm with the vendor whether refresh tokens issued before the incident are still valid.
3. Handle the local accounts. Anyone who used a non-SSO Bullhorn password elsewhere should change it there too. Treat this as the push to move everyone onto SSO, so the next vendor reset happens in your identity provider, where you control MFA and can revoke sessions in one place.
4. Check your own logs. Review the sign-in history for your Bullhorn users and API users from early October onward. Look for logins from unfamiliar IP ranges, API activity outside the hours your integrations normally run, and unusual bulk exports. Keep what you find in case Bullhorn later confirms data theft and you need to assess your notification duties.
5. Warn recruiters and candidates. Bullhorn has warned that attackers may pose as its staff by email, text or phone, and says it will never ask for passwords, MFA codes or verification tokens. Tell staff that any "Bullhorn" reset link should be ignored in favour of typing the login address. If candidate data was taken, expect fake job offers and requests for ID documents or bank details; a short note on your careers page about how you contact applicants helps.
6. Request a data export. Bullhorn advised customers to ask support for data extracts. A current copy of your candidates, placements and timesheets is what lets you keep billing and paying contractors when the platform is offline.

Plan for the vendor going dark

For many staffing firms, the hardest part of this incident was operational: two days without a system of record, then a payroll product that was offline for nearly a week. A short fallback plan covers most of that: a scheduled export to storage you control, a paper or spreadsheet process for timesheets and placements, and a named person who watches the vendor's status page and tells the business what changed.

When the vendor's post-incident report arrives, read it against your contract: how fast it notified you, what data it confirms was accessed, and what it is changing.

If you want help mapping which SaaS platforms hold your data and how each one connects, our safeguarding and hardening work covers SSO, API credentials and integration sprawl, and our security operations team can watch for misuse of vendor accounts. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.

---

Sources: BleepingComputer, Staffing Industry Analysts, Cyber Daily, The Register, OODA Loop, Rescana, Staffing Industry Analysts on the PHP vulnerabilities, Bullhorn status page.