Nov. 6, 2026 · Trust Player Zero
Abrigo took its Sageworks lending platform offline on Friday, October 30. Most of it did not come back until Monday morning, and banks and credit unions that run loan work on it had to keep going in the meantime. Two other organizations were breached this week. In all three cases, finding the problem was only the beginning. The harder job was working out what the system touched.
What a three-day Sageworks outage means for a bank
Abrigo disabled Sageworks at about 11:25 a.m. ET on October 30. Online Portal Now, Sageworks Analyst and the Sageworks API were affected. According to Abrigo's status page, most functionality came back on November 2, while borrower-facing features stayed unavailable longer.
The company first called the cause "irregular activity." On November 3, a spokesperson told American Banker that it was a data security incident involving unauthorized access, that the access had been contained, and that Abrigo had no evidence of continued unauthorized access. Abrigo did not say whether anyone viewed or took data. American Banker reports that more than 2,400 institutions use Abrigo's products. Abrigo has not said how many use Sageworks.
For a bank, the vendor's incident becomes its own. Someone has to know which lending workflows depend on the platform and which of them can wait. Someone also has to decide when normal operations resume, and a vendor's word that the access is contained is only one input to that decision.
Trigger.dev blocked the exploit. Customers still have keys to rotate.
Trigger.dev disclosed an incident on November 1 and published its full report on November 6. The attacker obtained customer root API keys for some customer environments and accessed environment variables. The company put the impact at 0.66% of all customers and says it has blocked the attacker. It has not said how the attacker got in or which variables were exposed.
Environment variables often hold the credentials one service uses to reach another. Trigger.dev's own advice to affected customers is to regenerate their Trigger.dev API keys, rotate credentials in the affected environments, including database passwords, third-party API keys and access tokens, and treat those credentials as compromised.
Blocking the exploit stops new access. It does not take back credentials the attacker may already hold. A customer's job is to know what each of those credentials opens, then confirm each one was actually changed.
The Kyiv Independent's newsletter carried the attackers' message
On November 4, the Kyiv Independent said attackers had gained access to its website content management system and a service it uses to send newsletters. They sent four emails to readers and posted similar messages on the site, which staff deleted. One email told readers to take shelter from a nuclear strike that was not happening. Others made false claims about an attack on President Zelensky.
The outlet said the content points to a Russian operation. It has not published technical evidence, citing the content of the messages and similarities to an earlier attack on a Ukrainian air raid alert app. Staff are working with cybersecurity specialists to investigate how the breach happened.
A newsletter tool does not look as sensitive as a customer database. But it sends mail that readers trust because of who it comes from. A support desk or a customer portal works the same way: an account that can speak in the company's voice is worth protecting for that reason alone.
Run the Friday afternoon call before it happens
Say a vendor tells your team this Friday that it has found suspicious activity and is shutting down a platform your employees use every day. The first problem is not technical. It is that nobody knows what stops working.
Pick one important third-party system and write the answers down now. Which business process depends on it? Who owns the vendor relationship? Who administers its access? Who has the authority to suspend or restore the connection during an incident?
Then go one step further. If the credentials tied to that system had to be rotated, you should be able to say where they are used. If the vendor says the issue is contained, you should know what your own team will check before treating its part as done. A vendor can restore its service while its customer still has work left to do.
Bring us the workflow that gets hard after the finding
TPZ is starting with identity and access. Our Microsoft Entra integration is read-only today. It surfaces identity and access conditions so a team can see what deserves attention. It does not inspect the Abrigo, Trigger.dev or Kyiv Independent environments.
In the Design Partner Beta, we are testing what context needs to sit beside an access finding before someone can make a good decision about it. A governed Entra action flow, with customer authorization and verification of the result, is a Beta target and is not available today.
If your team runs Microsoft Entra, think of the last access issue that was easy to find and hard to resolve. Bring us that workflow: what the tool found, what your team had to look up, who got pulled in, and what you needed to see before calling it resolved.
Bring us one finding that creates too much work after it is found. We’ll help you find a better way to handle what comes next.
